Pourquoi les grands sites Web utilisent-ils différentes langues pour le backend et le frontend?
D'après ce que je comprends des petites applications MVC, vous avez le front-end, qui traite de HTML, JS, jQuery, etc., et vous avez le back-end, qui se compose de vos contrôleurs et modèles.
Cependant, lorsque je parle à des développeurs de grandes entreprises, ils mentionnent souvent avoir un niveau frontend et un niveau backend. Donc, parfois, j'entends peut-être qu'ils ont un frontend avec C # et un backend avec Java. Pourquoi une entreprise voudrait-elle un backend et un frontend dans différentes langues? Est-ce que cela aide mieux le site Web à grande échelle?
Lorsque les gens disent que leur frontend est construit en C #, cela signifie-t-il qu'ils utilisent un framework pour le frontend (comme .NET) et un framework supplémentaire sur le backend (comme Spring)? Ou cela signifie-t-il quelque chose de complètement différent?
"Front-end" et "Back-end" peuvent être des termes nébuleux, en particulier dans les applications d'entreprise. "Front-end" peut signifier l'interface utilisateur, ou ce peut être l'application entière. "Back-end" peut être utilisé pour désigner les internes, ou ce peut être la base de données ou les services externes qui sont consommés. La signification de ces termes dépend souvent entièrement de qui vous parlez. Alors, vous avez peut-être demandé "hé, qu'est-ce que tu veux dire par là?"
Lorsque vous entrez dans le développement d'une grande entreprise, vous allez avoir beaucoup et beaucoup d'équipes écrit beaucoup et beaucoup de code. Ces équipes se développeront dans différentes langues, en utilisant différents paradigmes, à partir de différents endroits. Une partie de ce code devra fonctionner ensemble et une grande partie ne le sera pas.
Je travaille pour une grande banque. Mon équipe développe notre application en C #. Tout cela. Mais nous consommons des services Web qui sont largement écrits en Java, et ces services parlent à d'autres services qui parlent à d'autres services qui transfèrent les données de compte vers et depuis les magasins de données appropriés, et - qui sait quelles langues sont utilisées avec celles-ci.
Version courte: les gens utilisent les outils qui font le travail.
Je pense que vous devez élargir un peu la question: pourquoi les grands projets logiciels utilisent-ils plus d'un langage de programmation?
Il existe de nombreuses réponses possibles, les plus notables étant:
- Les grandes applications se composent de nombreuses pièces relativement indépendantes; souvent, chaque pièce est construite par une équipe différente ou même un entrepreneur externe différent. L'avantage de choisir la meilleure offre est souvent plus important que l'avantage d'avoir tout dans la même langue.
- Les langues vont et viennent, et parfois une composante d'un grand système survit à l'écosystème. Un exemple dans le monde Microsoft est le nombre d'entreprises qui utilisent maintenant C # pour tous les nouveaux projets, mais elles ont toujours une base de code VB environ). Le coût de la réécriture d'un projet juste pour le plaisir de le faire dans le dernier langage de programmation n'est pratiquement jamais justifié.
- Interfaçage avec des composants tiers. Si votre écosystème C # doit effectuer une tâche spécifique pour laquelle seules des solutions Java existent, alors vous avez deux choix: implémentez la solution vous-même ou utilisez le Java solution et développez un peu de colle pour l'intégrer dans votre système. Ce dernier est presque toujours moins cher pour toute tâche non triviale.
Les considérations de performances ne sont pratiquement jamais la raison, sauf dans les applications extrêmement critiques comme le trading haute fréquence - dans ces domaines, il peut être avantageux d'écrire le moteur de base critique dans un langage avec de meilleures performances d'exécution (par exemple, C++), mais les systèmes de support (UI, reporting, etc.) dans quelque chose de niveau supérieur comme Java ou C #.
Il est relatif dans une grande entreprise.
Dans mon entreprise, la pile est à peu près
(html/javascript)--> (JSP on Tomcat and Java based WebCMS) -> (.Net SOA)
Ainsi, pour l'équipe de développement Web, le frontend est HTML/JS et le backend est Java. Pour l'entreprise, le frontend est Java et le backend est .Net.
En fait, la couche .Net doit fonctionner avec une application COBOL/UNIX pour la facturation et les réclamations. Dans cette perspective, .Net est donc frontend et COBOL est backend.
Et oui, comme d'autres l'ont mentionné, nous avons des équipes de concepteurs UX, de développeurs HTML/JS, Java devs, Web Middleware, .Net devs, SQL devs, COBOL devs travaillant à chaque partie de la pile.
En fait, dans toute entreprise suffisamment grande, ce sont des tortues jusqu'en bas.
Sémantique déroutante
C'est un problème de sémantique. Quand quelqu'un dit un front end .NET ou Java front end, ils parlent généralement de la personne qui connaît beaucoup les langages de modèles et peut-être des frameworks qui ne devraient plus jamais être utilisés comme les formulaires Web qui ont été utilisés pour essayer de cacher le glissement de choses sur un mur http (c.-à-d. "développement Web") aux développeurs d'applications qui ne voulaient pas ou du moins étaient supposés ne pas vouloir en savoir plus sur toutes ces conneries. de mixte .NET et Java, je ne suis pas sûr, mais je ne pouvais que deviner que dans le sens des choses MVC, ils ont Java agissant pour tous les trucs de modèle commercial et .NET gérant tout sinon qui serait mieux décrit comme "de niveau intermédiaire" mais c'est toujours du côté serveur.
La vraie séparation est ce qui se passe sur le serveur et ce qui se passe sur le client ou le navigateur. Vous pouvez facilement confondre la création du code HTML à envoyer ou la représentation du frontal avec le "développement frontal". Je préfère donc éviter toute confusion en utilisant les termes client et côté serveur plutôt que frontal et principal lorsque je discute de ce que je fais généralement, (travail généralement côté client).
Langues côté client
La raison pour laquelle nous utilisons le même ensemble de langues sur le navigateur est que le navigateur est du côté de la réception et pour la plupart (il y a maintenant une résistance majoritairement morte de Microsoft et d'Adobe à ce sujet), personne ne veut avoir à envoyer trois différentes versions du même côté client pour satisfaire chaque client potentiel ou nécessiter l'installation d'un plug-in propriétaire pour que le Web fonctionne. De plus, les trois langues résument assez bien les problèmes côté client, ce qui nous permet de créer et de modifier rapidement les frontaux des applications Web en maintenant un couplage lâche entre la structure du document, l'apparence de tout et la façon dont tout se comporte. Vous pouvez en changer un sans changer les deux autres assez facilement.
Langues côté serveur
La raison pour laquelle vous avez des milliards d'options sur le Web côté serveur est bien sûr parce que vous le pouvez. C'est votre serveur. Tout ce qu'il a à faire est de communiquer via http/ssl et le reste dépend de vous. JavaScript est désormais une option, mais cela soulève une question intéressante. Si vous traitez toujours une application Web comme s'il s'agissait en fait de deux applications de chaque côté de ce mur HTTP. Je suis d'avis éclairé par la douleur que oui, oui, vous devriez et j'aime Node.js.
En bref, lorsque vous avez de grands projets, vous avez également plusieurs équipes de développeurs travaillant sur le projet, et ces équipes ont tendance à se spécialiser sur différentes couches de l'application.
Si vous vous concentrez sur l'interface utilisateur Web et que vous avez la flexibilité dans votre choix d'implémentation, vous êtes beaucoup plus susceptible d'utiliser un langage ciblé sur l'interface utilisateur Web, tel que JScript ou Flex, plutôt que C #.
De même, si vous êtes à l'extrémité du magasin de données transactionnelles de l'application, traitant de nombreuses actions simultanées à la fois, les langages spécialisés tels que erlang ont tendance à être utilisés. (Ou des produits tiers qui sont implémentés en partie dans ces langues)
La raison en est l'équilibre des risques commerciaux.
Disons que vous êtes un employeur géant dans une ville. Vous devez embaucher beaucoup de développeurs pour créer de nombreux services différents. Disons que votre évaluation initiale est que la langue A convient le mieux à vos intérêts et que vous souhaitez commencer par elle.
Si vous vous engagez à une technologie, vous pourriez tarir le bassin de talents. Êtes-vous sûr de vouloir embaucher un gars de Langauge A décent quand il y a une star de Language B juste au coin de la rue? Et si demain les frameworks de Langauge A saisissaient pour être pris en charge par le développeur principal? Et si demain il y a une langue C incroyable, devriez-vous l'ignorer parce que vous vous êtes engagé en langue A il y a cinq ans?
Idéalement, ce que vous voulez, c'est un système hétérogène avec différentes langues qui reflète le bassin de talents actuel et les tendances technologiques. Vous souhaitez que cet équilibre évolue lentement à mesure que le bassin de talents et les tendances évoluent, de sorte qu'à tout moment tous vos systèmes sont opérationnels et que vous pouvez embaucher des personnes pour les maintenir.
... et c'est en quelque sorte ce que font les entreprises.
Il est utile de considérer votre serveur frontal et votre serveur principal comme des applications distinctes qui utilisent toutes deux la même source de données.
Même pour les petits sites, vous pouvez considérer le frontal comme étant l'interface avec laquelle le client et le back-end comme quelque chose comme un CMS. Celles-ci peuvent facilement être des applications MVC distinctes. Le front-end a toujours besoin de modèles et de contrôleurs pour fonctionner - après tout, le contrôleur est le point d'entrée pour les visiteurs de votre site et les modèles vont être la façon dont vous obtenez les données de votre base de données pour l'utilisateur.
J'ai tendance à aimer utiliser Django/Python comme CMS sur le back-end et utiliser Rails, CodeIgniter ou Spring MVC sur le front-end. Souvent, il n'y a pas le choix; le client a déjà un site hérité configuré dans une langue sur le front-end et il veut juste une solution CMS. La plupart des clients ne sauraient même pas que le CMS exécutait un langage ou un framework différent s'ils ne le savaient pas.
Il s'agit vraiment de trouver ce qui fonctionne le mieux pour le site que vous souhaitez créer. Les extrémités avant et arrière n'ont vraiment besoin que de partager la base de données, donc tant qu'elles peuvent travailler avec cela, n'hésitez pas à choisir les meilleures options pour la tâche à accomplir.
Un exemple de langage principal est PHP, qui est un langage de script. Lorsqu'une page PHP est demandée, le serveur lit le code PHP et rend le balisage. Le résultat est du HTML qui vous est envoyé. Vous, le Web visualiseur de page, ne voyez jamais une ligne de code PHP. En supposant que l'administrateur du serveur Web a fait son travail correctement, le serveur ne vous montrera et ne pourra jamais vous montrer le PHP code. Il est analysé lorsque la page est servie et le résultat de cette traduction de code est HTML.