Différence entre le frontend, le backend et le middleware dans le développement Web
Je me demandais si quelqu'un pouvait comparer/contraster les différences entre le front-end, le backend et le middleware ("middle-end"?) De manière succincte.
Y a-t-il des cas où ils se chevauchent? Existe-t-il des cas où ils DOIVENT se chevaucher et où frontend/backend ne peut pas être séparé? En termes de goulots d'étranglement, à quelle fin est associé quel type de goulots d'étranglement?
Voici une ventilation:
Front-end tier -> Couche d’interface utilisateur composée généralement d’un mélange de HTML, Javascript, CSS, Flash et de divers codes côté serveur tels que ASP.Net, ASP classique, PHP, etc. Pensez-y comme étant le plus proche possible de l’utilisateur en termes de code.
Middleware, niveau intermédiaire -> Un niveau en arrière, généralement appelé partie "plomberie" d'un système. Java et C # sont des langages courants pour l'écriture de cette partie. Ils pourraient être considérés comme le lien entre l'interface utilisateur et les données. Ils peuvent être des services Web ou des composants WCF ou autres SOA = composants éventuellement.
Niveau principal -> Les bases de données et autres magasins de données se trouvent généralement à ce niveau. Oracle, MS-SQL, MySQL, SAP et divers logiciels du commerce viennent à l’esprit pour ce logiciel qui constitue le traitement final des données.
Un chevauchement peut exister entre tous ces éléments, dans la mesure où tout pourrait être versé dans une couche, comme un site Web ASP.Net qui utilise la fonctionnalité intégrée AJAX qui génère du code Javascript alors que le code situé derrière peut contenir des commandes de base de données). faire en sorte que le code derrière contienne à la fois les niveaux intermédiaire et principal.Vous pouvez également utiliser VBScript pour agir en tant que toutes les couches utilisant des objets ADO et fusionnant les trois niveaux en un seul.
De même, la prise d'intergiciels et de front-end 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 base de données ou back-end -> Cela peut varier de la paie, des ventes ou d’autres tâches pour lesquelles le débit de la base de données ralentit.
2) Goulots d’étranglement des intergiciels -> C’est là que certains services Web atteignent peut-être leur capacité, mais que l’avant et l’arrière ont une bande passante suffisante pour traiter plus de trafic. Il est également possible que certains serveurs faisant partie d'un système ne faisant pas partie de l'interface utilisateur ou des données brutes pouvant constituer un goulot d'étranglement avec quelque chose comme Biztalk ou MSMQ.
3) Goulots d’étranglement frontaux -> Cela pourrait entraîner des problèmes côté client ou côté serveur. Par exemple, si vous prenez un PC bas de gamme et le chargez sur une page Web contenant un grand nombre de données en cours de téléchargement, le client peut se situer à l’endroit où se trouve le goulot d’étranglement. De même, le serveur peut mettre des demandes en file d'attente s'il est bourré de demandes comme celles qu'Amazon.com ou d'autres sites Web à fort trafic peuvent avoir par moments.
Une partie de ceci est sujette à interprétation, donc ce n'est pas parfait, loin de là, et YMMV.
EDIT: Il convient de noter que certains systèmes peuvent avoir plusieurs interfaces frontales ou arrières. Par exemple, un système de gestion de contenu permettra probablement aux visiteurs du site de visualiser le contenu frontal, mais comment les éditeurs de contenu peuvent-ils modifier les données du site? La possibilité d'extraire ces données peut être considérée comme frontale puisqu'il s'agit d'un composant d'interface utilisateur ou comme un back-end puisqu'elle est utilisée par des utilisateurs internes plutôt que par le grand public qui consulte le site. Ainsi, il y a quelque chose à dire pour le contexte ici.
En règle générale, les utilisateurs font référence à la couche de présentation d'une application sous le nom front end, à sa couche de persistance (base de données, généralement) sous le nom back end, et tout ce qui se situe entre niveau intermédiaire. Cet ensemble d’idées est souvent appelé architecture à 3 niveaux. Ils vous permettent de séparer votre application en blocs plus compréhensibles (et testables!); vous pouvez également réutiliser plus facilement le code de niveau inférieur dans les niveaux supérieurs.
Quel code fait partie de quel niveau est quelque peu subjectif? les concepteurs graphiques ont tendance à penser à tout ce qui n'est pas la présentation, les utilisateurs de bases de données considèrent tout ce qui se trouve devant la base de données comme étant le front-end, etc.
Toutes les applications ne doivent cependant pas être séparées de cette façon. C’est certainement plus de travail d’avoir 3 sous-projets distincts que d’ouvrir simplement index.php et de craquer; En fonction de (1) combien de temps vous prévoyez de maintenir l'application (2) de la complexité de l'application, vous pouvez renoncer à la complexité.
Il y a en fait 3 questions dans votre question:
- Définir frontend, middle et back end
- Quand et comment se chevauchent-ils?
- Leurs goulots d'étranglement habituels associés.
Ce que JB King a décrit est correct, mais il s’agit d’une version particulière et simple, dans laquelle il a mappé l’avant, le milieu et l’autre 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 laide où même MVC n'a pas été appliqué, et vous pouvez avoir des appels directs à la base de données dans une vue.
Cependant, dans les applications Web réelles et complexes, vous avez en effet deux ou trois couches différentes, appelées avant, milieu et arrière. Chacun d'eux peut avoir une base de données 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 paramètres 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 middle-end n’est pas obligatoire et c’est là que se trouve la logique d’entreprise. Il sera basé sur un PIM, un outil MDM ou une sorte de base de données personnalisée sur laquelle vous enrichirez vos produits ou vos articles (pour les CMS). Ce sera également l’endroit où vous coderez les fonctions d’entreprise 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 base de données source ou votre ERP. C'est peut-être que l'API écrit et lit dans votre ERP. Ce peut être votre base de données de fournisseur, si vous faites du commerce électronique. En fait, cela dépend vraiment des projets Web, mais il s’agit toujours d’un référentiel central. Vous pourrez y accéder via un appel à la base de données, via une API, une couche Hibernate ou une application dorsale complète.
Cette description signifie qu'il est impossible de répondre aux 2 autres questions 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 reste 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 une vue serait liée aux appels de base de données. Si vous lisez la question "Y a-t-il des cas où ils DOIVENT se chevaucher et où frontend/backend ne peut pas être séparé?" dans un sens plus large, avec 3 composants différents, il y a des fois où l'architecture à 3 couches est inutile bien sûr. Pensez à un simple blog personnel, vous n'aurez pas besoin d'extraire de données externes ni d'interroger les files d'attente RabbitMQ.
Voici un exemple du monde réel qui montre front/mid/back end.
Description générale:
- Frontend est responsable de la présentation des données à l'utilisateur. S'il vous plaît noter bizarrerie intéressante que vous pouvez avoir deux frontaux différents associés à un seul backend
- Le backend fournit la logique métier/la persistance des données.
- Le middleware (activemq dans l'image) est responsable du système. intégration entre les backends. Il est généralement installé en tant qu'application distincte
![enter image description here]()
Chevauchement:
Il est possible d'avoir un chevauchement entre le frontend et le backend. Cela soulève 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 piles de technologies modernes encouragent les développeurs à avoir une séparation stricte. Par exemple, sur l'image, vous pouvez voir que le système Web du premier système dispose d'un service Web de repos, qui est une ligne de séparation claire.
Goulots d'étranglement
La plupart des goulots d'étranglement sont générés par la base de données/le 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, de sorte que chaque connexion peut être lente. Avec une bonne conception des applications, ces problèmes sont évitables dans une large mesure.
En termes de réseau et de sécurité, le backend est de loin le nœud le plus sécurisé (devrait être).
La partie intermédiaire, généralement un serveur Web, sera un peu dans la nature et sera coupée du réseau d’une entreprise à bien des égards. Le nœud intermédiaire est généralement placé dans le DMZ) et est segmenté à partir du réseau avec les paramètres de pare-feu. La plupart des analyses de code côté serveur des pages Web sont gérées sur le serveur Web intermédiaire.
Pour accéder au backend, il faut passer par le middle-end, qui dispose d’un ensemble de règles soigneusement conçues permettant/interdisant l’accès aux numéros essentiels stockés sur le serveur de base de données (backend).