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 frontend, backend et middleware ("middleware"?) succinctement.
Y a-t-il des cas où ils se chevauchent? Y a-t-il des cas où ils doivent se chevaucher et où frontend/backend ne peuvent pas être séparés? En termes de goulets d'étranglement, quelle fin est associée à quel type de goulets d'étranglement?
5 réponses
Voici une ventilation:
Niveau frontal- > couche D'Interface utilisateur généralement composée d'un mélange de HTML, Javascript, CSS, Flash et divers codes côté serveur comme ASP.Net, ASP classique, PHP, etc. Pensez à cela comme étant plus proche de l'utilisateur en termes de code.
Middleware, niveau intermédiaire- > un niveau 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 pourrait être considérée comme la colle entre L'interface utilisateur et les données et peut être des webservices ou des composants WCF ou d'autres composants SOA éventuellement.
Niveau -> Bases de données et d'autres magasins de données sont généralement à ce niveau. Oracle, MS-SQL, MySQL, SAP et divers logiciels disponibles sur le marché viennent à l'esprit pour ce logiciel qui est le traitement final des données.
Le chevauchement peut exister entre n'importe lequel d'entre eux car vous pourriez avoir tout versé dans une couche comme un ASP.Net site web qui utilise la fonctionnalité AJAX intégrée qui génère du Javascript alors que le code derrière peut contenir des commandes de base de données, ce qui fait que le code derrière contient à la fois des niveaux intermédiaires et back-end. Alternativement, on pourrait utiliser VBScript pour agir comme toutes les couches en utilisant des objets ADO et en fusionnant les trois niveaux en un seul.
De même, prendre middleware et front ou back-end peut être combiné dans certains cas.
Les goulets d'étranglement ont généralement quelques niveaux différents:
1) Traitement de base de données ou de back-end - > cela peut varier de la paie ou les ventes ou d'autres tâches où le débit de la base de données s'embourbe.
2) goulots D'étranglement Middleware- > ce serait là que certains services web peuvent atteindre la capacité, mais les extrémités avant et arrière ont de la 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 de L'interface utilisateur ou les données brutes qui peuvent être un goulot d'étranglement en utilisant quelque chose comme Biztalk ou MSMQ.
3) goulots D'étranglement frontaux - > cela pourrait client ou problèmes côté serveur. Par exemple, si vous avez pris un PC bas de gamme et qu'il a chargé une page web composée de beaucoup de données téléchargées, le client pourrait être l'endroit où se trouve le goulot d'étranglement. De même, le serveur pourrait mettre en file d'attente des demandes s'il est martelé avec des demandes comme quoi Amazon.com ou d'autres sites web à fort trafic peuvent parfois obtenir.
Une partie de ceci est sujette à interprétation, Donc ce n'est pas parfait par tous les moyens et YMMV.
EDIT: quelque chose à considérer est que certains les systèmes peuvent avoir plusieurs frontaux ou back-ends. Par exemple, un système de gestion de contenu aura probablement un moyen pour les visiteurs du site pour afficher le contenu qui est un front-end, mais comment les éditeurs de contenu sont en mesure de modifier les données sur le site? La capacité d'extraire ces données pourrait être considérée comme front-end puisqu'il s'agit d'un composant de L'interface utilisateur ou comme un back-end puisqu'elle est utilisée par les utilisateurs internes plutôt que par le grand public qui consulte le site. Ainsi, il y a quelque chose à dire pour contexte ici.
D'une manière générale, les gens se réfèrent à la couche de présentation d'une application comme son frontal , sa couche de persistance (base de données, généralement) comme back end , et tout ce qui se trouve entre niveau intermédiaire . Cet ensemble d'idées est souvent appelé architecture à 3 niveaux. Ils vous permettent de séparer votre application en plus facilement compréhensible (et testable!) morceaux; 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 un peu subjectif; les graphistes ont tendance à penser à tout ce qui n'est pas la présentation comme le back-end, les gens de la base de données pensent à tout ce qui se trouve devant la base de données comme le front-end, et ainsi de suite.
Cependant, toutes les applications ne doivent 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 l'index.php et get cracking; en fonction de (1) Combien de temps vous attendez à avoir à maintenir l'application (2) Comment complexe vous attendez l'application pour obtenir, vous pouvez souhaitez renoncer à la complexité.
Il y a en fait 3 questions dans votre question :
- Définir frontend, milieu et back end
- Comment et quand se chevauchent-ils ?
- leurs goulets d'étranglement habituels associés.
Ce que JB King a décrit est correct, mais c'est une version particulière et simple, où en fait il a mappé front, middle et bacn à 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 DB directs dans une vue.
Cependant, dans les applications web réelles et complexes, vous avez en effet deux ou trois couches différentes, appelées front, middle et back. 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 doit pas être confondu 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 Plateforme de e-commerce (Magento, etc.)
Le milieu n'est pas obligatoire et c'est là que se trouve la logique métier. Il sera basé sur un PIM, un outil MDM, ou une sorte de base de données personnalisée où vous enrichissez vos produits ou vos articles (pour CMS). Ce sera également l'endroit où vous coderez des fonctions commerciales qui doivent être partagées entre différentes interfaces (par exemple entre l'interface PC et L'application mobile basée sur L'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. Il peut s'agir de jsut L'API wrting et la lecture de votre ERP. Il peut s'agir de votre fournisseur DB, si vous faites du commerce électronique. En fait, cela dépend vraiment des projets web, mais c'est toujours un référentiel central. Il sera accessible via un appel DB, via une API, une couche Hibernate ou une application back-end complète
Cette description signifie que répondre aux 2 autres questions est pas possible dans ce thread, 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), peut-être que le modèle MVC n'était pas encore si largement adopté. Maintenant, il n'y a absolument aucune raison pour laquelle le modèle MVC ne serait pas suivi et une vue serait liée aux appels DB. Si vous lisez la question "y a-t-il des cas où ils doivent se chevaucher et que frontend/backend ne peuvent pas être séparés?"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 besoin de tirer des données externes ou d'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. Veuillez noter quirk intéressant que vous pouvez avoir deux frontaux différents associés à un seul backend
- Backend fournit la logique métier/persistance des données.
- Middleware (activemq dans l'image) est responsable de système à système. intégration entre backends. Habituellement il est installé comme séparé application
Chevauchement:
Il est possible d'avoir un chevauchement entre frontend et backend. Cela conduit généralement à des problèmes à long terme avec la maintenance des applications et l'évolutivité. Assez commun dans les applications héritées.
La plupart des piles technologiques modernes encouragent les développeurs à avoir une séparation stricte. Par exemple dans l'image vous pouvez voir que le backend du premier système a le service web rest qui est une séparation claire ligne.
Goulets d'Étranglement
La plupart des goulots d'étranglement dans les grands sont causés par la base de données / 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 a le potentiel d'être lente. Avec une bonne conception de l'application, ces problèmes sont évitables à grande échelle.
En termes de réseau et de sécurité, le Backend est de loin le nœud le plus (devrait être) sécurisé.
La partie intermédiaire, généralement un serveur web, sera quelque peu à l'état sauvage et coupée à bien des égards du réseau d'une entreprise. Le nœud intermédiaire est généralement placé dans la zone démilitarisée et segmenté à partir du réseau avec les paramètres du pare-feu. La plupart de l'analyse de code côté serveur des pages web est gérée sur le serveur web intermédiaire.
Arriver au backend signifie passer par le milieu, qui a un ensemble soigneusement conçu de règles permettant / interdisant l'accès aux nummies vitales qui sont stockées sur le serveur de base de données (backend).