Vorwort
Das Entwicklungsmodell, bei dem Node zur Trennung von Front-End und Back-End verwendet wird, bringt einige Vorteile in Bezug auf Leistung und Entwicklungsprozess mit sich, steht aber auch vor vielen Herausforderungen. Aufgrund der komplexen geschäftlichen und technischen Architektur von Taobao muss sich das Backend auf Java verlassen, um die Infrastruktur aufzubauen und relevante Geschäftsschnittstellen für die Nutzung durch das Frontend bereitzustellen. Eine der wichtigsten Aufgaben von Node in der gesamten Umgebung besteht darin, diese Geschäftsschnittstellen als Proxy bereitzustellen, um dem Front-End (Knotenseite und Browserseite) die Integration von Daten für das Seitenrendering zu erleichtern. Wie man in der Agenturarbeit einen guten Job macht, damit nach der Trennung von Front-End- und Backend-Entwicklung der Prozess weiterhin nahtlos verbunden werden kann, ist eine Frage, über die wir nachdenken müssen. In diesem Artikel wird dieses Problem erörtert und Lösungen vorgeschlagen.
Da die vom Backend bereitgestellten Schnittstellen unterschiedlich sein können, gibt es für Entwickler möglicherweise auch verschiedene Möglichkeiten, auf diese Schnittstellen zuzugreifen, wenn sie knotenseitigen Code schreiben. Wenn wir keine einheitliche Architekturverarbeitung in Bezug auf Schnittstellenzugriffsmethoden und -nutzung implementieren, treten die folgenden Probleme auf:
1. Jeder Entwickler verwendet seinen eigenen Codierungsstil, um Schnittstellenzugriffscode zu schreiben, was zu Verwirrung im Projektverzeichnis und im Codierungsstil führt und die Wartung relativ schwierig macht.
2. Jeder Entwickler schreibt seine eigene Scheindatenmethode. Nach der Entwicklung muss er den Code manuell ändern, um den Schein zu entfernen.
3. Jeder Entwickler kann einige Konfigurationsdateien pflegen, um zwischen verschiedenen Umgebungen der Schnittstelle (täglich, Vorabversion, online) zu wechseln.
4. Die Aufrufmethode der Datenschnittstelle kann von verschiedenen Geschäftsmodellen nicht einfach wiederverwendet werden.
5. Die Beschreibung der Datenschnittstelle ist in jeder Ecke des Codes verstreut und stimmt möglicherweise nicht mit dem vom Back-End-Personal vereinbarten Schnittstellendokument überein.
6. Nachdem das gesamte Projekt separat entwickelt wurde, sind die Kosten für das gemeinsame Debuggen oder die Testregression der Schnittstelle immer noch sehr hoch und jeder Schnittstellenanbieter und Benutzer muss einbezogen werden.
Daher hoffen wir, über ein solches Framework zu verfügen, das den vom Framework bereitgestellten Mechanismus nutzt, um alle externen Schnittstellen zu beschreiben, von denen das Projekt abhängt, sie einheitlich zu verwalten, flexible Schnittstellenmodellierungs- und Aufrufmethoden bereitzustellen und eine praktische Online- und Produktionsumgebung bereitzustellen Die Switching-Methode ermöglicht eine nahtlose Integration der Front-End- und Back-End-Entwicklung. ModelProxy ist ein leichtgewichtiges Framework, das diese Anforderungen erfüllt. Es ist eine der Kernkomponenten von Midway Framework und kann auch unabhängig verwendet werden. Die Verwendung von ModelProxy kann folgende Vorteile bringen:
1. Verschiedene Entwickler schreiben Schnittstellenzugriffscodes auf einheitliche Weise, mit klarer Bedeutung und geringerem Wartungsaufwand.
2. Der Factory-Singleton-Modus wird innerhalb des Frameworks übernommen, um die Schnittstellenkonfiguration einmal zu realisieren und mehrmals wiederzuverwenden. Und Entwickler können ihre eigenen Geschäftsmodelle (Abhängigkeitsinjektion) nach Belieben anpassen und zusammenstellen.
3. Es ist sehr bequem, zwischen Online-, Tages- und Vorabversionsumgebungen zu wechseln.
4. Integrierte Mock-Engines wie River-Mock und Mockjs machen die Bereitstellung von Mock-Daten sehr bequem.
5. Verwenden Sie Schnittstellenkonfigurationsdateien, um Schnittstellenabhängigkeitsbeschreibungen einheitlich zu verwalten und eine Verstreuung auf verschiedene Codes zu vermeiden.
6. Unterstützt das browserseitige gemeinsame Modell, das vom Browser für das Rendern von Front-End-Daten verwendet werden kann. Der gesamte Proxy-Prozess ist für den Browser transparent.
7. Die Schnittstellenkonfigurationsdatei selbst ist ein strukturiertes Beschreibungsdokument, und die River-Tool-Sammlung kann zum automatischen Generieren des Dokuments verwendet werden. Es kann auch für zugehörige automatisierte Schnittstellentests verwendet werden, sodass der gesamte Entwicklungsprozess einen geschlossenen Kreislauf bildet.
ModelProxy-Arbeitsprinzipdiagramm und zugehöriges Entwicklungsprozessdiagramm
In der obigen Abbildung muss der Entwickler zunächst die Beschreibung aller abhängigen Back-End-Schnittstellen im Projekt in die Konfigurationsdatei interface.json im angegebenen JSON-Format schreiben. Bei Bedarf müssen Sie für jede Schnittstelle eine Regeldatei schreiben. Dies ist der Schnittstellenregelteil in der Abbildung. Diese Regeldatei wird verwendet, um Daten während der Entwicklungsphase zu simulieren oder das River-Tool-Set zu verwenden, um die Schnittstelle während der gemeinsamen Debugging-Phase zu überprüfen. Der Inhalt der Regeldatei hängt davon ab, welche Mock-Engine verwendet wird (z. B. Mockjs, River-Mock usw.). Nach Abschluss der Konfiguration können Sie im Code Ihr eigenes Geschäftsmodell entsprechend Ihren eigenen Anforderungen erstellen.
Hier ist ein einfaches Beispiel:
【Beispiel 1】
Der erste Schritt besteht darin, die Schnittstellenkonfigurationsdatei interface.json im Projektverzeichnis zu erstellen und darin die JSON-Definition der Hauptsuchschnittstelle hinzuzufügen
Schritt 2: Erstellen und verwenden Sie das Modell im Code
// Globale Initialisierung führt die Schnittstellenkonfigurationsdatei ein (Hinweis: Die Initialisierungsarbeit erfolgt nur einmal)
ModelProxy.init( './interface.json' );
//Modell erstellen. Weitere Erstellungsmodi finden Sie im folgenden Artikel
var searchModel = new ModelProxy( {
SearchItems: 'Search.getItems' // Name der benutzerdefinierten Methode: Schnittstellen-ID, definiert in der Konfigurationsdatei
} );
searchModel.searchItems( { q: 'iphone6' } )
// !Beachten Sie, dass die done-Methode aufgerufen werden muss, um die Rückruffunktion anzugeben, um die durch den oben genannten asynchronen Aufruf von searchItems erhaltenen Daten zu erhalten!
.done( function( data ) {
console.log( data );
} )
.error( function( err ) {
console.log(err);
} );
Mit Schnittstellen-ID erstellen> Das generierte Objekt übernimmt das Wort nach dem letzten „.“ in der ID als Methodennamen
Die im folgenden Beispiel generierten Methodenaufrufnamen lauten: Cart_getItem, getItem, suggest, getName
[Beispiel 2] Zusammenführungsanforderung
model.suggest( { q: 'female' } )
.list( { keyword: 'iphone6' } )
.getNav( { key: 'Modische Kleidung' } )
.done( function( data1, data2, data3 ) {
// Die Reihenfolge der Parameter stimmt mit der Reihenfolge des Methodenaufrufs überein
console.log( data1, data2, data3 );
} );
[Beispiel 3] Abhängigkeitsanfrage
Darüber hinaus kann ModelProxy nicht nur auf der Node-Seite, sondern auch auf der Browser-Seite verwendet werden. Fügen Sie einfach modelproxy-client.js aus dem offiziellen Paket in die Seite ein.
[Beispiel 4] Verwendung von ModelProxy
Gleichzeitig kann ModelProxy zusammen mit Midway-XTPL, einer weiteren Kernkomponente von Midway, verwendet werden, um eine vollständige gemeinsame Nutzung von Daten, Vorlagen und zugehörigen Rendering-Prozessen auf Browser- und Serverseite zu realisieren. Ausführliche Tutorials und Dokumentation zu ModelProxy finden Sie unter https://github.com/purejs/modelproxy
Zusammenfassung
ModelProxy existiert als konfiguriertes, leichtes Framework, das eine benutzerfreundliche Montage und Nutzung von Schnittstellenmodellen ermöglicht und gleichzeitig das Problem der Schnittstellennutzungsspezifikationen bei der Trennung von Front-End- und Back-End-Entwicklungsmodellen gut löst. Während des gesamten Projektentwicklungsprozesses muss die Schnittstelle nur einmal definiert und beschrieben werden, und die Front-End-Entwickler können darauf verweisen. Gleichzeitig wird das River-Tool verwendet, um automatisch Dokumente zu generieren und einen Vertrag mit dem Back-End zu schließen. Endentwickler und führen zugehörige automatisierte Tests durch, was den gesamten Software-Engineering-Entwicklungsprozess erheblich optimiert.
[Hinweis] River ist die Sammelbezeichnung für die einheitlichen Front-End- und Back-End-Schnittstellenspezifikationen und die zugehörige Tool-Sammlung, die von der Alibaba Group entwickelt wurden
