Erforschung und Nachdenken über Webentwicklungsmodelle

In den letzten Jahren haben sich mit der Entwicklung der Software- und Hardwaretechnologie auch die Technologien im Zusammenhang mit der Webentwicklung sprunghaft weiterentwickelt. Im Vergleich zu vor zehn oder sogar fünf Jahren waren sowohl die Geschäftskomplexität als auch die Technologieauswahl völlig anders . Abmessungen.

Bei diesem Artikel handelt es sich um einen Aufsatz, der hauptsächlich das persönliche Verständnis und Denken des Autors über Webentwicklungsmodelle darlegt.

Vorwort

Wenn man vor fünf oder sechs Jahren oder früher von Webentwicklung sprach, bezog man sich meist auf eine bestimmte Technologie, die hauptsächlich auf Back-End-Sprachen basierte, wie zum Beispiel Java Web, Ruby on Rails, PHP und andere Technologie-Stacks. Nach der rasanten Entwicklung webentwicklungsbezogener Technologien in den letzten Jahren heißt es nun, dass die Webentwicklung in verschiedene Szenarien unterschiedlich unterteilt werden kann.

Typischerweise wurden in diesem Umfeld das sogenannte Web-Frontend, Web-Full-Stack und andere technische Richtungen geboren, die in den letzten Jahren erst allmählich unterteilt wurden.

Kehren wir zum Thema zurück, sprechen wir über Webentwicklung. Was ist also das Wesentliche an der Webentwicklung?

Wenn wir dieses Thema relativ abstrakt betrachten Ebene geht es bei der Webentwicklung um den Umgang mit Clients. Anfrage und Serverantwort sind zwei Dinge.

Um 2008, einem Standardmodell für Webanwendungen oder Webentwicklung, besteht die Hauptaufgabe des Backends darin, Daten aus der Datenbank abzurufen und HTML-Vorlagen auf der Serverseite zu generieren. und senden Sie dann die generierte Vorlage an den Kunden. Nachdem der Client die Vorlage erhalten hat, fügt er js und css in den Client ein, generiert einen Dom-Baum, rendert ihn dann auf einer Seite und präsentiert ihn dem Benutzer.

Dieses Muster wird immer noch bei der Entwicklung einiger Webanwendungen verwendet. Dieses Modell ist heute allgemein als traditionelles Entwicklungsmodell oder als Front-End- und Back-End-Hybrid-Entwicklungsmodell bekannt. Eines seiner Hauptmerkmale besteht darin, dass die Seitenvorlage vom Backend ausgespuckt wird und selbst die ausgespuckte Vorlage über Stile und Interaktionen verfügt. Das Frontend übergibt die Vorlage einfach an den Browser, um sie in einen DOM-Baum zu rendern und eine Seite zu generieren. Manchmal fügt das Frontend auch etwas JS-Code ein, um die dynamische Interaktion der Seite zu unterstützen.

Ich habe dieses Entwicklungsmodell tatsächlich selbst erlebt. In der Vergangenheit, als JavaEE und JavaWeb relativ beliebt waren, haben wir häufig ein bestimmtes System geschrieben, z. B. ein Studentenverwaltungssystem, ein Bibliotheksverwaltungssystem usw., und Java verwendet, um die JDBC-Linkdatenbank auf der Serverseite zu betreiben und diese zu erhalten Erforderliche Daten, und dann kombinieren Sie die Daten mit Die JSP wird zusammengestellt und an den Client gesendet, und der Client übergibt sie dann zum Rendern an den Browser. Später erlebte ich auch das Entwicklungsmodell von PHP plus Smarty. Obwohl diese beiden Methoden unterschiedliche Technologie-Stacks verwenden, ist das Wesentliche des Entwicklungsmodells dasselbe.

Zu diesem Zeitpunkt werden wir jedoch feststellen, dass derselbe Entwickler mehrere Rollen spielt und serverseitigen Code, Code auf Vorlagenebene und sogar etwas JS- und CSS-Code schreiben muss. Dies erfordert, dass Entwickler zwischen verschiedenen Rollen wechseln. Entwickler, die sich auf die Serverseite konzentrieren, hassen es jedoch oft oder sind nicht gut darin, Vorlagen, Interaktionen und Stile zu schreiben. Zu diesem Zeitpunkt wurde ein sogenanntes Seitenentwicklungsmodell entwickelt. Der sogenannte Seitensatz bedeutet, dass der Vollzeit-Front-End-Entwickler zunächst die statische Seite ausschneidet und sie dann an die Back-End-Entwicklung sendet, um die Vorlage zu imitieren und dann zu schreiben und die Teile, die dynamische Änderungen erfordern, durch die zu ersetzen Back-End-Vorlagensyntax. Dieses Modell hat sich als ineffizient erwiesen und stellt keine geeigneten Ressourcen für die Anwendungsentwicklung bereit.

Wenn es um Entwicklungseffizienz geht, sollten wir in einer groß angelegten Teamzusammenarbeit an der Idee festhalten, dass die richtigen Leute die richtigen Dinge tun, Arbeitsteilung und Zusammenarbeit sowie Fließbandabläufe auf jeden Fall wichtig sind beste Lösung.

Im traditionellen Entwicklungsmodell gibt es einige Schwachstellen, die gelöst werden müssen. Dies führte zu der Idee, die Front-End- und Back-End-Entwicklung zu trennen. Verschiedene Arten von Arbeiten sind nur für ihre eigenen Angelegenheiten verantwortlich und folgen dann einer bestimmten Kooperationsvereinbarung, um eine effiziente Ausgabe zu erzielen.

Das Obige ist im Grunde die Entwicklungsgeschichte der Front-End- und Back-End-Trennung.

Im Front-End- und Back-End-Trennungsentwicklungsmodus ruft die Serverseite die Metadaten aus der Datenbank ab und spuckt die Daten nach der Verarbeitung direkt anstelle einer Vorlage aus. Nachdem die Clientseite die Daten erhalten hat, führt sie auf der Clientseite ein Vorlagenrendering durch, um eine Seite zu generieren und diese dem Benutzer anzuzeigen.

Im Vergleich zum herkömmlichen Entwicklungsmodell übernimmt der Server nicht mehr das Geschäft der Vorlagenschicht, sondern stellt nur Daten direkt bereit. Verantwortlichkeiten sind singulärer. Zu diesem Zeitpunkt kann der Server Dienste entsprechend unterschiedlichen Geschäftsanforderungen oder Architekturunterschieden direkt bereitstellen. Unter Service versteht man hier oft Microservices. Selbst in einigen nicht absoluten Front-End- und Back-End-Trennungsmodi stellt der Server auch Vorlagenfragmente bereit.

Offensichtlich muss die Front-End-Entwicklung in diesem Modus mehr Dinge tun, und wenn das Unternehmen wächst, kann die Menge an Front-End-Logik und -Code größer und komplexer werden. Dies hat wiederum die Entstehung verschiedener Front-End-Frameworks gefördert, wie z. B. Angular, ein großes und umfassendes Framework, React, ein Framework, das sich auf die Lösung einer bestimmten Geschäftsebene konzentriert, und Webpack, ein Framework, das den Mangel an Gebäuden ausgleicht Funktionen usw. Verschiedene Frameworks selbst werden die Entwicklung ihrer umliegenden Communities vorantreiben und dazu führen, dass der gesamte Front-End-Entwicklungskreis eine explosive technologische Entwicklung erlebt.

Zusätzlich zur traditionellen Webentwicklung werden aufgrund der rasanten Entwicklung des mobilen Internets auch die Entwicklung mobiler Endgeräte, WeChat-Entwicklung, H5-Entwicklung und andere Bereiche von Front-End-Entwicklern akzeptiert. Aufgrund des Aufstiegs der NodeJS-Plattform ist die Frontend-Entwicklung möglicherweise nicht mehr auf browserseitige Entwicklungsarbeiten beschränkt. Mithilfe der NodeJS-Plattform und Frameworks wie Express und Koa verfügen Frontend-Entwickler bereits über die Möglichkeit sich an der serverseitigen Entwicklung zu beteiligen.

Hier ist ein Artikel, der ausreicht, um einen Einblick in die Breite und Aktualisierungsgeschwindigkeit des Technologie-Stacks der Front-End-Entwicklung zu erhalten.

Daher gibt es wirklich viele Inhalte, die besprochen werden können. Dieser Artikel wird nicht zu unterschiedlich sein, sondern nur Inhalte im Zusammenhang mit der Webentwicklung besprechen. Im Folgenden konzentrieren wir uns auf die Diskussion von Webentwicklungsmodellen auf der PC-Seite, beginnend mit der Trennung von Front-End und Back-End, und erläutern die beiden Entwicklungsmodelle, die ich erlebt habe, um andere zu inspirieren.

Mittelschichtmodus

Wie bereits erwähnt, aufgrund der Aktivität der NodeJS-Plattform, insbesondere der Entstehung einiger ausgereifter serverseitiger Entwicklungsframeworks wie Express, Koa usw., vorne Endentwickler dürfen mit JavaScript serverseitige Programme entwickeln und sogar Datenbanken betreiben. Dies eröffnet auch Front-End-Entwicklern, die zuvor auf der Browserseite entwickelt haben, neue Arbeitsszenarien. Wenn sie einige Kenntnisse über Datenbanken, HTTP-Protokolle, Netzwerksicherheit, Webserver usw. beherrschen, dann empfinde ich persönlich dieses Front-End Entwickler können auf jeden Fall. Es sollte kein Problem sein, Ihre Rolle zu einem Back-End-Entwickler zu wechseln und in einigen gängigen Szenarien die Back-End-Entwicklung zu übernehmen.

Dies hat offensichtlich höhere Anforderungen an traditionelle Front-End-Entwickler gestellt. Die an ihrer Arbeit beteiligten Bereiche sind auf niedrigerem Niveau als zuvor und sie werden häufiger mit echten Back-End-Entwicklern kommunizieren Wir werden zu diesem Zeitpunkt sogar an der Formulierung einiger Vereinbarungen und Normen beteiligt sein müssen. Wie können Sie das sonst tun, wenn Sie nicht auf dem Kanal kommunizieren? >
Dies Der Titel eines Teils des Inhalts ist der Mittelschichtmodus. Was ist also der Mittelschichtmodus? Mein persönliches Verständnis ist, dass die Trennung von Front- und Back-End der Ausgangspunkt ist und mit Hilfe des Auf der NodeJS-Plattform wird eine Ebene zwischen dem Web-Back-End und dem traditionellen Front-End (UI-Ebene) hinzugefügt. Die mittlere Ebene ist für die Verarbeitung von Daten, Vorlagen, Geschäftsinhalten und anderen Inhalten verantwortlich. Es ist die Brücke zwischen dem Backend und der UI-Ebene. Manche Leute nennen diese mittlere Schicht gerne die Leimschicht.

Erstens gibt es hier möglicherweise kein klares Backend, stattdessen handelt es sich um REST Server, Micro Service usw. Ihr Kern besteht immer noch darin, Daten an die oberen Ebenen bereitzustellen. Diese Inhalte gehören alle zur Kategorie Backend.

Die obere Schicht des Backends ist das Frontend. Das sogenannte Frontend ist hier eigentlich eine weit gefasste Referenz, die eine Sammlung von Vorgängen darstellt, wie z. B. die Reaktion auf Benutzeranfragen und -interaktionen. In dieser Sammlung ist die oberste Ebene der Benutzer, dann die Client-(Browser-)Ebene und dann die NodeJS-Ebene unterhalb des Clients. Es wird auch eine Nginx-Schicht geben.

Wenn der Benutzer im ersten Szenario eine Seitenanforderung initiiert, akzeptiert der Browser die Anforderung zunächst und leitet sie dann an Nginx weiter, damit Nginx die Anforderung entsprechend dem Typ an den entsprechenden NodeJS-Layer-Dienst weiterleitet der Anfrage. Die NodeJS-Schicht analysiert intern die von der Nginx-Schicht weitergeleitete Anforderung, führt die entsprechende Geschäftsklasse aus, stellt die Daten zusammen und gibt schließlich eine HTML-Vorlage an den Client (Browser) aus. Nachdem der Browser die Vorlage erhalten hat, injiziert er die js und des Clients CSS-Code. Rendern Sie ihn dann in eine Seite und präsentieren Sie ihn dem Benutzer.

Wenn der Benutzer im zweiten Szenario eine interaktive Anfrage auf der Seite initiiert, z. B. durch Klicken auf eine Schaltfläche, um eine Anfrage zu initiieren, wird die Anfrage schließlich an die NodeJS-Ebene weitergeleitet. Die NodeJS-Ebene verarbeitet die Anfrage nach Erhalt und senden Sie die Antwort dann an den Browser zurück.

Grundsätzlich werden die meisten Anfragen und Interaktionen vom Client (UI-Schicht) in der NodeJS-Schicht verarbeitet. Die UI-Schicht ist von den zugrunde liegenden REST-Diensten oder Microservices isoliert. Natürlich gibt es Sonderfälle, z. B. Szenarios mit Bildverifizierungscodes, in denen der Browser direkt den zugrunde liegenden REST-Dienst oder Mikrodienst anfordert.

Übung der Lösung für den Mittelschichtmodus

Hier versuche ich, eine Lösung für den Mittelschichtmodus mit Schwert-Plus zu geben. Seine Positionierung ist keine große und umfassende Lösung aus einer Hand, sondern eine Sammlung von Tools und die Verfeinerung gemeinsamer Funktionen für eine bequemere Entwicklung der NodeJS-Schicht. Basierend auf dem Koa-Programm bietet es Funktionen wie Protokollierung, Vorlagenrendering, Anforderungszugriff, Routing-Analyse und Business-Class-Abstraktion. Es besteht ein gewisser Grad an Kopplung zwischen verschiedenen Funktionskomponenten darin. Daher besteht die Voraussetzung für die Verwendung von Sword-Plus darin, NodeJS als mittlere Schicht einzuführen; die NodeJS-Schicht stellt Vorlagen für zusammengestellte Daten für die obere Schicht bereit.

Sword-plus umfasst die folgenden Komponenten: Router, Pugger, Connector, Logger, Handler und SwordError.

Der Router wird verwendet, um die gepackte Anfrage von Koa zu analysieren. Es gibt zwei Hauptmethoden:

Parsen, Parsen von Routen

Anbieter, Generieren von Geschäftsklassen und Starten der Geschäftslogik entsprechender Routen

Pugger wird hauptsächlich zum Zusammenstellen von Daten und verwendet Rendern Sie es als Jade/Pug-Vorlage.

Die Vorlage hier ist eine serverseitige Vorlage. Während des Rendering-Vorgangs können Sie über Parameter konfigurieren, ob Rendering-Protokolle aufgezeichnet werden sollen.

Die Hauptmethode render wird verwendet, um Daten zusammenzustellen, um serverseitige Vorlagen zu generieren.

Das Rendering-Protokoll zeichnet alle Fehlermeldungen während des Rendering-Vorgangs auf.

Der Connector kapselt die Anforderungsvorgänge der NodeJS-Ebene –>REST-Ebene, der UI-Ebene –>NodeJS-Ebene. Node-Fetch wird intern verwendet. Es ermöglicht auch die Aufzeichnung von Anforderungsprotokollen bei der Bearbeitung von Anforderungen. Es gibt zwei Methoden:

Get, die Get-Anfrage ausführen

Post, die Post-Anfrage ausführen

Logger ist eine Protokollkomponente, die alle Protokolle in die folgenden Kategorien unterteilt. Kategorie),

Schwerwiegend, Fehler, Warnung, Info

Anfrage, Antwort, Render, Aktion

Die erste Zeile ist eigentlich Bunyans eigener Alias ​​auf Protokollebene. Die zweite Zeile ist abstrahiert anhand verschiedener Geschäftsszenarien.

Anfrage, das Protokoll der restlichen API-Anfrage, die vom NodeJS-Programm an den REST-Server gesendet wurde

Antwort, das Protokoll der restlichen API-Antwort, die vom REST-Server an das NodeJS-Programm zurückgegeben wurde

Rendern, die serverseitige Vorlage Das sogenannte Rendering-Protokoll hat hier eigentlich nichts mit dem Client (Browser) zu tun. Es stellt nur den Zusammenstellungs- und Kompilierungsprozess von Vorlagendateien und -daten dar
Aktion, alle vom Benutzer initiierten Interaktionsprotokolle, einschließlich Seitenanfragen, Formularübermittlungen, Client-Ajax-Anfragen usw.

Jedes Protokoll ist eine Datensatzabstraktion. Jede Datensatzinstanz weist auch Ebenenunterschiede auf Die häufig verwendete Kategorieebene verfügt über die folgenden Informationstypen: Warnung und Fehler.

Handler ist die Abstraktion der obersten Ebene des Business-Class-Modells. Nachdem alle Anfragen vom Router analysiert wurden, werden bestimmte Geschäftsklassen über den Handler abgeleitet. Im Handler können Sie eine interne Erweiterung oder eine externe Erweiterung (Handler.inject) verwenden, um funktionale Methoden hinzuzufügen, die von allen Geschäftsklassen verwendet werden können. Darüber hinaus stellt der Handler mehrere Suite-Instanzobjekte als Proxy bereit, sodass diese in bestimmten Geschäftsklassen verwendet werden können. Die folgenden Methoden werden im Handler bereitgestellt:

erbt Nach dem Parsen des Routers wird die spezifische Business-Klasse Clazz in Router.provider über diese Methode generiert.

Versenden, adaptive Weiterleitung von Get- und Post-Anfragetypen in Business-Klassen durchführen.

Injizieren: Wenn der Server gestartet wird, können externe Erweiterungen nach Bedarf injiziert werden. Nach der Injektion können sie in allen generierten Geschäftsklassen verwendet werden.

SwordError ist das Fehlerpaket von SwordPlus. Wird verwendet, um Fehler gleichmäßig zu verteilen.

Derzeit sind die Arten von SwordPlus-Fehlern wie folgt:

LACK_OF_PARAMETER

INVALID_OF_PARAMETER

404

ERROR_OF_MAKEDIR

SUFFIX_NOT_SUPPORT

SUFFIX_IS_REQUIRED

TIMEOUT

MODULE_NOT_FOUND

NO_TEMPLATE_FILE

Vollständig getrennter Modus

Der sogenannte Complete TrennungsmodusDas heißt, die Front-End-Entwicklung in diesem Modus ist im herkömmlichen Sinne vollständig von der Back-End-Entwicklung isoliert und beinhaltet nicht die Entwicklung der mittleren Schicht.

Das Front-End und das Back-End interagieren über Ajax-Anfragen, und das Back-End gibt Daten an das Front-End zurück. Alle Dinge auf der Clientseite, einschließlich Seitenrendering, Interaktion, Stile, Routing usw., werden vom Frontend selbst verwaltet. Zu diesem Zeitpunkt führt die Front-End-Entwicklung häufig ein ausgereifteres Front-End-Open-Source-Framework als zugrunde liegende Auswahl ein. Dieses Entwicklungsmodell verfügt über einzigartige Anwendungsszenarien, z. B. Single Page Application, ein Managementsystem innerhalb des Unternehmens usw. Wenn der Front-End-Entwickler mit der Auswahl des zugrunde liegenden Frameworks vertraut ist, ist die Entwicklungsgeschwindigkeit oft sehr hoch. Grundsätzlich können einige Probleme, die bei der tatsächlichen Entwicklung auftreten, in der Framework-Community gelöst werden.

Diese Art der Entwicklung hat auch ihre Nachteile. Mit zunehmender Nachfrage wird die Menge des Front-End-Codes immer größer und die verschiedenen Interaktionen und die modulare Verwaltung des Front-Ends werden immer größer schwerer. Nicht pflegeleicht. Ein weiterer Punkt ist, dass es so viele Möglichkeiten gibt, aus denen man wählen kann, und manchmal weiß man nicht, welche man wählen soll.

Meine persönliche Meinung ist, Implementierungslösungen und Technologien basierend auf Szenarien und Bedürfnissen auszuwählen und nicht blind neue Technologien und Trends zu verfolgen. Mehrere Mainstream-Frameworks, die derzeit im Front-End-Bereich beliebt sind, wie Angular, React, Vue usw., haben alle ihre Vor- und Nachteile. Angular selbst ist beispielsweise ein All-Inclusive-Framework. Sobald Sie sich damit vertraut gemacht haben, ist die Einstiegsschwelle niedrig und es ist schwierig, in die Tiefe zu gehen, und es gibt einige Szenarien, in denen es darum geht es ist nicht geeignet. React konzentriert sich nur auf die Verarbeitung der Ansichtsebene und bietet eine sehr gute Vorstellung davon, wie die Ansichts- und Datenebenen interagieren und aktualisiert werden können. Die vorhandenen Lösungen zur Datenstatusverwaltung wie Redux sind jedoch meiner Meinung nach nicht sehr einfach zu verwenden. Der Autor von VueJS hat die Vorteile vieler Frameworks auf dem Markt übernommen. Ich persönlich habe das Gefühl, dass es sich noch nicht in einer Produktionsumgebung befindet, daher werde ich nicht zu viel kommentieren.

Dennoch denke ich persönlich, dass die aktuelle schnelle Entwicklung des Front-End-Kreises sehr gut ist. Auch wenn es viele neue Dinge gibt und es möglicherweise viele Möglichkeiten gibt, das gleiche Problem zu lösen, ist dies der Fall Es hat keinen Einfluss auf uns, von ihnen zu lernen, und sogar ihre Fallstricke zu erfahren. Ob sie in einer Produktionsumgebung eingesetzt werden sollten, ist eine andere Frage, daher hasse ich persönlich den aktuellen Status quo des vorderen Kreises.

Zusammenfassung

Der Hauptzweck dieses Artikels besteht darin, einige meiner persönlichen Erkenntnisse und Erkundungen des aktuellen Webentwicklungsmodells näher zu erläutern. Ich persönlich denke, dass es sich bei dem Artikel um das mittlere Entwicklungsmodell handelt ist eine Art Allheilmittel für die Entwicklung. Zusätzlich zu den im Artikel erwähnten Inhalten habe ich meiner Meinung nach einige Punkte für die weitere Erkundung angegeben.