Préface
Lors de la séparation des avant et de l'arrière, le premier problème auquel je fais attention est le rendu, c'est-à-dire travailler au niveau de la vue.
Dans le modèle de développement traditionnel, le navigateur et le serveur sont développés par deux équipes, à la fois avant et arrière, mais le modèle est dans la zone vague entre les deux. Par conséquent, il existe toujours des logiques de plus en plus complexes sur le modèle, qui sont finalement difficiles à entretenir.
Et nous avons choisi les Nodejs comme couche intermédiaire de l'avant et de l'arrière. Essayez d'utiliser NodeJS pour effacer les travaux au niveau de la vue.
Cela rend la division du travail entre les extrémités avant et arrière plus claire, rend le projet mieux entretenu et réalise une meilleure expérience utilisateur.
Cet article
Le travail de rendu est une très grande proportion du travail quotidien des développeurs frontaux, et c'est aussi la partie la plus facile à confondre avec le développement arrière.
En regardant en arrière sur les dernières années de développement de la technologie frontale, le travail au niveau de la vue a subi de nombreux changements, tels que:
Formulaire Soumettre une rafraîchissement pleine page => Ajax Rafraîchissement local
Suite côté serveur + MVC => Rendu côté client + MVC
Changement de page traditionnel Jump => Application de page unique
On peut observer que ces dernières années, tout le monde a eu tendance à déplacer cette chose de l'extrémité du serveur à l'extrémité du navigateur.
Le côté serveur se concentre sur le service et fournit des interfaces de données.
Avantages du rendu du navigateur
Nous connaissons tous les avantages du rendu côté navigateur, comme
1. Débarrassez-vous du couplage et de la confusion entre la logique métier et la logique de présentation dans le moteur du modèle Java.
2. Pour les applications multi-terminales, il est plus facile d'interfacer. Couplons différents modèles du côté du navigateur pour présenter différentes applications.
3. Le rendu de la page est non seulement HTML, mais le rendu sur le frontal peut facilement fournir des fonctions sous forme composante (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 de la dépendance des processus de développement et de distribution des back-end.
5. Réglage conjoint pratique.
Les inconvénients causés par le rendu du navigateur
Mais tout en profitant des avantages, nous sommes également confrontés aux inconvénients du rendu côté navigateur, comme:
1. Le modèle est séparé dans différentes bibliothèques. Certains modèles sont placés du côté serveur (Java), tandis que d'autres sont placés du côté du navigateur (JS). Les langages de modèle avant et arrière ne sont pas connectés.
2. Vous devez attendre que tous les modèles et composants soient chargés sur le navigateur avant de commencer, et vous ne pouvez pas le lire immédiatement.
3. Il y aura un écran blanc en attente de rendu pour la première fois, ce qui n'est pas propice à l'expérience utilisateur
4. Lors du développement d'une application à une seule page, l'itinéraire frontal ne correspond pas à l'itinéraire côté serveur, ce qui est très gênant à manipuler.
5. Tous les contenus importants sont assemblés à l'avant, ce qui n'est pas propice au SEO
Réfléchissez à la définition des extrémités avant et arrière
En fait, lorsque nous prenons les travaux de rendu du côté serveur (Java) du côté du navigateur (JS), notre objectif est de diviser clairement les responsabilités avant et arrière, et il n'est pas nécessaire de rendre le navigateur.
C'est simplement parce que dans le modèle de développement traditionnel, le serveur est libéré et que le navigateur est atteint, de sorte que le contenu de travail sur le frontal ne peut être limité qu'au côté navigateur.
Par conséquent, de nombreuses personnes ont déterminé que le côté backend = serveur Frontend = Browser, tout comme l'image ci-dessous.
Dans le projet Midway Midway actuellement en cours par Taobao UED, en construisant une couche moyenne nodejs au milieu du navigateur Java, nous essayons de différencier à nouveau la ligne de division avant et arrière pour les responsabilités de travail, plutôt que pour les environnements matériels (serveur et navigateur).
Par conséquent, nous avons la possibilité de partager des modèles et des itinéraires, qui est également l'État le plus idéal en front-end et back-end Division of Labor.
Taobao à mi-chemin
Dans le projet Midway, nous avons déplacé la ligne qui délimite les extrémités avant et arrière du navigateur vers le côté serveur.
Avec une couche NodeJS facilement contrôlée par le frontal et commun au navigateur, la séparation frontale peut être terminée plus clairement.
Il est également possible de permettre au développement frontal de décider de la solution la plus appropriée pour différentes situations. Au lieu que tout soit manipulé du côté du navigateur.
Diviser les responsabilités
Midway n'est pas un projet que le front-end essaie de saisir le travail arrière. Le but est de réduire clairement la zone vague du modèle et d'obtenir une division plus claire des responsabilités.
Backend (java), en se concentrant sur
1. Couche de service
2. Format de données et stabilité des données
3. Logique commerciale
Front-end, concentrez-vous sur
1.Ui couche
2. Contrôle la logique, rendu logique
3. Interaction, expérience utilisateur
Et ne s'en tiennent plus aux différences entre le serveur ou le côté navigateur.
Partage de modèle
Dans le modèle de développement traditionnel, le navigateur et le serveur sont développés par deux équipes, à la fois avant et arrière, mais le modèle est dans la zone vague entre les deux. Par conséquent, il existe toujours des logiques de plus en plus complexes sur le modèle, qui sont finalement difficiles à entretenir.
Avec NodeJS, les étudiants backend peuvent se concentrer sur le développement de la logique commerciale et des données dans la couche Java. Les étudiants frontaux se concentrent sur le développement de la logique de contrôle et du rendu. Et vous pouvez choisir ces modèles vous-même pour rendre du côté serveur (NodeJS) ou du côté navigateur.
Utilisation du même modèle de langue 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 de routage
En raison également de la couche NodeJS, vous pouvez contrôler le routage plus attentivement.
Si vous devez effectuer un routage côté navigateur sur le frontal, vous pouvez configurer le routage côté serveur en même temps afin qu'il puisse modifier des pages sur le côté du navigateur ou les pages sur le côté du serveur et que vous pouvez obtenir un effet de rendu cohérent.
Dans le même temps, le problème du référencement a également été traité.
La pratique du partage de modèles
Habituellement, lorsque nous rendons un modèle sur le navigateur, le processus n'est rien de plus que
Entrez le moteur de modèle dans le navigateur (XTMPLEAT, Juicer, Garniderbar, etc.)
Chargez des archives de modèle du navigateur, la méthode peut être
Imprimez sur la page en utilisant <script type = "js / tpl"> ... </cript>
Utilisez l'outil de chargement du module pour charger les archives du modèle (Kissy, requirejs, etc.)
autre
Obtenez des données et utilisez le moteur de modèle pour générer du HTML
Insérez HTML dans l'emplacement spécifié.
Le processus ci-dessus peut être vu que si vous souhaitez réaliser un partage croisé des modèles, l'accent est en fait mis sur la 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 l'archive du modèle NodeJS peut être sortie à l'extrémité NodeJS via des spécifications cohérentes du module, le partage de modèle de base peut être effectué.
La série d'articles ultérieures discutera davantage du proxy et du partage du modèle.
Discussion de cas
En raison de la couche intermédiaire de l'île Midway, il y a de meilleures réponses à certaines questions passées, telles que
Cas 1 Applications interactives complexes (telles que le panier, page de commande)
Statut: Tous les HTML sont rendus sur l'avant et le serveur ne fournit que des interfaces.
Problème: lors de la saisie de la page, il y aura un bref écran blanc.
répondre:
Entrez la page pour la première fois, rendez la page complète du côté Nodejs et téléchargez des modèles connexes en arrière-plan.
Interactions ultérieures, actualisation partielle complète du côté du navigateur
L'utilisation du même modèle produit le même résultat
Case 2 Application à page unique
Statut: utilisez le cadre MVC côté client pour modifier les pages du navigateur.
Problème: le rendu et le remplacement de la page sont tous deux terminés du côté du navigateur. Lorsque vous entrez l'URL directement dans ou actualisez le F5, le même contenu ne peut pas être directement présenté.
répondre:
Partagez les mêmes paramètres d'itinéraire du côté du navigateur et du côté Nodejs
Lorsque vous modifiez les pages du côté du navigateur, modifiez l'itinéraire et rendez le contenu de la page du côté du navigateur.
Lorsque vous entrez directement la même URL, utilisez le rendu du contenu Page Frame + Page côté Nodejs
Que vous modifiiez des pages sur le navigateur ou que vous entrez 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. Il a également résolu le problème SEO
Page de navigation pure du cas trois
Statut: la page ne fournit que des informations, moins ou pas d'interaction
Problème: HTML est généré du côté du serveur, CSS et JS sont placés à un autre endroit, et ils ont des dépendances entre elles.
répondre:
Grâce à Nodejs, gestion unifiée de HTML + CSS + JS
Si vous devez vous développer à des applications complexes ou à des applications à une page à l'avenir, vous pouvez également les transférer facilement.
Page de terminal de quatre croisements de cas
Statut: la même application doit présenter différentes interfaces et interactions à différents points de terminaison
Problème: la gestion HTML n'est pas facile, et différents HTML seront souvent générés du côté du serveur, et différents traitements seront effectués du côté du navigateur.
répondre:
Les pages inter-terminales sont des problèmes et sont gérées par le frontal.
Grâce à la couche NodeJS et au service backend, les meilleures solutions peuvent être conçues pour ce type d'applications complexes.
Résumer
L'émergence de technologies telles que l'AJAX, le MVC côté client, le spa, la liaison des données bidirectionnelle dans le passé ont toutes été des tentatives pour résoudre les goulots d'étranglement rencontrés dans le développement frontal à l'époque.
L'émergence de la couche intermédiaire NodeJS est également une tentative de résoudre une limitation que le frontal est actuellement limité au navigateur.
Cet article se concentre sur le partage des modèles frontaux et back-end, et espère attirer l'attention. Discutons avec vous de savoir comment améliorer notre flux de travail et coopérer avec le back-end pour faire un meilleur travail dans le front-end sous l'architecture de la couche moyenne Nodejs.