Différence entre frontend, backend et middleware dans le développement web

Je me demandais si quelqu’un pouvait comparer / contraster les différences entre le frontend, le backend et le middleware (“middle-end”?) Succinctement.

Y a-t-il des cas où ils se chevauchent? Y a-t-il des cas où ils DOIVENT se chevaucher et que l’interface frontale / backend ne peut pas être séparée? En termes de goulots d’étranglement, quelle est la fin associée à quel type de goulots d’étranglement?

Voici une ventilation:

Niveau frontal -> La couche d’interface utilisateur consiste généralement en un mélange de code HTML, Javascript, CSS, Flash et divers codes côté serveur tels que ASP.Net, ASP classique, PHP, etc. Considérez ceci comme étant le plus proche de l’utilisateur en termes de code.

Middleware, middle-tier -> Un niveau en arrière, généralement appelé la partie “plomberie” d’un système. Java et C # sont des langages communs pour écrire cette partie qui peuvent être considérés comme le lien entre l’interface utilisateur et les données et peuvent être des services Web, des composants WCF ou d’autres composants SOA.

Niveau back-end -> Les bases de données et autres magasins de données sont généralement à ce niveau. Oracle, MS-SQL, MySQL, SAP et divers logiciels disponibles sur le marché sont à l’esprit pour ce logiciel qui constitue le traitement final des données.

Un chevauchement peut exister entre ces éléments car vous pourriez avoir tout versé dans une couche comme un site Web ASP.Net qui utilise la fonctionnalité AJAX intégrée qui génère du Javascript alors que le code peut contenir des commandes de firebase database -end tiers. Vous pouvez également utiliser VBScript pour agir comme toutes les couches utilisant des objects ADO et fusionner les trois niveaux en un seul.

De même, la prise de middleware et de front ou back-end peut être combinée dans certains cas.

Les goulots d’étranglement ont généralement plusieurs niveaux différents:

1) Traitement de la firebase database ou du back-end -> Cela peut aller de la paie, des ventes ou d’autres tâches où le débit vers la firebase database ralentit.

2) Les goulots d’étranglement du middleware -> Ce serait le cas où certains services Web seraient en train de bash de la capacité mais les extrémités avant et arrière ont une bande passante pour gérer plus de trafic. Alternativement, il peut y avoir un serveur qui fait partie d’un système qui n’est pas tout à fait la partie interface utilisateur ou les données brutes qui peuvent constituer un goulot d’étranglement en utilisant quelque chose comme Biztalk ou MSMQ.

3) Goulots d’étranglement du front-end – Cela pourrait causer des problèmes côté client ou côté serveur. Par exemple, si vous preniez un PC bas de gamme et que vous chargiez une page Web contenant beaucoup de données en cours de téléchargement, le client pourrait être l’emplacement où se trouve le goulot d’étranglement. De même, le serveur peut mettre en queue des requêtes s’il reçoit des demandes telles que celles qu’Amazon.com ou d’autres sites Web à fort trafic peuvent parfois obtenir.

Certaines sont sujettes à interprétation, donc ce n’est absolument pas parfait et YMMV.


EDIT: Quelque chose à prendre en compte est que certains systèmes peuvent avoir plusieurs front-end ou back-end. Par exemple, un système de gestion de contenu aura probablement un moyen pour les visiteurs du site de voir le contenu qui est une interface, mais comment les éditeurs de contenu peuvent-ils modifier les données sur le site? La possibilité de récupérer ces données peut être vue comme une interface car il s’agit d’un composant de l’interface utilisateur ou peut être considéré comme un serveur principal car il est utilisé par les utilisateurs internes plutôt que par le grand public qui consulte le site. Il y a donc quelque chose à dire pour le contexte ici.

D’une manière générale, les utilisateurs se réfèrent à la couche de présentation d’une application en tant que serveur frontal , à sa couche de persistance (firebase database, généralement) en tant que serveur principal et à tout ce qui se trouve entre tiers . Cet ensemble d’idées est souvent appelé architecture à trois niveaux. Ils vous permettent de séparer votre application en plusieurs parties plus facilement compréhensibles (et testables!). Vous pouvez également réutiliser le code de niveau inférieur plus facilement dans les niveaux supérieurs.

Quel code fait partie de quel niveau est quelque peu subjectif; Les concepteurs graphiques ont tendance à penser que tout ce qui n’est pas une présentation constitue l’arrière-plan.

Cependant, toutes les applications ne doivent pas être séparées de cette façon. Il est certainement plus difficile d’avoir 3 sous-projets distincts que d’ouvrir simplement index.php et de faire du cracking; En fonction de (1) combien de temps vous pensez avoir à maintenir l’application (2) à quel point vous attendez de la complexité de l’application, vous voudrez peut-être renoncer à la complexité.

Il y a en fait 3 questions dans votre question:

  • Définir frontend, middle et back end
  • Comment et quand se chevauchent-ils?
  • Leurs goulots d’étranglement habituels.

Ce que JB King a décrit est correct, mais il s’agit d’une version simple et particulière, dans laquelle il a en fait mappé l’avant, le milieu et le bacn sur une couche MVC. Il a cartographié M à l’arrière, V à l’avant et C au milieu.

Pour beaucoup de gens, c’est très bien, car ils viennent du monde laid où même MVC n’a pas été appliqué, et vous pourriez avoir des appels de firebase database directs dans une vue.

Cependant, dans les applications Web complexes et réelles, vous avez en effet deux ou trois couches différentes, appelées front, middle et back. Chacun d’entre eux peut avoir une firebase database associée et un contrôleur.

Le front-end sera visible par l’utilisateur final. Il ne faut pas le confondre avec le front-office, qui est l’interface utilisateur pour les parameters et l’administration du front. Le front-end sera généralement une sorte de CMS ou de plate-forme de commerce électronique (Magento, etc.).

Le moyen terme n’est pas obligatoire et c’est là que sont les logiques commerciales. Il sera basé sur un PIM, un outil MDM ou une sorte de firebase database personnalisée où vous enrichirez vos produits ou vos articles (pour les CMS). Ce sera également l’endroit où vous coderez les fonctions métier devant être partagées entre différentes interfaces (par exemple, entre l’interface PC et l’application mobile basée sur une API). Parfois, un ESB ou un outil comme ActiveMQ sera votre milieu de gamme

Le back-end sera une 3ème couche, entourant votre firebase database source ou votre ERP. Il peut être inutile de lire et de lire les API de votre ERP. C’est peut-être votre fournisseur de firebase database, si vous faites du commerce électronique. En fait, cela dépend vraiment de projets Web, mais il s’agit toujours d’un repository central. Il sera accessible via un appel de firebase database, via une API ou une couche Hibernate, ou une application back-end complète.

Cette description signifie que répondre aux deux autres questions n’est pas possible dans ce fil, car les goulots d’étranglement dépendent vraiment de ce que contiennent vos 3 extrémités: ce que JB King a écrit rest vrai pour les architectures MVC simples

au moment où la question a été posée (il y a 5 ans), le modèle MVC n’était peut-être pas encore si largement adopté. Maintenant, il n’y a absolument aucune raison pour que le modèle MVC ne soit pas suivi et qu’une vue soit liée aux appels de firebase database. Si vous lisez la question “Existe-t-il des cas où ils DOIVENT se chevaucher et que l’interface utilisateur / backend ne peut pas être séparée?” dans un sens plus large, avec 3 composants différents, puis il y a des moments où l’architecture 3 couches est inutile bien sûr. Pensez à un simple blog personnel, vous n’aurez pas à extraire de données externes ou à interroger les files d’attente RabbitMQ.

Voici un exemple concret qui montre l’avant / milieu / arrière.

Description générale:

  • Frontend est responsable de la présentation des données à l’utilisateur. S’il vous plaît noter bizarre intéressant que vous pouvez avoir deux frontaux différents associés à backend unique
  • Backend fournit la persistance de la logique métier / des données.
  • Le middleware (activemq dans l’image) est responsable du système au système. intégration entre les backends. Il est généralement installé en tant qu’application séparée entrer la description de l'image ici

Chevauchement:

Il est possible d’avoir un chevauchement entre le frontend et le backend. Cela entraîne généralement des problèmes à long terme liés à la maintenance et à l’évolutivité des applications. Assez commun dans les applications héritées.

La plupart des stacks de technologies modernes encouragent les développeurs à avoir une séparation ssortingcte. Par exemple, sur la photo, vous pouvez voir que le backend du premier système a un service Web qui est une ligne de séparation claire.

Goulets d’étranglement

La plupart des goulots d’étranglement sont causés par une firebase database ou un réseau. Les bases de données sont situées dans le backend. En ce qui concerne les problèmes de réseau, chaque connexion passe par netowrk, donc chaque connexion risque d’être lente. Avec une bonne conception des applications, ces problèmes peuvent être évités dans une large mesure.

En termes de mise en réseau et de sécurité, le backend est de loin le nœud le plus (devrait être) sécurisé.

La partie du milieu de gamme, qui est généralement un serveur Web, sera quelque peu sauvage et coupée à bien des égards du réseau d’une entreprise. Le noeud intermédiaire est généralement placé dans la zone démilitarisée et segmenté à partir du réseau avec les parameters du pare-feu. La plupart de l’parsing de code côté serveur des pages Web est gérée sur le serveur Web intermédiaire.

Accéder au backend signifie passer par le moyen terme, qui comprend un ensemble de règles soigneusement conçues permettant / interdisant l’access aux numéros essentiels stockés sur le serveur de firebase database (backend).