Avant-propos
Le modèle de développement consistant à utiliser Node pour séparer le front-end et le back-end apporte certains avantages en termes de performances et de processus de développement, mais il est également confronté à de nombreux défis. Dans le cadre de l'architecture commerciale et technique complexe de Taobao, le backend doit s'appuyer sur Java pour construire l'infrastructure et fournir des interfaces commerciales pertinentes à utiliser par le frontend. L'une des tâches les plus importantes de Node dans l'ensemble de l'environnement est de proxy ces interfaces métier pour faciliter l'intégration des données pour le rendu des pages par le front-end (côté nœud et côté navigateur). Comment faire du bon travail dans le travail d'agence afin qu'après la séparation du développement front-end et back-end, les processus puissent toujours être connectés de manière transparente, est une question que nous devons considérer. Cet article abordera ce problème et proposera des solutions.
Étant donné que les interfaces fournies par le backend peuvent être diverses, les développeurs peuvent également disposer de différentes manières d'accéder à ces interfaces lors de l'écriture de code côté nœud. Si nous ne mettons pas en œuvre un traitement d'architecture unifié en termes de méthodes d'accès et d'utilisation de l'interface, les problèmes suivants surgiront :
1. Chaque développeur utilise son propre style de codage pour écrire le code d'accès à l'interface, ce qui provoque une confusion dans le répertoire du projet et le style de codage, rendant la maintenance relativement difficile.
2. Chaque développeur écrit sa propre méthode de données fictives. Après le développement, il doit modifier manuellement le code pour supprimer la simulation.
3. Chaque développeur peut conserver certains fichiers de configuration afin de basculer entre les différents environnements de l'interface (quotidiennement, en pré-version, en ligne).
4. La méthode d'appel de l'interface de données ne peut pas être facilement réutilisée par divers modèles commerciaux.
5. La description de l'interface de données est dispersée dans tous les coins du code et peut être incompatible avec le document d'interface convenu par le personnel back-end.
6. Une fois l'ensemble du projet développé séparément, le coût du débogage conjoint ou du test de régression de l'interface reste très élevé et chaque fournisseur d'interface et utilisateur doit être impliqué.
Nous espérons donc avoir un tel framework qui utilise le mécanisme fourni par le framework pour décrire toutes les interfaces externes dont dépend le projet, les gérer de manière uniforme, fournir des méthodes de modélisation et d'appel d'interface flexibles, et fournir un environnement en ligne et un environnement de production pratiques. La méthode de commutation permet une intégration transparente du développement front-end et back-end. ModelProxy est un framework léger qui répond à ces exigences. Il s'agit de l'un des composants essentiels de Midway Framework et peut également être utilisé indépendamment. L'utilisation de ModelProxy peut apporter les avantages suivants :
1. Différents développeurs écrivent les codes d'accès à l'interface de manière unifiée, avec une signification claire et une difficulté de maintenance réduite.
2. Le mode singleton d'usine est adopté à l'intérieur du cadre pour réaliser la configuration de l'interface une fois et la réutiliser plusieurs fois. Et les développeurs peuvent personnaliser et assembler leurs propres modèles économiques (injection de dépendances) à volonté.
3. Il est très pratique de basculer entre les environnements en ligne, quotidiens et préliminaires.
4. Les moteurs fictifs intégrés tels que river-mock et mockjs rendent très pratique la fourniture de données fictives.
5. Utilisez les fichiers de configuration d'interface pour gérer uniformément les descriptions des dépendances d'interface afin d'éviter d'être dispersées entre différents codes.
6. Prend en charge le modèle partagé côté navigateur, qui peut être utilisé par le navigateur pour le rendu des données frontales. L'ensemble du processus de proxy est transparent pour le navigateur.
7. Le fichier de configuration de l'interface lui-même est un document de description structuré, et la collection d'outils River peut être utilisée pour générer automatiquement le document. Il peut également être utilisé pour des tests d'interface automatisés associés, faisant de l'ensemble du processus de développement une boucle fermée.
Diagramme du principe de fonctionnement de ModelProxy et diagramme du processus de développement associé
Dans la figure ci-dessus, le développeur doit d'abord écrire la description de toutes les interfaces back-end dépendantes du projet dans le fichier de configuration interface.json au format json spécifié. Si nécessaire, vous devez écrire un fichier de règles pour chaque interface, qui constitue la partie des règles d'interface dans la figure. Ce fichier de règles est utilisé pour simuler les données pendant la phase de développement ou utiliser l'ensemble d'outils River pour vérifier l'interface pendant la phase de débogage conjointe. Le contenu du fichier de règles dépend du moteur fictif utilisé (comme mockjs, river-mock, etc.). Une fois la configuration terminée, vous pouvez créer votre propre modèle économique dans le code en fonction de vos propres besoins.
Voici un exemple simple :
【Exemple 1】
La première étape consiste à créer le fichier de configuration de l'interface interface.json dans le répertoire du projet et à y ajouter la définition json de l'interface de recherche principale
Étape 2 : Créer et utiliser le modèle dans le code
// L'initialisation globale introduit le fichier de configuration de l'interface (attention : le travail d'initialisation n'a lieu qu'une seule fois)
ModelProxy.init( './interface.json' );
//Créer un modèle Veuillez vous référer à l'article suivant pour plus de modes de création
var searchModel = nouveau ModelProxy ({
SearchItems : 'Search.getItems' // Nom de la méthode personnalisée : ID d'interface défini dans le fichier de configuration
} );
// En utilisant le modèle, remarque : les paramètres requis pour appeler la méthode sont les paramètres requis par l'interface réelle.
searchModel.searchItems( { q : 'iphone6' } )
// !Notez que la méthode done doit être appelée pour spécifier la fonction de rappel afin d'obtenir les données obtenues en appelant searchItems de manière asynchrone ci-dessus !
.done( fonction( données ) {
console.log( données);
} )
.erreur (fonction (erreur) {
console.log(err);
} );
La richesse des fonctionnalités de ModelProxy est qu'il prend en charge diverses formes de profils pour créer les modèles économiques requis :
Créer en utilisant l'ID de l'interface> L'objet généré prendra le mot après le dernier '.' dans l'ID comme nom de méthode
Utiliser l'objet JSON clé-valeur> Nom de la méthode personnalisée : ID d'interface
Utiliser la forme d'un tableau> Prenez le mot après le dernier comme nom de méthode
Les noms d'appel de méthode générés dans l'exemple suivant sont : Cart_getItem, getItem, suggest, getName
Formulaire de préfixe> Tous les ID d'interface qui satisfont au préfixe seront introduits dans l'objet et la seconde moitié sera utilisée comme nom de méthode
En même temps, en utilisant ces modèles, vous pouvez facilement implémenter des demandes de fusion ou des demandes de dépendance, et effectuer le rendu de modèles associés
[Exemple 2] Demande de fusion
// Demande de fusion (sauf pour done, les méthodes de modèle appelées ci-dessous sont toutes spécifiées lors de la configuration de l'identifiant de l'interface)
model.suggest( { q : 'femelle' } )
.list( { mot-clé : 'iphone6' } )
.getNav( { clé : 'Vêtements à la mode' } )
.done( fonction( data1, data2, data3 ) {
// L'ordre des paramètres est cohérent avec l'ordre d'appel de la méthode
console.log( data1, data2, data3 );
} );
[Exemple 3] Demande de dépendance
De plus, ModelProxy peut être utilisé non seulement côté nœud, mais également côté navigateur. Introduisez simplement modelproxy-client.js fourni par le package officiel dans la page.
[Exemple 4] Utilisation de ModelProxy
Dans le même temps, ModelProxy peut être utilisé avec Midway-XTPL, un autre composant essentiel de Midway, pour réaliser un partage complet des données, des modèles et des processus de rendu associés du côté du navigateur et du serveur. Pour des didacticiels détaillés et de la documentation sur ModelProxy, veuillez vous rendre sur https://github.com/purejs/modelproxy
Résumé
ModelProxy existe en tant que framework léger configuré, fournissant un assemblage et une utilisation conviviaux de modèles d'interface, et en même temps résolvant bien le problème des spécifications d'utilisation de l'interface dans la séparation des modèles de développement front-end et back-end. Pendant tout le processus de développement du projet, l'interface n'a besoin d'être définie et décrite qu'une seule fois, et les développeurs front-end peuvent la référencer. Parallèlement, l'outil River est utilisé pour générer automatiquement des documents, former un contrat avec le back-end. les développeurs finaux et effectuent les tests automatisés associés, ce qui optimise considérablement l'ensemble du processus de développement du génie logiciel.
[Note] River est le nom collectif des spécifications d'interface unifiées front-end et back-end et de la collection d'outils associés développés par Alibaba Group
qu'est-ce que nodejs
Nodejs implémente le robot d'exploration
Tutoriel sur l'achat et la vente de Bitcoin sur Huobi.com
Que faire s'il n'y a aucun son provenant du microphone de l'ordinateur
Comment résoudre un périphérique USB non reconnu
Quels types d'architecture système existe-t-il ?
Encyclopédie d'utilisation de Printf
Quelle est la température normale d'un ordinateur portable ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
