Denken und Praktizieren der Front-End- und Back-End-Trennung basierend auf NodeJS (2) Vorlage explore_node.js

Vorwort

Bei der Front-End- und Back-End-Trennung achten wir zunächst auf das Rendern, also die Arbeit auf der Ansichtsebene.

Im traditionellen Entwicklungsmodell werden die Browserseite und die Serverseite von unterschiedlichen Front-End- und Back-End-Teams entwickelt, die Vorlage befindet sich jedoch im Fuzzy-Bereich zwischen beiden. Daher ist es unvermeidlich, dass der Vorlage immer komplexere Logik hinzugefügt wird, die schließlich schwierig zu warten sein wird.

Und wir haben NodeJS als mittlere Schicht zwischen Front- und Back-End gewählt. Ich versuche, NodeJS zu verwenden, um die Arbeit auf der Ansichtsebene zu optimieren.

Machen Sie die Arbeitsteilung zwischen Front- und Backend klarer, sodass das Projekt besser verwaltet werden kann und eine bessere Benutzererfahrung erzielt wird.

Dieser Artikel

Rendering macht einen sehr großen Teil der täglichen Arbeit von Front-End-Entwicklern aus und ist auch der Bereich, in dem es am wahrscheinlichsten mit der Back-End-Entwicklung verwickelt wird.

Rückblickend auf die Entwicklung der Front-End-Technologie in den letzten Jahren hat die Arbeit auf der Ansichtsebene viele Veränderungen durchgemacht, wie zum Beispiel:

Formular senden, vollständige Seitenaktualisierung => teilweise AJAX-Aktualisierung
Serverseitiges Rendering von MVC => Clientseitiges Rendering von MVC
Herkömmlicher Seitenwechselsprung => Einzelseitenanwendung
Es ist zu beobachten, dass in den letzten Jahren jeder dazu tendierte, das Rendering von der Serverseite auf die Browserseite zu verlagern.

Die Serverseite konzentriert sich auf Servitization und stellt Datenschnittstellen bereit.

Vorteile des browserseitigen Renderings

Wir alle kennen die Vorteile des browserseitigen Renderings, wie zum Beispiel

1. Beseitigen Sie die Kopplung und Verwirrung von Geschäftslogik und Präsentationslogik in der Java-Vorlagen-Engine.
2. Bei Multi-Terminal-Anwendungen ist die Schnittstelle einfacher. Nutzen Sie browserseitig unterschiedliche Vorlagen, um unterschiedliche Anwendungen darzustellen.
3. Beim Rendern von Seiten handelt es sich nicht nur um HTML. Beim Front-End-Rendering können Funktionen einfacher in komponentenbasierter Form (HTML-JS-CSS) bereitgestellt werden, sodass Front-End-Komponenten nicht auf die vom Server generierte HTML-Struktur angewiesen sind.
4. Beseitigen Sie die Abhängigkeit von Back-End-Entwicklungs- und Release-Prozessen.
5. Erleichtern Sie das gemeinsame Debuggen.

Nachteile durch browserseitiges Rendern

Aber während wir die Vorteile genießen, stehen wir auch vor den Nachteilen, die das browserseitige Rendering mit sich bringt, wie zum Beispiel:

1. Vorlagen sind in verschiedene Bibliotheken unterteilt. Einige Vorlagen werden auf der Serverseite (JAVA) platziert, während andere auf der Browserseite (JS) platziert werden. Die Front-End- und Back-End-Vorlagensprachen sind nicht miteinander verbunden.
2. Sie müssen warten, bis alle Vorlagen und Komponenten im Browser geladen sind, bevor mit dem Rendern begonnen werden kann, und Sie können sie nicht sofort anzeigen.
3. Beim ersten Betreten wartet ein weißer Bildschirm auf die Renderzeit, was der Benutzererfahrung nicht förderlich ist
4. Bei der Entwicklung einer Single-Page-Anwendung stimmen die Front-End-Route und die serverseitige Route nicht überein, was sehr problematisch ist.
5. Wichtige Inhalte werden im Frontend zusammengestellt, was der SEO nicht förderlich ist

Denken Sie über die Definition von Front-End und Back-End nach

Tatsächlich bestand unser Ziel, als wir die Rendering-Arbeit von der Serverseite (Java) auf die Browserseite (JS) verlagerten, nur darin, die Front-End- und Back-End-Verantwortlichkeiten klar aufzuteilen, und das ist auch passiert Das bedeutet nicht, dass das Browser-Rendering unverzichtbar war.

Nur ​​weil es im traditionellen Entwicklungsmodell nach dem Verlassen des Servers zum Browser geht, kann der Front-End-Arbeitsinhalt nur auf die Browserseite beschränkt werden.

Aus diesem Grund glauben viele Leute, dass Back-End = Serverseite und Front-End = Browserseite ist, genau wie im Bild unten.

Im Midway-Projekt, das derzeit von Taobao UED durchgeführt wird, versuchen wir durch den Aufbau einer NodeJS-Mittelschicht zwischen JAVA und Browser, die Trennlinie zwischen Front- und Back-End basierend auf Arbeitsverantwortlichkeiten und nicht auf der Hardwareumgebung neu zu definieren. Zur Unterscheidung (Server & Browser).

So haben wir die Möglichkeit, Vorlagen und Routen zu teilen, was auch der idealste Zustand in der Arbeitsteilung zwischen Front- und Backend ist.

Taobao Midway Midway

Im Midway-Projekt haben wir die Linie, die das Front- und Back-End von der Browserseite trennt, zurück auf die Serverseite verschoben.

Mit einer Nodejs-Ebene, die einfach vom Front-End gesteuert werden kann und mit dem Browser gemeinsam ist, kann die Trennung von Front-End und Back-End klarer durchgeführt werden.

Sie können Frontend-Entwickler auch die Entscheidung überlassen, welche Lösung für verschiedene Situationen am besten geeignet ist. Anstatt dass alles auf der Browserseite abgewickelt wird.

Verantwortungsverteilung

Midway ist kein Front-End-Projekt, das versucht, die Back-End-Jobs zu stehlen. Der Zweck besteht lediglich darin, den unscharfen Bereich der Vorlagen zu durchbrechen und eine klarere Aufteilung der Verantwortlichkeiten zu erreichen.

Backend (JAVA), mit Schwerpunkt auf
1. Serviceschicht
2. Datenformat und Datenstabilität
3.Geschäftslogik

Frontend, konzentrieren Sie sich auf
1.UI-Ebene
2. Steuerlogik und Rendering-Logik
3. Interaktion und Benutzererfahrung

Halten Sie sich nicht länger an den Unterschied zwischen der Serverseite und der Browserseite.

Vorlagenfreigabe

Im traditionellen Entwicklungsmodell werden die Browserseite und die Serverseite von unterschiedlichen Front-End- und Back-End-Teams entwickelt, die Vorlage befindet sich jedoch im Fuzzy-Bereich zwischen beiden. Daher ist es unvermeidlich, dass der Vorlage immer komplexere Logik hinzugefügt wird, die schließlich schwierig zu warten sein wird.

Mit NodeJS können sich Back-End-Studenten auf die Entwicklung von Geschäftslogik und Daten auf der JAVA-Ebene konzentrieren. Die Frontend-Studenten konzentrieren sich auf die Entwicklung von Steuerungslogik und Rendering. Und Sie können wählen, ob diese Vorlagen auf der Serverseite (NodeJS) oder auf der Browserseite gerendert werden sollen.

Verwendung derselben Vorlagensprache XTemplate und derselben Rendering-Engine JavaScript

Rendern Sie dasselbe Ergebnis in verschiedenen Rendering-Umgebungen (serverseitig, PC-Browser, mobiler Browser, Webansicht usw.).

Routenfreigabe

Aufgrund der NodeJS-Schicht kann das Routing detaillierter gesteuert werden.

Wenn Sie im Front-End browserseitiges Routing durchführen müssen, können Sie gleichzeitig serverseitiges Routing konfigurieren, um beim browserseitigen oder serverseitigen Seitenwechsel einen konsistenten Rendering-Effekt zu erzielen.

Gleichzeitig wurden auch SEO-Themen behandelt.

Praxis der Vorlagenfreigabe

Wenn wir eine Vorlage auf der Browserseite rendern, ist der Vorgang normalerweise nichts weiter als

Laden Sie die Template-Engine (xtmpleate, Juicer, Handlerbar usw.) im Browser
Laden Sie die Vorlagendatei in den Browser. Die Methode lautet möglicherweise
Verwenden Sie , um auf der Seite zu drucken Verwenden Sie Modulladetools, um Vorlagendateien zu laden (KISSY, requireJS usw.)
Andere
Erhalten Sie Daten und verwenden Sie die Template-Engine, um HTML zu generieren
Fügen Sie HTML an der angegebenen Stelle ein.
Aus dem obigen Prozess lässt sich erkennen, dass der Fokus tatsächlich auf einer konsistenten Modulauswahl liegt, um eine übergreifende gemeinsame Nutzung von Vorlagen zu erreichen.

Es gibt viele gängige Modulstandards auf dem Markt, wie z. B. KMD, AMD und CommonJS. Solange die NodeJS-Vorlagendatei über konsistente Modulspezifikationen an die NodeJS-Seite ausgegeben werden kann, ist eine grundlegende Vorlagenfreigabe möglich.

In der folgenden Artikelserie wird der Proxy und die gemeinsame Nutzung von Modellen weiter erörtert.

Fallstudie

Aufgrund der Mittelschicht von Midway Island konnten einige Probleme in der Vergangenheit besser gelöst werden, wie zum Beispiel

Fall 1 Komplexe interaktive Anwendung (z. B. Warenkorb, Bestellseite)

Status: Der gesamte HTML-Code wird im Frontend gerendert und der Server stellt nur Schnittstellen bereit.

Problem: Beim Betreten der Seite erscheint kurzzeitig ein weißer Bildschirm.
Antwort:
Wenn Sie die Seite zum ersten Mal betreten, führen Sie auf der NodeJS-Seite ein Ganzseiten-Rendering durch und laden Sie die entsprechenden Vorlagen im Hintergrund herunter.
Nachfolgende interaktive Vorgänge werden auf der Browserseite mit teilweiser Aktualisierung abgeschlossen
Die Verwendung derselben Vorlage führt zu denselben Ergebnissen

Fall 2 Einseitiger Antrag

Status: Verwenden Sie das clientseitige MVC-Framework, um Seiten im Browser zu ändern.

Problem: Rendering und Seitenwechsel sind browserseitig abgeschlossen. Bei direkter URL-Eingabe oder Aktualisierung mit f5 kann der gleiche Inhalt nicht direkt angezeigt werden.
Antwort:
Teilen Sie dieselben Routeneinstellungen auf der Browserseite und der NodeJS-Seite
Wenn Sie Seiten auf der Browserseite wechseln, führen Sie Routenänderungen und Seiteninhaltsrendering auf der Browserseite durch
Wenn dieselbe URL direkt eingegeben wird, werden der Seitenrahmen und der Seiteninhalt auf der NodeJS-Seite gerendert
Unabhängig davon, ob Sie die Seite im Browser wechseln oder dieselbe URL direkt eingeben, ist der angezeigte Inhalt derselbe.
Zusätzlich zur Erhöhung der Erfahrung und Reduzierung der Logikkomplexität. Es löst auch das SEO-Problem

Fall 3 Reine Browsing-Seite

Status: Die Seite bietet nur Informationen, mit wenig oder keiner Interaktion

Problem: HTML wird serverseitig generiert, CSS und JS werden an einem anderen Ort platziert und sind voneinander abhängig.
Antwort:
Durch NodeJS einheitliche Verwaltung von HTML-CSS-JS
Wenn Sie es in Zukunft zu einer komplexen Anwendung oder einer einseitigen Anwendung erweitern müssen, kann es problemlos übertragen werden.

Fall 4 Terminalübergreifende Seite

Situation: Dieselbe Anwendung muss unterschiedliche Schnittstellen und Interaktionen auf verschiedenen Endpunkten darstellen

Problem: Die HTML-Verwaltung ist oft nicht einfach auf der Serverseite und erfordert eine unterschiedliche Verarbeitung auf der Browserseite
Antwort:
Terminalübergreifende Seiten stellen ein Rendering-Problem dar und werden vom Frontend einheitlich behandelt.
Durch die NodeJS-Schicht und die Back-End-Servitisierung kann die beste Lösung für diese Art komplexer Anwendungen entworfen werden.

Zusammenfassung

Das Aufkommen von AJAX, clientseitigem MVC, SPA, bidirektionaler Datenbindung und anderen Technologien in der Vergangenheit war allesamt Versuche, die Engpässe zu lösen, die damals in der Front-End-Entwicklung auftraten.

Das Aufkommen der NodeJS-Mittelschicht ist auch ein Versuch, die Beschränkung des aktuellen Frontends auf die Browserseite zu lösen.

Dieser Artikel konzentriert sich auf die gemeinsame Nutzung von Front-End- und Back-End-Vorlagen und ich hoffe, dass er andere dazu inspirieren kann, darüber zu diskutieren, wie wir unseren Workflow verbessern und mit dem Back-End unter der NodeJS-Mittelschichtarchitektur zusammenarbeiten können -end macht einen besseren Job.