Au travail, nous avons une grande application interne qui est en développement depuis près de 2 ans maintenant; Je viens de rejoindre le projet récemment et une partie de l'architecture me laisse un peu perplexe, donc j'espère que quelqu'un ici pourra fournir des conseils avant de sortir poser les mêmes questions aux architectes (afin que je puisse avoir une discussion éclairée avec eux ).
Je m'excuse si ce qui suit est un peu long, je veux juste essayer de brosser un bon tableau de ce qu'est le système avant de poser ma question :)
La façon dont le système est configuré est que nous avons une application Web principale (asp.net, AngularJS) qui agrège principalement les données de divers autres services. Donc, fondamentalement, c'est un hôte pour une application AngularJS; il y a littéralement un contrôleur MVC qui amorce le côté client, puis tous les autres contrôleurs sont des contrôleurs WebAPI.
Les appels du côté client sont gérés par ces contrôleurs, qui sont toujours déployés sur des boîtiers qui ne font qu'héberger l'application Web. Nous en avons actuellement 4.
Cependant, les appels sont ensuite acheminés vers un autre ensemble d'applications WebAPI (généralement celles-ci par domaine d'activité, telles que la sécurité, les données client, les données produit, etc.). Toutes ces WebAPI sont également déployées sur des boîtiers dédiés; nous avons également 4 de ces boîtes.
À une seule exception près, ces WebAPI ne sont utilisées par aucune autre partie de notre organisation.
Enfin, ces WebAPI effectuent encore un autre ensemble d'appels aux services "back-end", qui sont généralement des services asmx ou wcf hérités placés au-dessus de divers systèmes ERP et magasins de données (sur lesquels nous n'avons aucun contrôle).
La plupart des logiques métier de notre application se trouvent dans ces WebApis, comme la transformation de données héritées, leur agrégation, l'exécution de règles métier, le type de chose habituel.
Ce qui m'a dérouté, c'est quel est l'avantage possible d'avoir une telle séparation entre la WebApplication et les WebAPI qui la servent. Étant donné que personne d'autre ne les utilise, je ne vois aucun avantage d'évolutivité (c'est-à-dire qu'il est inutile de mettre 4 autres boîtes API pour gérer une charge accrue, car une charge accrue sur les serveurs API doit signifier qu'il y a une charge accrue sur les serveurs Web - par conséquent, il doit y avoir un rapport 1: 1 du serveur Web au serveur Api)
Je ne vois pas non plus d’avantage de devoir effectuer un appel HTTP supplémentaire Navigateur => HTTP => WebApp => HTTP => WebAPI => HTTP => Services backend. (cet appel HTTP entre WebApp et WebAPI est mon problème)
Je cherche donc actuellement à faire en sorte que les WebAPI actuelles soient déplacées de solutions distinctes vers des projets simplement séparés au sein de la solution WebApplication, avec de simples références de projet entre les deux et un modèle de déploiement unique. Ils deviendraient donc finalement des bibliothèques de classes.
Au niveau du déploiement, cela signifie que nous aurions 8 boîtes Web "full stack", par opposition à 4 + 4.
Les avantages que je vois de la nouvelle approche sont
- Augmentation des performances car il y a un cycle de sérialisation / désérialisation en moins entre l'application Web et les serveurs WebAPI
- Des tonnes de code qui peuvent être supprimés (c'est-à-dire pas besoin de maintenir / tester) en termes de DTO et de mappeurs aux limites sortantes et entrantes des serveurs d'application Web et WebApi respectivement.
- Meilleure capacité à créer des tests d'intégration automatisés significatifs, car je peux simplement me moquer des services principaux et éviter le désordre autour des sauts HTTP de niveau intermédiaire.
La question est donc: ai-je tort? Ai-je manqué une "magie" fondamentale d'avoir séparé les boîtes WebApplication et WebAPI?
J'ai fait des recherches sur certains matériaux d'architecture à N niveaux, mais je n'arrive pas à trouver quoi que ce soit qui puisse apporter un avantage concret à notre situation (car l'évolutivité n'est pas un problème pour autant que je sache, et c'est une application interne donc la sécurité des applications WebAPI n'est pas un problème.)
Et aussi, que serais-je en train de perdre en termes d'avantages si je devais réorganiser le système selon la configuration proposée?