Réflexion et pratique de la séparation front-end et back-end basée sur NodeJS (1) Full-stack development_node.js

Avant-propos

Afin de résoudre divers problèmes causés par le modèle de développement Web traditionnel, nous avons fait de nombreuses tentatives, mais en raison de l'écart physique entre le front-end et le back-end, les solutions essayées sont toutes similaires. Après avoir tiré les leçons de cette expérience douloureuse, nous repensons aujourd'hui la définition de « front-end et back-end », introduisons NodeJS, familier aux étudiants front-end, et essayons d'explorer un nouveau modèle de séparation front-end et back-end. .

Avec l'essor des différents terminaux (Pad/Mobile/PC), les exigences des développeurs sont de plus en plus élevées. La réactivité pure côté navigateur ne peut plus répondre aux exigences élevées de l'expérience utilisateur. Bornes. Version personnalisée. Afin d'améliorer l'efficacité du développement, la nécessité de séparer le front-end et le back-end fait l'objet de plus en plus d'attention. Le back-end est responsable de l'interface métier/données, et le front-end est responsable de l'affichage/. logique d’interaction. Nous pouvons personnaliser et développer plusieurs versions de la même interface de données.

Ce sujet a été beaucoup abordé ces derniers temps, et certaines BU d'Alibaba font également quelques tentatives. Après une longue discussion, notre équipe a décidé d'explorer une solution de séparation front-end et back-end basée sur NodeJS. Au cours du processus, nous avons eu des compréhensions et des réflexions changeantes, qui sont enregistrées ici. Nous espérons également que les camarades de classe pourront le voir. participera à la discussion et nous aidera à l’améliorer.

1. Qu'est-ce que la séparation front-end et back-end ?

Lors de la discussion initiale au sein du groupe, j'ai constaté que chacun avait une compréhension différente de la séparation du front-end et du back-end. Afin de garantir que la discussion puisse être discutée dans le même canal, nous devons d'abord atteindre. un accord sur ce qu'est la « séparation du front-end et du back-end ».

L'exemple de séparation front-end et back-end sur lequel tout le monde s'accorde est le SPA (Single-page application). Toutes les données d'affichage utilisées sont fournies par le back-end via une interface asynchrone (AJAX/JSONP). le front-end ne fait que l'afficher.
Dans un sens, SPA parvient effectivement à séparer le front-end et le back-end, mais cette approche pose deux problèmes :

Parmi les services WEB, le SPA représente une faible proportion. Dans de nombreux scénarios, il existe des modes mixtes synchrone/synchrone et asynchrone, et SPA ne peut pas être utilisé comme solution universelle.
Dans le modèle de développement SPA actuel, les interfaces sont généralement fournies sur la base d'une logique de présentation. Parfois, afin d'améliorer l'efficacité, le backend nous aide à gérer une certaine logique de présentation, ce qui signifie que le backend est toujours impliqué dans le travail de la couche View, ce qui signifie que le backend est toujours impliqué dans le travail de la couche View. n’est pas réel. La séparation des extrémités avant et arrière.
La séparation de style SPA du front-end et du back-end est basée sur la couche physique (on pense que tant qu'il s'agit du client, c'est le front-end et que le côté serveur est le back-end) . Cette division ne peut plus répondre à nos besoins de séparation front-end et back-end. Nous pensons que la division des responsabilités peut être réalisée. Répondez à nos scénarios d'utilisation actuels :

.

Front end : responsable des couches View et Controller.
Backend : uniquement responsable de la couche Modèle, des traitements/données métier, etc.
La raison de cette répartition des responsabilités sera discutée plus loin.

2. Pourquoi les extrémités avant et arrière doivent-elles être séparées ?

Concernant cette question, l'article de Yu Bo L'évolution du modèle de R&D Web l'explique de manière très complète :

2.1 Scénarios applicables des modèles de développement existants

Les différents modèles de développement mentionnés par Oncle Yu ont chacun leurs propres scénarios applicables, et aucun ne remplace complètement l'autre.

Par exemple, MVC, qui se concentre sur le backend, est très efficace pour effectuer certaines activités d'affichage synchrone. Cependant, lorsqu'il s'agit de pages combinant synchrone et asynchrone, il sera plus difficile de communiquer avec le développement backend.
Ajax est le principal modèle de développement SPA, qui est plus adapté aux scénarios de développement d'applications, mais il ne convient qu'aux applications car des problèmes tels que le référencement sont difficiles à résoudre. Pour de nombreux types de systèmes, cette méthode de développement est trop lourde.
2.2 Responsabilités peu claires du front-end et du back-end

Dans un système avec une logique métier complexe, nous avons le plus peur de maintenir un code mélangé avec le front-end et le back-end. Parce qu'il n'y a pas de contraintes, chaque couche de M-V-C peut avoir des codes d'autres couches au fil du temps. il n'y a aucune maintenabilité du tout.
Bien que la séparation du front-end et du back-end ne puisse pas résoudre complètement ce problème, elle peut être grandement atténuée. Parce qu'il est physiquement garanti que vous ne pouvez pas faire cela.

2.3 Problèmes d'efficacité du développement

Le Web de Taobao est essentiellement basé sur le framework MVC webx. L'architecture détermine que le front-end ne peut s'appuyer que sur le back-end.
Par conséquent, notre modèle de développement consiste toujours à écrire une démo statique sur le front-end et à la traduire en modèle de VM sur le back-end. Je n'entrerai pas dans les problèmes de ce modèle, qui a longtemps été critiqué.
Il est également pénible de développer directement à partir de l'environnement back-end, et il est difficile à configurer, à installer et à utiliser. Afin de résoudre ce problème, nous avons inventé divers outils, tels que VMarket, mais le front-end doit toujours écrire une VM et s'appuie sur les données du back-end, donc l'efficacité n'est toujours pas élevée.
De plus, le backend ne peut pas se débarrasser de sa forte concentration sur la présentation et se concentrer sur le développement de la couche de logique métier.

2.4 Limites des performances frontales

Si l'optimisation des performances se fait uniquement sur le front-end, l'espace est très limité, nous avons donc souvent besoin d'une coopération back-end pour obtenir des étincelles. Cependant, en raison des limites du framework back-end, cela nous est difficile. d'utiliser des solutions techniques telles que Comet et Bigpipe pour optimiser les performances.

Afin de résoudre certains des problèmes mentionnés ci-dessus, nous avons fait de nombreuses tentatives et développé divers outils, mais il n'y a jamais eu beaucoup d'amélioration, principalement parce que nous ne pouvons utiliser que le petit espace qui nous est alloué sur le jeu backend. Ce n'est qu'en séparant véritablement l'avant et l'arrière que nous pourrons résoudre complètement les problèmes ci-dessus.

3. Comment séparer les extrémités avant et arrière ?

Comment séparer les extrémités avant et arrière ? En fait, la réponse est déjà dans la première section :

Front end : responsable des couches View et Controller.
Backend : responsable de la couche Modèle, du traitement/données métier, etc.

Imaginez, si le front-end maîtrise le contrôleur, nous pouvons faire la conception d'URL. Nous pouvons décider de rendre le rendu de manière synchrone côté serveur en fonction de la scène, ou générer des données json basées sur les données de la couche de vue. Nous pouvons également facilement faire Bigpipe. , Comet, etc. en fonction des besoins de la couche de présentation Socket et ainsi de suite, il est entièrement basé sur la demande qui détermine comment l'utiliser.

3.1 Développement « Full-stack » basé sur NodeJS

Si nous voulons réaliser la superposition dans l'image ci-dessus, nous aurons certainement besoin d'un service Web pour nous aider à réaliser ce que nous faisons sur le front et le back-end, il y a donc le "développement full-stack basé sur NodeJS" mentionné dans le titre

Cette image semble simple et facile à comprendre, mais si vous ne l’avez pas essayée, vous vous poserez de nombreuses questions.

En mode SPA, le backend fournit déjà l'interface de données requise et le frontend de vue peut déjà être contrôlé. Pourquoi ajouter une couche supplémentaire de NodeJS ?
Quelle est la performance de l’ajout d’une couche supplémentaire ?
En ajoutant une couche supplémentaire, la charge de travail front-end augmentera-t-elle ?
Ajouter plus de couches signifie plus de risques. Comment le briser ?
NodeJS peut tout faire, pourquoi avez-vous besoin de JAVA ?
Il n’est pas facile d’expliquer clairement ces problèmes. Permettez-moi de parler de mon processus de compréhension ci-dessous.

3.2 Pourquoi ajouter une couche de NodeJS ?

À ce stade, nous développons principalement dans le modèle back-end MVC. Ce modèle entrave sérieusement l'efficacité du développement front-end et empêche le back-end de se concentrer sur le développement commercial.
La solution consiste à permettre au front-end de contrôler la couche contrôleur, mais cela est difficile à faire avec le système technique existant, car il est impossible pour tous les front-ends d'apprendre Java, d'installer un environnement de développement back-end et écrire des machines virtuelles.
NodeJS peut très bien résoudre ce problème. Nous n’avons pas besoin d’apprendre un nouveau langage, nous pouvons faire ce que les développeurs précédents ont fait pour nous, et tout semble si naturel.

3.3 Problèmes de performances

La superposition implique une communication entre chaque couche, et il y aura certainement une certaine perte de performances. Cependant, une hiérarchisation raisonnable peut clarifier les responsabilités et faciliter la collaboration, ce qui améliorera considérablement l’efficacité du développement. Les pertes causées par la stratification seront certainement compensées par des gains dans d’autres domaines.
De plus, une fois que nous décidons de superposer, nous pouvons minimiser les pertes autant que possible en optimisant les méthodes et protocoles de communication.

Par exemple :
Une fois la page de détails de Taobao Baby rendue statique, il reste encore de nombreuses informations à obtenir en temps réel, telles que la logistique, les promotions, etc. Étant donné que ces informations se trouvent dans différents systèmes commerciaux, le front-end doit envoyer 5 soit 6 requêtes asynchrones pour renseigner le contenu.
Avec NodeJS, le front-end peut proxy ces cinq requêtes asynchrones dans NodeJS et peut facilement créer Bigpipe. Cette optimisation peut grandement améliorer l'efficacité globale du rendu.
Peut-être pensez-vous qu'il est acceptable d'envoyer 5 ou 6 requêtes asynchrones sur un PC, mais côté sans fil, il est très coûteux d'établir une requête HTTP sur le téléphone mobile du client. Avec cette optimisation, les performances peuvent être améliorées plusieurs fois.

Détails de Taobao : Nous sommes en train d'optimiser Taobao basé sur NodeJS. Je partagerai le processus d'optimisation après sa mise en ligne.

3.4 La charge de travail front-end a-t-elle augmenté ?

Par rapport au simple fait de couper des pages/faire des démos, cela ajoute certainement un petit peu, mais dans le modèle actuel, il existe des liens communs de débogage et de communication. Ce processus prend beaucoup de temps, est sujet aux bugs et est difficile à maintenir.
Par conséquent, même si la charge de travail augmentera légèrement, l’efficacité globale du développement sera considérablement améliorée.

De plus, le coût des tests peut être considérablement économisé. Les interfaces développées précédemment étaient toutes destinées à la couche de présentation, ce qui rendait difficile l'écriture de cas de test. Si le front-end et le back-end sont séparés, même les tests peuvent être séparés. Un groupe de personnes se concentrera sur les tests de l'interface, et un autre groupe de personnes se concentrera sur les tests de l'interface utilisateur (cette partie du travail peut même être remplacée). par des outils).

3.5 Comment contrôler les risques liés à l'ajout d'une couche Node ?

Avec l'utilisation à grande échelle de Node, les étudiants du département système/exploitation et maintenance/sécurité se joindront certainement à la construction de l'infrastructure. Ils nous aideront à améliorer les problèmes possibles dans chaque lien et à assurer la stabilité du système.

3.6 Node peut tout faire, pourquoi avez-vous besoin de JAVA ?

Notre intention initiale est de séparer les extrémités avant et arrière. Si nous considérons ce problème, cela irait à l'encontre de notre intention initiale. Même si Node est utilisé pour remplacer Java, nous ne pouvons garantir que divers problèmes rencontrés aujourd'hui ne se produiront pas, tels que des responsabilités floues. Notre objectif est de nous développer par étapes, avec des professionnels se concentrant sur leurs tâches professionnelles. L'infrastructure basée sur JAVA est déjà très puissante et stable, et est plus adaptée à l'architecture actuelle.

4. Séparation front-end et back-end de Taobao basée sur Node

L'image ci-dessus représente ma compréhension de la séparation et de la superposition front-end et back-end de Taobao basées sur Node, ainsi que de l'étendue des responsabilités de Node. Brève explication :

Le haut de gamme est le serveur, que nous appelons souvent le backend. Pour nous, le backend est un ensemble d’interfaces et le serveur fournit une variété d’interfaces que nous pouvons utiliser. Puisqu’il existe une couche Node, il n’est pas nécessaire de limiter la forme de service dont il s’agit. Pour le développement back-end, ils utilisent uniquement des implémentations d’interface qui se soucient du code métier.
Sous le serveur se trouve l'application Node.
Il existe une couche de Model Proxy dans l'application Node pour communiquer avec le serveur. Cette couche sert actuellement principalement à lisser la façon dont nous appelons différentes interfaces et à encapsuler certains modèles requis par la couche de vue.
La couche Node peut également facilement réaliser les vmcommon, tms (en référence au système de gestion de contenu Taobao) d'origine et d'autres exigences.
C'est au développeur de décider quel framework utiliser pour la couche Node. Cependant, il est recommandé d'utiliser la combinaison de xTemplate express qui peut être partagée entre le front-end et le back-end.
Tout le monde décide comment utiliser Node, mais ce qui est passionnant, c'est que nous pouvons enfin utiliser Node pour obtenir facilement la méthode de sortie souhaitée : JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/synchronous, asynchrone, comme vous le souhaitez. l'ajuster dépend entièrement de votre scène.
La couche navigateur n'a pas changé dans notre architecture et nous n'espérons pas que l'introduction de Node modifiera votre compréhension antérieure du développement dans le navigateur.
L'introduction de Node place simplement le contrôle frontal sur les parties qui doivent être contrôlées par le front-end.
Nous avons déjà deux projets en cours de développement avec ce modèle, même s'il n'est pas encore lancé, nous avons déjà goûté aux bénéfices en termes d'efficacité de développement et d'optimisation des performances.

5. Que devons-nous faire d'autre ?

Intégrez le processus de développement de Node dans le processus SCM existant de Taobao.
Construction d'infrastructures, telles que session, enregistreur et autres modules communs.
Meilleures pratiques de développement
Histoires de réussite en ligne
Compréhension de tous le concept de séparation front-end et back-end dans Node
Coffre-fort
Performances
…
Il n’y a pas grand chose à innover et à faire des recherches techniques, et il existe déjà beaucoup d’accumulation toute faite. En fait, la clé est de clarifier certains processus et d'accumuler des solutions communes. Je pense qu'avec davantage de pratique de projet, cela deviendra progressivement un processus stable.

6. "À mi-chemin"

Bien que le modèle de « développement full-stack basé sur NodeJS » soit très excitant, il reste encore un long chemin à parcourir pour transformer le développement full-stack basé sur Node en quelque chose de stable et acceptable pour tout le monde. Le projet « Midway » a été conçu pour résoudre ce problème. Même si nous venons tout juste de commencer, nous nous rapprochons de plus en plus de notre objectif ! !