Avantages d'utiliser des serveurs API et UI distincts pour les applications Web

17

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?

Stephen Byrne
la source
Si les 8 cases sont en effet sous votre contrôle, je ne vois aucune bonne raison pour la séparation. Savez-vous s'ils avaient une propriété distincte dans le passé?
Ixrec
@Ixrec - oui, les 8 cases appartiennent à l'organisation, et l'application est 100% interne uniquement. Je soupçonne que la séparation a été initialement conçue en partie parce qu'un autre groupe interne possédait l'infrastructure (beaucoup de politique) et en partie parce que quelqu'un a dit "N-Tier" et tout le monde est allé avec.
Stephen Byrne

Réponses:

25

Une des raisons est la sécurité - si (haha! Quand ) un pirate accède à votre serveur Web frontal, il a accès à tout ce à quoi il a accès. Si vous avez placé votre niveau intermédiaire dans le serveur Web, alors il a accès à tout ce qu'il a - c'est-à-dire à votre base de données, et la prochaine chose que vous savez, il suffit de lancer "select * from users" sur votre base de données et de le retirer hors ligne craquage de mot de passe.

Une autre raison est la mise à l'échelle - le niveau Web où les pages sont construites et modifiées et traitées XML et tout ce qui prend beaucoup plus de ressources que le niveau intermédiaire, qui est souvent une méthode efficace pour obtenir des données de la base de données vers le niveau Web. Sans oublier de transférer toutes ces données statiques qui résident (ou sont mises en cache) sur le serveur Web. Ajouter plus de serveurs Web est une tâche simple une fois que vous en avez passé 1. Il ne devrait pas y avoir de rapport 1: 1 entre les niveaux Web et logique - j'ai déjà vu 8: 1 (et un rapport 4: 1 entre logique tier et DB). Cela dépend cependant de ce que font vos niveaux et de la quantité de cache qui s'y déroule.

Les sites Web ne se soucient pas vraiment des performances d'un seul utilisateur car ils sont conçus pour évoluer, peu importe qu'un appel supplémentaire ralentisse un peu les choses si cela signifie que vous pouvez servir plus d'utilisateurs.

Une autre raison pour laquelle il peut être bon d'avoir ces couches est qu'elle force plus de discipline dans le développement où une API est développée (et facilement testée car elle est autonome), puis l'interface utilisateur développée pour la consommer. J'ai travaillé dans un endroit qui a fait cela - différentes équipes ont développé différentes couches et cela a bien fonctionné car elles avaient des spécialistes pour chaque niveau qui pouvaient lancer les changements très rapidement parce qu'ils n'avaient pas à se soucier des autres niveaux - c'est-à-dire un développeur javscript d'interface utilisateur pourrait ajouter une nouvelle section au site en consommant simplement un nouveau service Web développé par quelqu'un d'autre.

gbjbaanb
la source
merci pour la perspective. Je n'avais pas considéré le travail supplémentaire effectué par la construction de pages, etc. Cependant, étant donné qu'il y a littéralement une vue de rasoir dans l'application et que tout une fois amorcé est AngularJs, je ne suis pas sûr que ce soit un problème dans ce cas. De plus, puisque l'application est uniquement interne, je ne pense pas que la sécurité soit une préoccupation trop importante - en gardant à l'esprit que les services principaux, où toutes les données sont réellement stockées, seront toujours sur des boîtes séparées derrière les services wcf, avec des tonnes de sécurité sur eux car ils sont utilisés par toute l'organisation.
Stephen Byrne
Bien sûr, votre cas est ce que votre cas est. Je me demande si ces services pourraient être consommés par une autre application Web à l'avenir (ou devraient l'être) et c'est pourquoi son architecture est telle qu'elle est. Là encore, le vieil architecte aurait pu le regarder à 10 000 pieds!
gbjbaanb
1
Dans notre scénario, nous avons décidé de développer l'application mobile après que tout ait été en production pendant un certain temps. Nous étions heureux d'avoir un serveur API séparé du serveur UI, car l'application mobile n'avait rien à voir avec l'application Web. Nous pourrions mettre à l'échelle séparément les parties «mobile» et «Web». Une autre chose mérite d'être notée: l'application Web n'est en réalité qu'un simple front / client, ce qui signifie que le client d'application Web (navigateur) appelle le serveur API pour obtenir des données (dans notre cas, cela est possible). Les appels HTTP "redondants" entre les serveurs API et UI étaient négligeables par rapport au trafic entre navigateur / mobile et serveur API.
Michal Vician
2

Je pense qu'il n'y a pas de bonne / mauvaise réponse ici. Avez-vous interrogé vos collègues sur le but de cette architecture?

D'après la façon dont je comprends vos descriptions, le " WebAPI " dans votre architecture sert de sorte de middleware self-made. Vous pouvez maintenant rechercher les avantages des utilisations d'un middleware. Fondamentalement, votre Webapp n'aurait jamais besoin d'être adoptée si vous modifiez votre système de backoffice (tant que l' interface WebAPI reste la même).

Pour aller plus loin: Imaginez que vous ayez une base de données clients (service backend) et que 5 applications web communiquent avec cette base de données. Si vous remplacez le système de base de données client par un nouveau système (comme celui d'un autre fournisseur et que vous ne pouvez pas influencer les interfaces de service Web), vous devrez probablement modifier la couche de communication des 5 applications Web. Si vous communiquez via votre WebAPI , il vous suffira de changer la couche de communication de la WebAPI .

Fondamentalement, l'architecture de couche est aujourd'hui considérée à la fois comme un motif et un anti-motif. (Voir: Code Lasagne ) Si vous n'avez qu'un seul système sans avoir l'intention de l'étendre davantage au cours des prochaines années, je préfère considérer cela comme anti-modèle. Mais ce serait un juge taff irréaliste, car je ne connais pas les circonstances / situation exactes :)

Stefan Woehrer
la source
merci pour les commentaires, les services back-end finaux sont utilisés par toute l'organisation et ont des contrats de services WCF bien définis (quoique un peu simplistes) dont l'organisation est propriétaire. Il y a donc beaucoup d'indirection si nous devons changer le back-end (ce que nous sommes en train de faire, passer d'un ERP à un autre). Mais mon problème est que notre application fournit un ensemble distinct d'apis HTTP middleware qui ne sont consommés que par elle. Il semble qu'un niveau de trop :)
Stephen Byrne