Vor etwa einem Jahr wurde Nikita Prokopovs offensichtlicher Artikel über Enttäuschungen bei Software veröffentlicht. Dem positiven Feedback nach zu urteilen, sind Entwickler der Qualität ihrer Produkte nicht gleichgültig. Vielleicht ist es Zeit zu schauspielern?
In diesem Artikel möchte ich über meine Entwicklung sprechen, die meiner Meinung nach die Hauptleistungsprobleme des modernen Webs beheben und den Benutzer ein wenig glücklicher machen kann. Die Probleme sind: starker JS-Code, hohe Zeit für die Arbeit mit der Seite (TTI) , hoher Speicher- und Prozessorverbrauch.
Bevor Sie weiterlesen, folgen Sie dem Link . Versuchen Sie, ein paar Spiele zu spielen. Spielen Sie vorzugsweise vom Desktop aus.
Ein bisschen Geschichte
Der Webbrowser war von Anfang an als Thin Client für Webserver konzipiert. Der Browser zeigte die vom Server empfangenen Hypertextseiten an. Einfach und elegant. Wie so oft wird eine schöne Idee mit der Realität konfrontiert, und nach einigen Jahren haben Browserhersteller die Unterstützung für die Skriptsprache hinzugefügt. Anfangs diente es nur als Dekoration, und bis Mitte der 2000er Jahre galt es als bewährte Methode, Webseiten ohne JS-Unterstützung zum Laufen zu bringen.
Ein moderner Ansatz für die Website-Entwicklung ist das Ergebnis der Entwicklung von Interaktivitätsanforderungen für Benutzeroberflächen. Aufgaben zur Verbesserung der Interaktivität fielen den Programmierern auf die Schultern. Diese hatten oft nicht die Kompetenzen und Befugnisse, um eine „End-to-End“ -Lösung zu entwickeln. Layoutdesigner lernten das Schreiben von JS und wurden zum Frontend. Die Logik begann allmählich vom Server zum Client zu fließen. Für den Spitzenreiter ist es praktisch, für den Browser zu schreiben, und für das Back-End ist es praktisch, nicht an den Benutzer zu denken (geben Sie mir meinen JSON, und dann wächst zumindest das Gras nicht). Noch vor zwei Jahren gab es ein starkes Interesse an serverloser Architektur, bei der vorgeschlagen wurde, dass JS-Anwendungen direkt mit der Datenbank und den Ereignisbussen zusammenarbeiten.
Derzeit ist die "sphärische Website im luftleeren Raum" eine komplexe JS-Anwendung und ein einfacher API-Server, mit dem sie kommuniziert. Die Hauptlogik läuft auf einem Thick-Client, die Serverseite degeneriert zu einer einfachen Ebene in der Datenbank.
Die Notwendigkeit, die Logik auf dem Client zu halten, führt zu Problemen. Wenn der Service „abhob“ und anfing, Geld zu verdienen, wird es in Bezug auf die Produktivität nur noch schlimmer. Die Anforderungen werden sich ändern. Das Entwicklungsteam wird sich ändern. Es wird immer mehr neuen Code geben und der alte Code wird nicht bereinigt. Die Seite schwillt von Abhängigkeiten an, es wird JSON geladen, über dessen Zweck sich niemand erinnert, aber es ist beängstigend zu löschen, plötzlich bricht etwas zusammen. Es werden Hintergrundaufgaben von SetInterval angezeigt, die jeweils mehrere Millisekunden pro Sekunde ausgeführt werden. Dies führt nach einiger Zeit zu Bremsen und zum Aufwärmen des iPad des unglücklichen Benutzers, sodass er Spiegeleier darauf braten kann. Es endet mit der Tatsache, dass das verbrannte Front-End dem Manager mit einem Vorschlag vorgelegt wird, alles in einem neuen Framework von Grund auf neu zu schreiben. Der Manager wird dies ablehnen und das Front-End wird beginnen, zwei Frameworks zusammen zu verwenden.
Wie Korolev funktioniert
Was ist, wenn wir zum Punkt des Berichts zurückkehren? Der Moment, in dem jemand auf die Idee kam, Inhalte zu aktualisieren, ohne die Seite neu zu laden, und die historische Unvermeidlichkeit zu AJAX führte? Was ist, wenn Sie alles auf dem Server belassen und einen Thin Client erstellen? Die besten Websites führen SSR (Server Page Pre-Rendering) durch, sodass der Benutzer die Benutzeroberfläche sieht, bevor JS geladen und gestartet wird. Sie können weiter gehen und auf dem Client nur den Code belassen, der für die Verarbeitung von E / A verantwortlich ist, angesichts der aktuellen Anforderungen an die Interaktivität. Gedanken darüber flossen in das Korolev-Projekt ein .
Wie funktioniert es auf der Client-Seite? Der Benutzer kommt auf die Seite. Der Server gibt den generierten HTML-Code und ein kleines Skript (~ 6 KB ohne Komprimierung) an, das über einen Web-Socket eine Verbindung zum Server herstellt. Wenn ein Benutzer ein Ereignis auslöst (z. B. einen Klick), sendet das Skript es an den Server. Nachdem der Server das Ereignis verarbeitet hat, generiert er eine Liste von Befehlen der Form "dort ein neues <div> hinzufügen", "einem solchen Element eine Klasse hinzufügen", "ein solches und ein solches Element löschen". Der Client wendet die Befehlsliste auf das DOM an. Daher wird nicht mit HTML gearbeitet - das Skript arbeitet direkt mit dem DOM. Machen Sie sich also keine Sorgen, dass der Inhalt des Formulars oder die Position des Bildlaufs zurückgesetzt werden.
Was passiert auf dem Server? Wenn eine Anfrage für eine Seite vom Browser kommt, erstellt Korolev eine neue Sitzung. Für die Sitzung wird der Anfangszustand erstellt, der im Cache gespeichert wird. Aus diesem Status wird HTML generiert, das dem Client als Antwort auf die Anforderung übergeben wird. Außerdem speichert der Server das "virtuelle DOM" in der Sitzung. Nach dem Anfordern der Seite akzeptiert der Server die Anforderung zum Öffnen des Web-Sockets. Korolev verknüpft einen offenen Web-Socket mit einer Sitzung. Jedes vom Client kommende Ereignis kann den der Sitzung zugeordneten Status ändern. Jede Statusänderung führt zu einem Aufruf der render , die ein neues "virtuelles DOM" bildet, das mit der alten Version verglichen wird. Der Vergleich führt zu einer Liste von Befehlen, die an den Client gesendet werden sollen.
Was passiert im Code und im Kopf des Entwicklers? Das Obige könnte Sie an React erinnern, mit dem Unterschied, dass alles auf dem Server läuft. In Bezug auf den Entwicklungsansatz haben wir auch etwas Ähnliches. Wenn Sie also mit React oder einem anderen "virtuellen DOM" gearbeitet haben, ist Ihnen der Ansatz der Königin vertraut. Wenn Sie mit React nicht vertraut sind, stellen Sie sich vor, Sie haben Daten, die Sie in die Vorlage einfügen. Stellen Sie sich vor, dass gemäß der Vorlage Ereignishandler verstreut sind, die Daten ändern können (nicht jedoch das DOM). Sie ändern die Daten, die Seite ändert sich. Korolev selbst hat herausgefunden, wie man das DOM ändert.
Leistung
Es gibt zwei beliebte Fragen zu Korolev: "Was ist, wenn die Verzögerungen hoch sind?" Und "Wird dies meinen Server nicht laden?". Beide Fragen sind sehr vernünftig. Der Front-End-Programmierer ist es gewohnt, dass sein Programm auf dem lokalen Computer des Benutzers ausgeführt wird. Dies bedeutet, dass die daran vorgenommenen Änderungen übernommen werden, sobald der JS-Computer die Ausführung des Codes beendet hat und der Browser mit dem Rendern beginnt. Ich habe am Anfang speziell ein Beispiel für die Verwendung von "mit maximaler Geschwindigkeit" gezeigt. Sie konnten die Verzögerung nur beobachten, wenn Sie von der anderen Seite der Welt kamen (die Server befinden sich in Moskau) oder über GPRS im Internet saßen. Nun, oder mein erbärmlicher virtueller Server mit einem Kern und 1 GB RAM konnte den Habr-Effekt nicht ertragen.
Die Frage zur Serverlast wird normalerweise von Beckendern gestellt. Die Change Output Engine arbeitet sehr schnell: ~ 10 Tausend Schlussfolgerungen pro Sekunde für zwei beliebige Bäume mit 500 Knoten auf dem Junior Macbook von 2013. Statisches Rendern liefert ebenfalls ein ziemlich gutes Ergebnis: Bis zu 1 Million Seiten pro Sekunde. Jedes "virtuelle DOM" wird in einer speziellen serialisierten Form gespeichert und verarbeitet und benötigt 128 KB für eine durchschnittliche Webseite. Der Ausgabeprozess ist speziell optimiert und hat keinen Overhead für Speicher und GC.
In Bezug auf die Geschwindigkeit der Entwicklung bietet Korolev hier große Vorteile. Es ist nicht erforderlich, eine zusätzliche Ebene zwischen der Datenbank und dem Server zu schreiben. Es ist nicht erforderlich, ein Protokoll zwischen Client und Server auszuhandeln. Sie müssen sich keine Gedanken über die Modularität des Frontends machen - das JS-Gewicht auf dem Client bleibt immer gleich. Keine zusätzliche Logik für Serverereignisse erforderlich: Akzeptieren Sie einfach die Nachricht aus der Warteschlange und ändern Sie den Status der Sitzung. Korolev rendert und übermittelt sie.
Preis
Sie müssen für die Leistungen bezahlen. Einige Gewohnheiten müssen aufgegeben und andere neu erworben werden. Beispielsweise müssen Sie JS-Animationen aufgeben und mit CSS-Animationen zufrieden sein. Sie müssen lernen, wie Sie die Infrastruktur zunächst geoverteilt machen, wenn Sie Benutzer aus verschiedenen Ländern mit hoher Qualität bedienen möchten. Ich muss JS verlassen und zur Scala gehen.
Ich schäme mich ein wenig (eigentlich nicht), dass ich den Leser in die Irre geführt habe und nicht sofort gesagt habe, dass Korolev in Scala geschrieben wurde. Würden Sie bis zu diesem Punkt lesen, wenn ich sofort darüber sprechen würde? Wenn ich über die Königin spreche, muss ich zwei Stereotypen überwinden. Der erste Grund ist die Tatsache, dass das Rendern von Servern als etwas Langsames und nicht als Interaktives wahrgenommen wird. Der zweite hängt mit der Tatsache zusammen, dass Scala etwas Kompliziertes ist. Und das erste und zweite Stereotyp haben nichts mit der Realität zu tun. Darüber hinaus ist das Programmieren im React-Stil auf Scala bequemer als auf JS. Das moderne JS tendiert zur funktionalen Programmierung, Scala nimmt es aus der Box. Beispielsweise verfügt jedes Objekt in Scala über eine copy() -Methode, mit der Sie ein Objekt kopieren können, indem Sie einige Felder ändern. Unveränderliche Sammlungen sind in die Scala-Standardbibliothek integriert.
Fazit
Korolev wurde drei Jahre lang von mehreren Entwicklern entwickelt und viele "Kinder" -Probleme werden darin gelöst. Das Projekt ist gut dokumentiert, alle Funktionen werden mit Beispielen abgedeckt. Ich schlage vor, die Umsetzung der Königin mit kleinen unabhängigen Diensten zu beginnen. Ich hoffe, Korolev hilft dabei, die Programme weniger enttäuschend zu machen.
Link zum Projekt auf Github