React ist ein Full-Stack-Framework (oder wird gerade zu einem)
(robinwieruch.de)- React entwickelt sich mit der Ergänzung von Server Components und Server Actions zu einem Full-Stack-Framework
Beginn der Framework-Kriege im Jahr 2010
- Die Framework-Kriege, die 2010 mit Backbone, Knockout und Ember begannen, wurden schnell von Angular und React fortgesetzt, und niemand konnte das Ergebnis vorhersagen
- Lange Zeit dominierten JavaScript-Anwendungen mit Client-Side Rendering (CSR)
- Diese Anwendungen werden auch Single-Page Applications (SPA) genannt und bestanden in der Regel aus einer kleinen HTML-Datei und einer großen JavaScript-Datei
- So war es jedenfalls, bevor Code-Splitting eingeführt wurde
Trennung von Frontend und Backend
- In dieser Zeit wurde die Frontend-Entwicklung von verschiedenen JavaScript-Frameworks und -Bibliotheken dominiert
- Das Backend war in der Regel nicht an eine bestimmte Sprache gebunden, und REST wurde zum Standard für die API-Kommunikation
- Als freiberuflicher Webentwickler arbeitete ich vor allem mit .NET-, Java-, Python- und PHP-Backends
- TypeScript/JavaScript sah ich im Backend nur bei Greenfield-Projekten oder kleinen Projekten, in denen man das Backend kontrollieren konnte
- Mit dem Aufstieg von Full-Stack-React könnte sich das jedoch ändern
- Interessant ist, dass Entwickler die Zeit zwischen 2010 und 2020 je nach Startzeitpunkt ihrer Karriere unterschiedlich wahrnehmen
- Entwickler, die vor 2010 angefangen haben, kamen aus einer Server-Side-Rendering-(SSR)-Welt und scheinen mit der jüngsten Rückkehr serverseitiger Technologien vertrauter zu sein
- Viele andere dagegen arbeiteten fast ein Jahrzehnt lang nur mit Client-Side-Rendering-(CSR)-Anwendungen und REST-APIs
- Jetzt wissen sie nicht so recht, wie sie die neue Full-Stack-React-Welt einordnen sollen
TypeScript etabliert sich als Industriestandard
- In den letzten Jahren hat sich TypeScript als Industriestandard herausgebildet
- TypeScript gibt Frontend-Entwicklern eine typisierte und leistungsfähige Programmiersprache an die Hand
- Als Entwickler TypeScript einmal angenommen hatten, gab es praktisch kein Zurück mehr
- Es ist interessant, wie kleine Änderungen im Code große Auswirkungen auf einzelne Entwickler und die gesamte Branche haben können
Schwierigkeiten mit TypeScript und REST
- Der Einfluss von TypeScript auf REST hat viele Behelfslösungen hervorgebracht
- OpenAPI (früher Swagger) existierte für die Dokumentation von REST-APIs, wird heute aber vor allem genutzt, um typisierte API-Interfaces zu erzeugen
- Obwohl sich in einer Client-Server-Architektur perfekte typsichere Interfaces bauen ließen, scheitern viele Projekte daran, dies von Anfang an sauber umzusetzen
-
Persönliche Anmerkung: „Es gibt sicher Entwickler, die mit einer OpenAPI-basierten Architektur gute Erfahrungen gemacht haben, aber leider gehöre ich nicht dazu.“
TypeScript verändert die Stimmung
- Es ist ziemlich interessant zu sehen, wie TypeScript hier die Wahrnehmung verändert hat
- Einerseits wirkten untypisierte SPAs mit REST (und OpenAPI zu Dokumentationszwecken) völlig „okay“
- Doch als TypeScript zum Standard und zur Norm wurde, wurden erzeugte Typ-Interfaces unangenehm in der Handhabung, weil man sich im Frontend-Code an einen höheren Qualitätsmaßstab gewöhnt hatte
- Die Nachteile erzeugter Typ-Interfaces sind offensichtlich:
- Es gibt immer einen Generierungsschritt
- Die generierte Ausgabe ist komplex
- Je nach anfänglicher Konfiguration ist der erzeugte Code nicht immer korrekt
Aufstieg von RPC und tRPC
- RPC ist kein neues Konzept, gewann aber dank tRPC im React-Ökosystem an Popularität
- Nach meiner Erfahrung als Solo-Entwickler über sechs Monate an einer Anwendung mit 80.000 Zeilen Code war es fast eine Offenbarung, Funktionen im Backend aufzurufen, um Daten zu lesen und zu schreiben
- Noch nie hatte ich auf beiden Seiten des Stacks mit TypeScript das Gefühl, produktiver zu sein
- Persönlich hatte ich mich nur einige Jahre zuvor in einer (generierten) typisierten GraphQL-Architektur ähnlich produktiv gefühlt
- Im gesamten Jahr 2023 konnte ich mir kaum etwas Besseres als tRPC vorstellen
- Funktionen im Backend aufzurufen, um Daten zu lesen und zu schreiben, fühlte sich revolutionär an
- Aber war das wirklich alles, was ich brauchte? Nein
Die Innovation von Server Components und Server Actions
- Für mich kam der echte Durchbruch 2024 mit Server Components und Server Actions
- Sie rufen nicht nur den Server auf, sondern schließen die Lücke zum Server, indem sie ermöglichen, Code auf der anderen Seite zu implementieren und auszuführen
- Server Components erlauben es, React-Komponenten auf dem Server auszuführen und dadurch direkt auf Datenquellen wie Datenbanken zuzugreifen, bevor als Antwort UI in JSX zurückgegeben wird
- Server Actions können unter der Haube HTTP-API-Endpunkte erzeugen, sodass Funktionen ähnlich wie bei einem Remote Procedure Call aufgerufen und ausgeführt werden können
- Server Components und Server Actions verwandeln React in ein Full-Stack-Framework
- Es ist eine spannende Zeit für den Übergang vom Frontend in eine Full-Stack-Umgebung
Reacts Unterstützung für Server Components und Server Actions
- React selbst liefert nur die grundlegenden Bausteine und Spezifikationen für Server Components und Server Actions
- Auf React aufbauende Meta-Frameworks können die Lücke schließen, indem sie als Bundler die Anweisungen zwischen Client und Server interpretieren
- Next.js führt derzeit die Implementierung von Server Components und Server Actions an
- Next.js unterstützte bereits zuvor Server-Side Rendering (SSR), doch jetzt können Entwickler über Server Components und Server Actions auf serverseitige Ressourcen wie Datenbanken und Message Queues zugreifen
Der Beginn der Full-Stack-Entwicklung
- Full-Stack-Entwicklung mit React steht erst ganz am Anfang
- Wenn Entwickler mit Server Components und Server Actions beginnen, direkt auf Datenbanken zuzugreifen, wird es darum gehen, die Komplexität jenseits einfacher CRUD-Anwendungen zu beherrschen
- Mit gründlicher Ausbildung werden Frontend-Entwickler die Umsetzung von Backend-Architekturen mithilfe von Schichten, Design Patterns und Best Practices bald beherrschen
- Ganz ehrlich: Niemand möchte ORM-Funktionsaufrufe direkt in React-Komponenten sehen
Erwartung an den Paradigmenwechsel
- Ich freue mich sehr auf diesen Paradigmenwechsel
- Eine neue Ära steht bevor, in der React-Entwickler vertikale Features von der UI bis zur Datenbank umsetzen
8 Kommentare
Es hat doch bereits alles für den Full-Stack übernommen.
Wenn man wie bei der App-Entwicklung auch an die Kompatibilität mit anderen Sprachen denken muss, scheint mir tRPC keine besonders gute Wahl zu sein. 😅
Ich denke, GraphQL ist die beste Lösung.
Ich denke, dass Next.js Server Actions das Problem haben, zufällige API-Endpunkte, die Entwickler nicht kontrollieren können, öffentlich offenzulegen, und ich halte das für eine ziemlich kritische Schwachstelle.
Könnten Sie mir vielleicht sagen, um welche Schwachstelle es sich dabei handelt, die Sie erwähnt haben? Wenn ich danach suche, stoße ich zwar auf eine SSRF-Schwachstelle, bin mir aber nicht sicher, ob das die richtige ist. Ich lerne gerade Next.js und frage aus Interesse nach.
Was war ursprünglich eigentlich die Absicht der Leute, die SPA vorangetrieben haben? Es ist zwar deutlich besser als in der Zeit, als man mit jQuery das DOM manipuliert hat, aber die Konzepte, die man für Architektur und Entwicklung von Backend und Frontend braucht, verschwinden nicht, sondern scheinen nur ihren Platz zu wechseln. Allein beim Routing wurde es vom Server auf den Client verlagert, und wegen des Trends zu serverseitigem Rendering versucht man jetzt wieder, es zurück auf den Server zu holen.
Ich frage mich, ob in drei Jahren in Coding-Bootcamps oder Kursen überhaupt noch React im SPA-Stil gelehrt wird.
War nicht die flüssige Navigation zwischen Seiten der größte Vorteil? (zumindest damals)
Der ursprüngliche Beitrag endet damit, dass der Autor für seinen geplanten Full-Stack-Webentwicklungs-Kurs The Road to Next wirbt ^^;