Réflexion et pratique de la séparation front-end et back-end basée sur NodeJS (2) Modèle exploration_node.js

Avant-propos

Lors de la séparation front-end et back-end, le premier problème auquel nous prêtons attention est le rendu, qui est le travail au niveau de la vue.

Dans le modèle de développement traditionnel, le côté navigateur et le côté serveur sont développés par des équipes front-end et back-end différentes, mais le modèle se situe dans la zone floue entre les deux. Par conséquent, il est inévitable qu’une logique de plus en plus complexe soit ajoutée au modèle, qui finira par devenir difficile à maintenir.

Et nous avons choisi NodeJS comme couche intermédiaire entre le front et le back end. Essayer d'utiliser NodeJS pour rationaliser le travail au niveau de la vue.

Rendre la division du travail entre le front et le back-end plus claire, permettant au projet d'être mieux maintenu et d'obtenir une meilleure expérience utilisateur.

Cet article

Le rendu représente une très grande partie du travail quotidien des développeurs front-end, et c'est aussi le domaine où il est le plus susceptible d'être mêlé au développement back-end.

En regardant le développement de la technologie front-end au cours des dernières années, le travail au niveau View a connu de nombreux changements, tels que :

Actualisation complète de la page de soumission du formulaire => Actualisation partielle AJAX
Rendu côté serveur MVC => Rendu côté client MVC
Saut de changement de page traditionnel => Application d'une seule page
On peut observer que depuis quelques années, tout le monde a tendance à déplacer le rendu du côté serveur vers le côté navigateur.

Le côté serveur se concentre sur la servitisation et fournit des interfaces de données.

Avantages du rendu côté navigateur

Nous connaissons tous les avantages du rendu côté navigateur, tels que

1. Débarrassez-vous du couplage et de la confusion entre la logique métier et la logique de présentation dans le moteur de modèles Java.
2. Pour les applications multiterminaux, l'interface est plus facile. Utilisez différents modèles côté navigateur pour présenter différentes applications.
3. Le rendu de page n'est pas seulement HTML. Le rendu frontal peut plus facilement fournir des fonctions sous forme de composants (html js css), de sorte que les composants frontaux n'ont pas besoin de s'appuyer sur la structure HTML générée par le serveur.
4. Débarrassez-vous des processus de développement et de publication back-end.
5. Faciliter le débogage commun.

Inconvénients causés par le rendu côté navigateur

Mais tout en profitant des avantages, nous sommes également confrontés aux inconvénients apportés par le rendu côté navigateur, tels que :

1. Les modèles sont séparés en différentes bibliothèques. Certains modèles sont placés côté serveur (JAVA), tandis que d'autres sont placés côté navigateur (JS). Les langages de modèles front-end et back-end ne sont pas connectés.
2. Vous devez attendre que tous les modèles et composants soient chargés dans le navigateur avant que le rendu puisse commencer, et vous ne pouvez pas les afficher immédiatement.
3. Lors de la première connexion, un écran blanc attendra le temps de rendu, ce qui n'est pas propice à l'expérience utilisateur
4. Lors du développement d'une application monopage, la route frontale et la route côté serveur ne correspondent pas, ce qui est très difficile à gérer.
5. Le contenu important est assemblé sur le front-end, ce qui n'est pas propice au référencement

Réfléchissez à la définition du front-end et du back-end

En fait, en y repensant, lorsque nous avons déplacé le travail de rendu du côté serveur (Java) vers le côté navigateur (JS), notre objectif était simplement de diviser clairement les responsabilités front-end et back-end, et cela a été le cas. cela ne veut pas dire que le rendu du navigateur était indispensable.

Tout simplement parce que dans le modèle de développement traditionnel, après avoir quitté le serveur, il va vers le navigateur, de sorte que le contenu du travail front-end ne peut être limité qu'au côté navigateur.

Pour cette raison, beaucoup de gens pensent que back-end = côté serveur et front-end = côté navigateur, tout comme l'image ci-dessous.

Dans le projet Midway actuellement mené par Taobao UED, en construisant une couche intermédiaire NodeJS entre JAVA et Browser, nous essayons de redéfinir la ligne de démarcation entre le front et le back end en fonction des responsabilités professionnelles plutôt que de l'environnement matériel. Pour différencier (serveur & navigateur).

Nous avons donc la possibilité de partager des modèles et des itinéraires, ce qui est également l'état le plus idéal dans la division du travail entre le front et le back-end.

Taobao Midway Midway

Dans le projet Midway, nous avons déplacé la ligne qui sépare les extrémités avant et arrière du côté navigateur vers le côté serveur.

Avec une couche Nodejs facilement contrôlée par le front-end et commune avec le navigateur, la séparation front-end et back-end peut être réalisée plus clairement.

Vous pouvez également laisser les développeurs front-end décider de la solution la plus appropriée pour différentes situations. Plutôt que tout soit géré du côté du navigateur.

Répartition des responsabilités

Midway n'est pas un projet front-end essayant de voler les tâches back-end. Le but est simplement de traverser la zone floue des modèles et d'obtenir une répartition plus claire des responsabilités.

Backend (JAVA), axé sur
1. Couche de service
2. Format des données et stabilité des données
3.Logique métier

Front-end, concentrez-vous sur
1.Couche UI
2. Logique de contrôle et logique de rendu
3. Interaction et expérience utilisateur

Ne vous en tenez plus à la différence entre le côté serveur et le côté navigateur.

Partage de modèles

Dans le modèle de développement traditionnel, le côté navigateur et le côté serveur sont développés par des équipes front-end et back-end différentes, mais le modèle se situe dans la zone floue entre les deux. Par conséquent, il est inévitable qu’une logique de plus en plus complexe soit ajoutée au modèle, qui finira par devenir difficile à maintenir.

Avec NodeJS, les étudiants back-end peuvent se concentrer sur le développement de la logique métier et des données au niveau de la couche JAVA. Les étudiants front-end se concentrent sur le développement de la logique de contrôle et du rendu. Et vous pouvez choisir si ces modèles doivent être rendus côté serveur (NodeJS) ou côté navigateur.

Utilisation du même langage de modèle XTemplate et du même moteur de rendu JavaScript

Rendez le même résultat dans différents environnements de rendu (côté serveur, navigateur PC, navigateur mobile, vue Web, etc.).

Partage d'itinéraire

Grâce à la couche NodeJS, le routage peut être contrôlé plus en détail.

Si vous devez effectuer un routage côté navigateur sur le front-end, vous pouvez configurer le routage côté serveur en même temps afin d'obtenir un effet de rendu cohérent lors du changement de page côté navigateur ou du changement de page côté serveur.

Parallèlement, les problématiques SEO ont également été traitées.

Pratique du partage de modèles

Habituellement, lorsque nous rendons un modèle côté navigateur, le processus n'est rien de plus que

Chargez le moteur de template (xtmpleate, juicer, handlerbar, etc.) dans le navigateur
Chargez le fichier modèle dans le navigateur, la méthode peut être
Utilisez Utilisez les outils de chargement de modules pour charger les fichiers modèles (KISSY, requireJS, etc.)
Autres
Obtenez des données et utilisez le moteur de modèles pour générer du HTML
Insérez du HTML à l'emplacement spécifié.
Il ressort du processus ci-dessus que pour parvenir à un partage croisé des modèles, l'accent est en fait mis sur une sélection cohérente des modules.

Il existe de nombreuses normes de modules populaires sur le marché, telles que KMD, AMD et CommonJS. Tant que le fichier modèle NodeJS peut être généré côté NodeJS via des spécifications de module cohérentes, le partage de modèles de base peut être effectué.

La série d'articles suivante discutera plus en détail du proxy et du partage de Model.

Étude de cas

En raison de la couche intermédiaire de l'île Midway, certains problèmes du passé ont été mieux résolus, comme

Cas 1 Application interactive complexe (telle que panier, page de commande)

Statut : tout le HTML est rendu sur le front-end et le serveur ne fournit que des interfaces.

Problème : Lorsque vous entrez dans la page, un bref écran blanc apparaîtra.
Réponse :
Lorsque vous entrez dans la page pour la première fois, effectuez un rendu pleine page côté NodeJS et téléchargez les modèles pertinents en arrière-plan.
Les opérations interactives ultérieures sont complétées côté navigateur avec une actualisation partielle
Utiliser le même modèle produit les mêmes résultats

Cas 2 Demande d'une seule page

Statut : utilisez le framework MVC côté client pour modifier les pages dans le navigateur.

Problème : Le rendu et le changement de page s'effectuent côté navigateur. Lors de la saisie directe de l'URL ou de l'actualisation avec f5, le même contenu ne peut pas être affiché directement.
Réponse :
Partagez les mêmes paramètres de Route côté navigateur et côté NodeJS
Lorsque vous changez de page côté navigateur, effectuez les modifications d'itinéraire et le rendu du contenu de la page côté navigateur
Lorsque la même URL est saisie directement, le cadre de la page et le contenu de la page sont rendus côté NodeJS
Que vous modifiiez la page côté navigateur ou que vous saisissiez directement la même URL, le contenu que vous voyez est le même.
En plus d'augmenter l'expérience et de réduire la complexité logique. Cela résout également le problème du référencement

Cas 3 Page de navigation pure

Statut : La page fournit uniquement des informations, avec peu ou pas d'interaction

Problème : le HTML est généré côté serveur, CSS et JS sont placés à un autre emplacement et ils dépendent l'un de l'autre.
Réponse :
Grâce à NodeJS, gestion unifiée du html css js
Si vous devez ultérieurement l'étendre à une application complexe ou à une application d'une seule page, elle peut être facilement transférée.

Cas 4 Page inter-terminaux

Situation : la même application doit présenter différentes interfaces et interactions sur différents points de terminaison

Problème : la gestion du HTML n'est pas facile. Un HTML différent est souvent généré côté serveur, et un traitement différent est requis côté navigateur
Réponse :
Les pages inter-terminaux posent un problème de rendu et sont gérées uniformément par le front-end.
Grâce à la couche NodeJS et à la servitisation back-end, la meilleure solution peut être conçue pour ce type d'applications complexes.

Résumé

L'émergence d'AJAX, de MVC côté client, de SPA, de liaison de données bidirectionnelle et d'autres technologies dans le passé étaient autant de tentatives pour résoudre les goulots d'étranglement rencontrés dans le développement front-end à cette époque.

L'émergence de la couche intermédiaire NodeJS est également une tentative de résoudre une limitation du front-end actuel étant limité au côté navigateur.

Cet article se concentre sur le partage de modèles front-end et back-end, et j'espère qu'il pourra inspirer d'autres à discuter de la façon dont nous pouvons améliorer notre flux de travail et comment coopérer avec le back-end sous l'architecture de couche intermédiaire NodeJS. -end fait un meilleur travail.