Denken und Praktizieren der Front-End- und Back-End-Trennung basierend auf NodeJS (1) Full-Stack-Entwicklung_node.js

Vorwort

Um verschiedene Probleme zu lösen, die durch das traditionelle Webentwicklungsmodell verursacht werden, haben wir viele Versuche unternommen, aber aufgrund der physischen Lücke zwischen Front- und Back-End sind die ausprobierten Lösungen alle ähnlich. Nachdem wir aus der schmerzhaften Erfahrung gelernt haben, überdenken wir heute die Definition von „Front-End und Back-End“, führen NodeJS ein, das Front-End-Studenten vertraut ist, und versuchen, ein neues Front-End- und Back-End-Trennmodell zu erkunden .

Mit dem Aufkommen verschiedener Endgeräte (Pad/Mobil/PC) werden die Anforderungen an die reine Browser-Reaktionsfähigkeit nicht mehr den hohen Anforderungen an die Benutzererfahrung gerecht. Wir müssen oft für unterschiedliche Endgeräte entwickeln Terminals. Kundenspezifische Version. Um die Entwicklungseffizienz zu verbessern, wird der Notwendigkeit einer Trennung von Front-End und Back-End immer mehr Aufmerksamkeit geschenkt. Das Back-End ist für die Geschäfts-/Datenschnittstelle verantwortlich und das Front-End ist für die Anzeige verantwortlich. Interaktionslogik. Wir können mehrere Versionen derselben Datenschnittstelle anpassen und entwickeln.

Dieses Thema wurde in letzter Zeit viel diskutiert und einige BUs in Alibaba unternehmen ebenfalls einige Versuche. Nach einer langen Diskussion beschloss unser Team, eine Front-End- und Back-End-Trennlösung auf Basis von NodeJS zu erkunden. Während des Prozesses hatten wir einige veränderte Erkenntnisse und Gedanken, die wir hier festhalten Wir werden uns an der Diskussion beteiligen und uns helfen, sie zu verbessern.

1. Was ist Front-End- und Back-End-Trennung?

Während der ersten Diskussion in der Gruppe habe ich festgestellt, dass jeder ein anderes Verständnis für die Trennung von Front-End und Backend hat. Um sicherzustellen, dass die Diskussion im gleichen Kanal diskutiert werden kann, müssen wir uns zunächst darauf einigen eine Vereinbarung darüber, was „Trennung von Front-End und Back-End“ ist.

Das Beispiel für die Trennung von Front-End und Back-End, über das sich alle einig sind, ist SPA (Single-Page Application). Alle verwendeten Anzeigedaten werden vom Back-End über eine asynchrone Schnittstelle (AJAX/JSONP) bereitgestellt Das Frontend zeigt es nur an.
In gewisser Weise erreicht SPA zwar die Trennung von Front- und Back-End, aber bei diesem Ansatz gibt es zwei Probleme:

Unter den WEB-Diensten macht SPA einen kleinen Anteil aus. In vielen Szenarien gibt es synchrone/synchrone und asynchrone Mischmodi, und SPA kann nicht als universelle Lösung verwendet werden.
Im aktuellen SPA-Entwicklungsmodell werden Schnittstellen normalerweise auf der Grundlage der Präsentationslogik bereitgestellt. Um die Effizienz zu verbessern, hilft uns das Backend manchmal bei der Handhabung einiger Präsentationslogiken, was bedeutet, dass das Backend weiterhin an der Arbeit der Ansichtsebene beteiligt ist ist nicht real.
Die Trennung von Front-End und Back-End im SPA-Stil basiert auf der physischen Schicht (man geht davon aus, dass es sich um das Front-End handelt, solange es sich um den Client handelt und die Serverseite um das Back-End). . Diese Aufteilung kann unsere Anforderungen an die Trennung von Front-End und Back-End nicht mehr erfüllen. Wir glauben, dass die Aufteilung der Verantwortlichkeiten erreicht werden kann. Erfüllen Sie unsere aktuellen Nutzungsszenarien:

Frontend: Verantwortlich für die View- und Controller-Ebenen.
Backend: nur verantwortlich für die Modellebene, Geschäftsverarbeitung/Daten usw.
Auf den Grund für diese Aufgabenteilung wird später eingegangen.

2. Warum sollten Vorder- und Rückseite getrennt werden?

Zu diesem Thema erklärt Yu Bos Artikel The Evolution of Web R&D Model es sehr ausführlich:

2.1 Anwendbare Szenarien bestehender Entwicklungsmodelle

Die verschiedenen von Onkel Yu erwähnten Entwicklungsmodelle haben jeweils ihre eigenen anwendbaren Szenarien, und keines ersetzt das andere vollständig.

Zum Beispiel ist MVC, das sich auf das Backend konzentriert, bei einigen synchronen Anzeigegeschäften sehr effizient. Wenn es jedoch um Seiten geht, die synchron und asynchron sind, ist die Kommunikation mit der Backend-Entwicklung schwieriger.
Ajax ist das wichtigste SPA-Entwicklungsmodell, das besser für APP-Entwicklungsszenarien geeignet ist, aber nur für APPs geeignet ist, da Probleme wie SEO schwer zu lösen sind. Für viele Arten von Systemen ist diese Entwicklungsmethode zu schwer.
2.2 Unklare Verantwortlichkeiten von Front-End und Back-End

In einem System mit komplexer Geschäftslogik haben wir am meisten Angst davor, Code zu verwalten, der mit Front-End und Back-End gemischt ist. Da es keine Einschränkungen gibt, kann jede Schicht von M-V-C im Laufe der Zeit Codes aus anderen Schichten enthalten. Es gibt überhaupt keine Wartbarkeit.
Obwohl die Trennung von Front-End und Back-End dieses Problem nicht vollständig lösen kann, kann es erheblich gemildert werden. Weil es physikalisch garantiert ist, dass Sie dies nicht tun können.

2.3 Probleme mit der Entwicklungseffizienz

Taobaos Web basiert im Wesentlichen auf dem MVC-Framework webx. Die Architektur legt fest, dass sich das Front-End nur auf das Back-End verlassen kann.
Daher besteht unser Entwicklungsmodell immer noch darin, dass wir eine statische Demo auf dem Frontend schreiben und diese auf dem Backend in ein VM-Template übersetzen. Ich werde nicht auf die Probleme dieses Modells eingehen, das schon seit langem kritisiert wird.
Es ist außerdem mühsam, direkt auf der Grundlage der Back-End-Umgebung zu entwickeln, und die Konfiguration, Installation und Verwendung ist mühsam. Um dieses Problem zu lösen, haben wir verschiedene Tools wie VMarket erfunden, aber das Front-End muss immer noch VM schreiben und ist auf Back-End-Daten angewiesen, sodass die Effizienz immer noch nicht hoch ist.
Darüber hinaus kann das Backend seinen starken Fokus auf die Präsentation nicht loswerden und sich auf die Entwicklung der Geschäftslogikschicht konzentrieren.

2.4 Einschränkungen der Front-End-Leistung

Wenn die Leistungsoptimierung nur im Front-End erfolgt, ist der Platz sehr begrenzt, sodass wir häufig eine Back-End-Zusammenarbeit benötigen, um Funken zu erzielen. Aufgrund der Einschränkungen des Back-End-Frameworks ist dies jedoch für uns schwierig technische Lösungen wie Comet und Bigpipe zur Leistungsoptimierung einzusetzen.

Um einige der oben genannten Probleme zu lösen, haben wir viele Versuche unternommen und verschiedene Tools entwickelt, aber es gab nie große Verbesserungen, hauptsächlich weil wir nur den kleinen Platz nutzen konnten, der uns im Backend zugewiesen wurde. Nur durch eine wirkliche Trennung von Front- und Back-End können wir die oben genannten Probleme vollständig lösen.

3. Wie trennt man Vorder- und Rückseite?

Wie trennt man Vorder- und Rückseite? Tatsächlich finden Sie die Antwort bereits im ersten Abschnitt:

Frontend: Verantwortlich für die View- und Controller-Ebenen.
Backend: verantwortlich für die Modellebene, Geschäftsverarbeitung/Daten usw.

Stellen Sie sich vor, wenn das Front-End den Controller beherrscht, können wir das URL-Design entsprechend der Szene synchronisieren oder JSON-Daten basierend auf den Daten der Ansichtsebene ausgeben , Comet usw., basierend auf den Anforderungen der Präsentationsschicht usw., hängt vollständig von der Nachfrage ab, die bestimmt, wie sie verwendet wird.

3.1 „Full-Stack“-Entwicklung basierend auf NodeJS

Wenn wir die Schichtung im Bild oben erreichen wollen, benötigen wir auf jeden Fall einen Webdienst, der uns dabei hilft, das zu erreichen, was wir im Front- und Backend tun, also gibt es die erwähnte „Full-Stack-Entwicklung auf Basis von NodeJS“. im Titel

Dieses Bild sieht einfach und leicht verständlich aus, aber wenn Sie es noch nicht ausprobiert haben, werden Sie viele Fragen haben.

Im SPA-Modus stellt das Backend bereits die erforderliche Datenschnittstelle bereit und das View-Frontend kann bereits gesteuert werden. Warum eine zusätzliche Ebene von NodeJS hinzufügen?
Wie ist die Leistung beim Hinzufügen einer weiteren Ebene?
Erhöht sich die Front-End-Arbeitslast durch das Hinzufügen einer weiteren Ebene?
Das Hinzufügen weiterer Schichten bedeutet mehr Risiken.
NodeJS kann alles, warum brauchen Sie JAVA?
Es ist nicht einfach, diese Probleme klar zu erklären. Lassen Sie mich im Folgenden über meinen Verständnisprozess sprechen.

3.2 Warum eine Ebene von NodeJS hinzufügen?

Zu diesem Zeitpunkt entwickeln wir hauptsächlich im Back-End-MVC-Modell. Dieses Modell beeinträchtigt die Effizienz der Front-End-Entwicklung erheblich und verhindert, dass sich das Back-End auf die Geschäftsentwicklung konzentriert.
Die Lösung besteht darin, dem Front-End die Steuerung der Controller-Schicht zu ermöglichen. Dies ist jedoch unter dem vorhandenen technischen System schwierig, da es unmöglich ist, dass alle Front-Ends Java lernen, eine Back-End-Entwicklungsumgebung installieren usw VMs schreiben.
NodeJS kann dieses Problem sehr gut lösen. Wir müssen keine neue Sprache lernen, wir können das tun, was frühere Entwickler für uns getan haben, und alles erscheint so natürlich.

3.3 Leistungsprobleme

Layering beinhaltet die Kommunikation zwischen den einzelnen Schichten, und es wird definitiv einen gewissen Leistungsverlust geben. Eine sinnvolle Schichtung kann jedoch die Verantwortlichkeiten klarstellen und die Zusammenarbeit erleichtern, was die Entwicklungseffizienz erheblich verbessern wird. Die durch die Schichtung verursachten Verluste werden auf jeden Fall durch Gewinne in anderen Bereichen ausgeglichen.
Darüber hinaus können wir, sobald wir uns für die Schichtung entscheiden, den Verlust durch die Optimierung von Kommunikationsmethoden und -protokollen so weit wie möglich minimieren.

Zum Beispiel:
Nachdem die Detailseite von Taobao Baby statisch gemacht wurde, müssen noch viele Informationen in Echtzeit abgerufen werden, z. B. Logistik, Werbeaktionen usw. Da sich diese Informationen in verschiedenen Geschäftssystemen befinden, muss das Front-End 5 senden oder 6 asynchrone Anfragen zum Ausfüllen des Inhalts.
Mit NodeJS kann das Front-End diese fünf asynchronen Anforderungen in NodeJS vertreten und Bigpipe problemlos erstellen. Diese Optimierung kann die Gesamtrendereffizienz erheblich verbessern.
Vielleicht denken Sie, dass es in Ordnung ist, 5 oder 6 asynchrone Anfragen auf einem PC zu senden, aber auf der drahtlosen Seite ist es sehr teuer, eine HTTP-Anfrage auf dem Mobiltelefon des Clients einzurichten. Mit dieser Optimierung kann die Leistung um ein Vielfaches verbessert werden.

Taobao-Details: Wir sind dabei, Taobao auf Basis von NodeJS zu optimieren. Ich werde den Optimierungsprozess teilen, nachdem er online ist.

3.4 Hat sich die Front-End-Arbeitsbelastung erhöht?

Im Vergleich zum bloßen Schneiden von Seiten/Demos bringt es definitiv ein wenig mehr mit sich, aber im aktuellen Modell gibt es gemeinsame Debugging- und Kommunikationsverbindungen. Dieser Prozess ist sehr zeitaufwändig, fehleranfällig und schwierig zu warten.
Obwohl die Arbeitsbelastung etwas zunimmt, wird die Gesamtentwicklungseffizienz erheblich verbessert.

Außerdem können die Testkosten erheblich eingespart werden. Die zuvor entwickelten Schnittstellen waren alle für die Präsentationsschicht gedacht, was das Schreiben von Testfällen erschwerte. Wenn Front-End und Back-End getrennt sind, kann sogar das Testen getrennt werden. Eine Gruppe von Personen wird sich auf das Testen der Benutzeroberfläche konzentrieren und eine andere Gruppe von Personen wird sich auf das Testen der Benutzeroberfläche konzentrieren (dieser Teil der Arbeit kann sogar ersetzt werden). durch Werkzeuge).

3.5 Wie kann man die Risiken kontrollieren, die durch das Hinzufügen einer Knotenebene entstehen?

Durch den groß angelegten Einsatz von Node werden sich Studenten aus den Bereichen System/Betrieb und Wartung/Sicherheit definitiv am Aufbau der Infrastruktur beteiligen. Sie werden uns helfen, mögliche Probleme in jeder Verbindung zu beheben und die Stabilität des Systems sicherzustellen.

3.6 Knoten kann alles, warum brauchen Sie JAVA?

Unsere ursprüngliche Absicht bestand darin, das Front- und Back-End zu trennen. Wenn wir dieses Problem berücksichtigen, würde dies unserer ursprünglichen Absicht zuwiderlaufen. Selbst wenn Node als Ersatz für Java verwendet wird, können wir nicht garantieren, dass verschiedene heute auftretende Probleme, wie z. B. unklare Verantwortlichkeiten, nicht auftreten. Unser Ziel ist es, uns schichtweise weiterzuentwickeln, wobei sich die Fachkräfte auf die Erledigung beruflicher Dinge konzentrieren. Die JAVA-basierte Infrastruktur ist bereits sehr leistungsstark und stabil und eignet sich besser für die aktuelle Architektur.

4. Taobaos Front-End- und Back-End-Trennung basierend auf Node

Das Bild oben zeigt mein Verständnis der Front-End- und Back-End-Trennung und -Schichtung von Taobao basierend auf Node sowie den Umfang der Verantwortlichkeiten von Node. Kurze Erklärung:

Das obere Ende ist der Server, den wir oft als Backend bezeichnen. Für uns ist das Backend eine Sammlung von Schnittstellen, und der Server stellt uns eine Vielzahl von Schnittstellen zur Verfügung. Da es eine Knotenschicht gibt, besteht keine Notwendigkeit, die Art des Dienstes einzuschränken. Für die Back-End-Entwicklung verwenden sie ausschließlich Schnittstellenimplementierungen, die sich um den Geschäftscode kümmern.
Unterhalb des Servers befindet sich die Node-Anwendung.
In der Knotenanwendung gibt es eine Modell-Proxy-Ebene für die Kommunikation mit dem Server. Diese Schicht dient derzeit hauptsächlich dazu, die Art und Weise zu glätten, wie wir verschiedene Schnittstellen aufrufen und einige von der Ansichtsschicht benötigte Modelle zu kapseln.
Die Knotenschicht kann auch die ursprünglichen Anforderungen von vmcommon, tms (bezogen auf das Taobao-Content-Management-System) und anderen Anforderungen problemlos realisieren.
Es ist Sache des Entwicklers, zu entscheiden, welches Framework er für die Node-Schicht verwendet. Es wird jedoch empfohlen, die Kombination von Express-xTemplate zu verwenden, die vom Front-End und vom Back-End gemeinsam genutzt werden kann.
Jeder entscheidet, wie er Node verwendet, aber das Spannende ist, dass wir Node endlich verwenden können, um die gewünschte Ausgabemethode einfach zu erreichen: JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/synchron, asynchron, was auch immer Sie wollen Die Anpassung hängt ganz von Ihrer Szene ab.
Die Browserebene hat sich in unserer Architektur nicht geändert und wir hoffen nicht, dass die Einführung von Node Ihr bisheriges Verständnis der Entwicklung im Browser ändern wird.
Durch die Einführung von Node wird dem Front-End lediglich die Kontrolle über die Teile übertragen, die vom Front-End gesteuert werden sollen.
Wir haben bereits zwei Projekte mit diesem Modell in der Entwicklung, obwohl es noch nicht gestartet ist, haben wir bereits die Vorteile in Bezug auf Entwicklungseffizienz und Leistungsoptimierung erlebt.

5. Was müssen wir noch tun?

Integrieren Sie den Entwicklungsprozess von Node in den bestehenden SCM-Prozess von Taobao.
Infrastrukturaufbau, wie Sitzung, Logger und andere gängige Module.
Beste Entwicklungspraktiken
Online-Erfolgsgeschichten
Jeder versteht das Konzept der Front-End- und Back-End-Trennung in Node
Sicher
Leistung
…
Es gibt nicht viel, was technisch innoviert und erforscht werden muss, und es gibt bereits eine Menge fertiger Anhäufungen. Tatsächlich liegt der Schlüssel darin, einige Prozesse zu klären und gemeinsame Lösungen zu sammeln. Ich glaube, dass dies mit mehr Projektpraxis allmählich zu einem stabilen Prozess wird.

6. „Mitte“

Obwohl das Modell der „Full-Stack-Entwicklung auf Basis von NodeJS“ sehr spannend ist, ist es noch ein weiter Weg, um die Full-Stack-Entwicklung auf Basis von Node in etwas Stabiles und für alle Akzeptables zu verwandeln. Wir arbeiten derzeit daran Das Projekt „Midway“ wurde entwickelt, um dieses Problem zu lösen. Obwohl wir gerade erst angefangen haben, kommen wir unserem Ziel immer näher! !