React est un framework full stack (ou en train de le devenir)

xguru · 2024-08-26T10:21:02+09:00

Avec l’ajout des Server Components et des Server Actions, React évolue vers un framework full stack Le début des guerres de frameworks en 2010 Les guerres de frameworks, lancées en 2010 avec Backbone, Knockout et Ember, ont été rapidement suivies par Angular et React, sans que personne ne puisse vraiment en prévoir l’issue Pendant longtemps, les applications JavaScript en client-side rendering (CSR) ont dominé Ces applications, aussi appelées single-page applications (SPA), se composaient généralement d’un petit fichier HTML et d’un gros fichier JavaScript C’était le cas avant l’introduction du code splitting La séparation entre front-end et back-end Durant cette période, le développement front-end a été dominé par divers frameworks et bibliothèques JavaScript Le back-end n’était généralement pas lié à un langage en particulier, et REST est devenu le standard pour la communication via API En tant que développeur web freelance, j’ai surtout travaillé avec des back-ends .NET, Java, Python et PHP Je ne voyais TypeScript/JavaScript côté back-end que dans des projets greenfield ou de petits projets où l’on pouvait contrôler le back-end Mais l’essor de React full stack pourrait changer cela Il est intéressant de voir que la perception des développeurs sur la période 2010-2020 varie selon le moment où ils ont commencé leur carrière Les développeurs qui ont débuté avant 2010 ont connu des environnements en server-side rendering (SSR) et semblent plus à l’aise avec le retour récent vers les technologies côté serveur À l’inverse, beaucoup d’autres ont travaillé presque une décennie uniquement avec des applications en client-side rendering (CSR) et des API REST Ils ne savent maintenant plus très bien comment accueillir ce nouveau monde full stack de React TypeScript s’impose comme standard de l’industrie Ces dernières années, TypeScript s’est imposé comme standard de l’industrie TypeScript offre aux développeurs front-end un langage de programmation typé et puissant Une fois que les développeurs ont adopté TypeScript, il devient difficile de revenir en arrière Il est fascinant de voir à quel point un petit changement dans le code peut avoir un impact énorme sur les individus comme sur l’industrie entière Les difficultés entre TypeScript et REST L’impact de TypeScript sur REST s’est traduit par de nombreuses solutions de fortune OpenAPI (anciennement Swagger) existait pour documenter les API REST, mais sert désormais principalement à générer des interfaces d’API typées Bien qu’il soit possible de créer des interfaces typées parfaites dans une architecture client-serveur, beaucoup de projets échouent à bien l’implémenter dès le départ Note personnelle : « Certains développeurs ont sans doute eu une bonne expérience avec une architecture basée sur OpenAPI, mais malheureusement, ce n’est pas mon cas. » TypeScript change l’ambiance Il est assez intéressant de voir comment TypeScript a changé l’ambiance ici D’un côté, les SPA non typées utilisant REST (avec OpenAPI à des fins de documentation) semblaient « acceptables » Mais à mesure que TypeScript est devenu un standard et une norme, les interfaces typées générées sont devenues désagréables à manipuler, car les bases de code front-end se sont habituées à un niveau d’exigence plus élevé Les inconvénients des interfaces typées générées sont clairs : elles impliquent toujours une étape de génération la sortie générée est complexe selon la configuration initiale, le code généré n’est pas toujours correct L’émergence de RPC et de tRPC RPC n’est pas un concept nouveau, mais il a gagné en popularité dans l’écosystème React grâce à tRPC D’après mon expérience de développeur solo pendant 6 mois sur une application de 80 000 lignes de code, appeler des fonctions sur le back-end pour lire et écrire des données a été une véritable révélation Je ne m’étais jamais senti aussi productif sur les deux côtés de la stack avec TypeScript Personnellement, je n’avais ressenti un niveau de productivité comparable que quelques années plus tôt avec une architecture GraphQL typée (générée) Durant toute l’année 2023, je n’arrivais pas à imaginer mieux que tRPC Appeler des fonctions sur le back-end pour lire et écrire des données donnait une impression révolutionnaire Mais est-ce que c’était vraiment tout ce dont j’avais besoin ? Non La révolution des Server Components et des Server Actions Pour moi, la vraie percée est arrivée en 2024 avec les Server Components et les Server Actions Ils ne se contentent pas d’appeler le serveur : ils comblent aussi l’écart avec lui en permettant d’implémenter et d’exécuter du code de l’autre côté Les Server Components permettent d’exécuter des composants React sur le serveur, avec un accès direct aux sources de données (par exemple une base de données) avant de renvoyer une UI en JSX Les Server Actions créent en coulisses des endpoints d’API HTTP, ce qui permet d’appeler et d’exécuter des fonctions comme avec un remote procedure call Les Server Components et les Server Actions transforment React en framework full stack C’est une période passionnante de transition du front-end vers un environnement full stack La prise en charge des Server Components et des Server Actions dans React React lui-même ne fournit que les briques de base et les spécifications pour les Server Components et les Server Actions Les méta-frameworks construits sur React peuvent combler cet écart grâce à des bundlers capables d’interpréter les directives entre client et serveur Next.js est en tête pour l’implémentation des Server Components et des Server Actions Next.js prenait déjà en charge le server-side rendering (SSR), mais avec les Server Components et les Server Actions, les développeurs peuvent désormais accéder à des ressources côté serveur comme des bases de données et des files de messages Le début du développement full stack Le développement full stack avec React n’en est encore qu’à ses débuts À mesure que les développeurs commencent à accéder directement aux bases de données via les Server Components et les Server Actions, il faudra apprivoiser une complexité qui dépasse les simples applications CRUD Grâce à une formation approfondie, les développeurs front-end maîtriseront bientôt l’implémentation d’architectures back-end à l’aide de couches, de design patterns et de bonnes pratiques Franchement, personne n’a envie de voir des appels de fonctions ORM dans des composants React L’attente d’un changement de paradigme Je suis très enthousiaste à propos de ce changement de paradigme Une nouvelle ère se prépare, dans laquelle les développeurs React implémenteront des fonctionnalités verticales allant de l’UI jusqu’à la base de données

(robinwieruch.de)

15 points par xguru 2024-08-26 | 8 commentaires | Partager sur WhatsApp

Avec l’ajout des Server Components et des Server Actions, React évolue vers un framework full stack

Le début des guerres de frameworks en 2010

Les guerres de frameworks, lancées en 2010 avec Backbone, Knockout et Ember, ont été rapidement suivies par Angular et React, sans que personne ne puisse vraiment en prévoir l’issue
Pendant longtemps, les applications JavaScript en client-side rendering (CSR) ont dominé
Ces applications, aussi appelées single-page applications (SPA), se composaient généralement d’un petit fichier HTML et d’un gros fichier JavaScript
C’était le cas avant l’introduction du code splitting

La séparation entre front-end et back-end

Durant cette période, le développement front-end a été dominé par divers frameworks et bibliothèques JavaScript
Le back-end n’était généralement pas lié à un langage en particulier, et REST est devenu le standard pour la communication via API
En tant que développeur web freelance, j’ai surtout travaillé avec des back-ends .NET, Java, Python et PHP
Je ne voyais TypeScript/JavaScript côté back-end que dans des projets greenfield ou de petits projets où l’on pouvait contrôler le back-end
Mais l’essor de React full stack pourrait changer cela
Il est intéressant de voir que la perception des développeurs sur la période 2010-2020 varie selon le moment où ils ont commencé leur carrière
Les développeurs qui ont débuté avant 2010 ont connu des environnements en server-side rendering (SSR) et semblent plus à l’aise avec le retour récent vers les technologies côté serveur
À l’inverse, beaucoup d’autres ont travaillé presque une décennie uniquement avec des applications en client-side rendering (CSR) et des API REST
Ils ne savent maintenant plus très bien comment accueillir ce nouveau monde full stack de React

TypeScript s’impose comme standard de l’industrie

Ces dernières années, TypeScript s’est imposé comme standard de l’industrie
TypeScript offre aux développeurs front-end un langage de programmation typé et puissant
Une fois que les développeurs ont adopté TypeScript, il devient difficile de revenir en arrière
Il est fascinant de voir à quel point un petit changement dans le code peut avoir un impact énorme sur les individus comme sur l’industrie entière

Les difficultés entre TypeScript et REST

L’impact de TypeScript sur REST s’est traduit par de nombreuses solutions de fortune
OpenAPI (anciennement Swagger) existait pour documenter les API REST, mais sert désormais principalement à générer des interfaces d’API typées
Bien qu’il soit possible de créer des interfaces typées parfaites dans une architecture client-serveur, beaucoup de projets échouent à bien l’implémenter dès le départ
Note personnelle : « Certains développeurs ont sans doute eu une bonne expérience avec une architecture basée sur OpenAPI, mais malheureusement, ce n’est pas mon cas. »

TypeScript change l’ambiance

Il est assez intéressant de voir comment TypeScript a changé l’ambiance ici
D’un côté, les SPA non typées utilisant REST (avec OpenAPI à des fins de documentation) semblaient « acceptables »
Mais à mesure que TypeScript est devenu un standard et une norme, les interfaces typées générées sont devenues désagréables à manipuler, car les bases de code front-end se sont habituées à un niveau d’exigence plus élevé
Les inconvénients des interfaces typées générées sont clairs :
- elles impliquent toujours une étape de génération
- la sortie générée est complexe
- selon la configuration initiale, le code généré n’est pas toujours correct

L’émergence de RPC et de tRPC

RPC n’est pas un concept nouveau, mais il a gagné en popularité dans l’écosystème React grâce à tRPC
D’après mon expérience de développeur solo pendant 6 mois sur une application de 80 000 lignes de code, appeler des fonctions sur le back-end pour lire et écrire des données a été une véritable révélation
Je ne m’étais jamais senti aussi productif sur les deux côtés de la stack avec TypeScript
Personnellement, je n’avais ressenti un niveau de productivité comparable que quelques années plus tôt avec une architecture GraphQL typée (générée)
Durant toute l’année 2023, je n’arrivais pas à imaginer mieux que tRPC
Appeler des fonctions sur le back-end pour lire et écrire des données donnait une impression révolutionnaire
Mais est-ce que c’était vraiment tout ce dont j’avais besoin ? Non

La révolution des Server Components et des Server Actions

Pour moi, la vraie percée est arrivée en 2024 avec les Server Components et les Server Actions
Ils ne se contentent pas d’appeler le serveur : ils comblent aussi l’écart avec lui en permettant d’implémenter et d’exécuter du code de l’autre côté
Les Server Components permettent d’exécuter des composants React sur le serveur, avec un accès direct aux sources de données (par exemple une base de données) avant de renvoyer une UI en JSX
Les Server Actions créent en coulisses des endpoints d’API HTTP, ce qui permet d’appeler et d’exécuter des fonctions comme avec un remote procedure call
Les Server Components et les Server Actions transforment React en framework full stack
C’est une période passionnante de transition du front-end vers un environnement full stack

La prise en charge des Server Components et des Server Actions dans React

React lui-même ne fournit que les briques de base et les spécifications pour les Server Components et les Server Actions
Les méta-frameworks construits sur React peuvent combler cet écart grâce à des bundlers capables d’interpréter les directives entre client et serveur
Next.js est en tête pour l’implémentation des Server Components et des Server Actions
Next.js prenait déjà en charge le server-side rendering (SSR), mais avec les Server Components et les Server Actions, les développeurs peuvent désormais accéder à des ressources côté serveur comme des bases de données et des files de messages

Le début du développement full stack

Le développement full stack avec React n’en est encore qu’à ses débuts
À mesure que les développeurs commencent à accéder directement aux bases de données via les Server Components et les Server Actions, il faudra apprivoiser une complexité qui dépasse les simples applications CRUD
Grâce à une formation approfondie, les développeurs front-end maîtriseront bientôt l’implémentation d’architectures back-end à l’aide de couches, de design patterns et de bonnes pratiques
Franchement, personne n’a envie de voir des appels de fonctions ORM dans des composants React

L’attente d’un changement de paradigme

Je suis très enthousiaste à propos de ce changement de paradigme
Une nouvelle ère se prépare, dans laquelle les développeurs React implémenteront des fonctionnalités verticales allant de l’UI jusqu’à la base de données

8 commentaires

t7vonn 2024-09-02

Ils ont déjà tout fait en full stack.

wan2land 2024-08-26

Si l’on prend en compte la compatibilité avec d’autres langages, comme dans le développement d’apps, je pense que tRPC n’est pas un très bon choix. 😅
Pour moi, GraphQL est la meilleure option.

click 2024-08-26

Je pense que les server actions de Next.js ont le problème d’exposer publiquement des endpoints d’API aléatoires que les développeurs ne peuvent pas contrôler, et je considère que c’est un point extrêmement vulnérable.

2024-08-27

[Ce commentaire a été masqué.]

pasg0725 2024-08-26

Pourriez-vous me dire de quelle vulnérabilité vous parliez exactement ? Quand je cherche, je vois qu’il s’agit d’une vulnérabilité SSRF, mais je ne suis pas sûr que ce soit bien ça. Je suis justement en train d’étudier Next.js, donc je vous pose la question par curiosité.

savvykang 2024-08-26

Quelle était au départ l’intention de ceux qui poussaient le SPA ? C’est bien mieux que l’époque où on manipulait le DOM avec jquery, mais on a l’impression que les concepts nécessaires à la conception et au développement du backend et du frontend ne disparaissent pas, ils ne font que changer d’endroit. Rien que pour le routing, on l’a déplacé du serveur vers le client, puis on essaie de le ramener côté serveur à cause de la mode du server-side rendering.

Je me demande même si, dans trois ans, les écoles de code ou les cours enseigneront encore React dans un style SPA

superwoou 2024-08-28

La fluidité des transitions entre les pages n’était-elle pas son plus grand avantage ? (à l’époque)

xguru 2024-08-26

La fin de l’article original se conclut par la promotion du futur programme de formation de l’auteur au développement web full stack, The Road to Next ^^;