Perspectives de développement JavaScript Full-Stack pour 2023 | de Yiming Cao | décembre 2022

C’est pourquoi Prisma, même en développant activement et en défendant son approche orientée vers la pointe Proxy de données, a honnêtement affirmé que:

Comme bonne pratique, nous recommandons toujours de déployer généralement votre base de données aussi près que possible de votre serveur d’API afin de minimiser la latence dans les temps de réponse.

C’est certainement quelque chose que vous devriez peser avant de passer au bord. L’atténuation, comme Prisma l’a laissé entendre, consiste à confiner votre réseau périphérique à des régions suffisamment proches de votre base de données. Certains frameworks, par exemple Next.js, prennent déjà en charge la configuration de la région périphérique au niveau de la route. Eh bien, si vous utilisez déjà un magasin de données distribué à l’échelle mondiale, je n’ai rien d’autre à vous avertir que de vous envoyer mes félicitations.

Alors que les développeurs triaient encore CSR, SSR, SSG, ISR, etc., Next.js 13 a atterri avec style en faisant de React Server Components sa nouvelle valeur par défaut (toujours en version bêta, cependant).

Cela a généré beaucoup d’enthousiasme pour une performance encore meilleure des futures applications Web, mais a sans aucun doute rendu les choses encore plus confuses. Néanmoins, l’idée est plutôt cool : les composants du serveur s’affichent sur le serveur et leur code y reste.

Cela peut potentiellement réduire considérablement la taille du groupe de clients, mais rend en même temps la limite du réseau plus floue qu’auparavant. Par conséquent, le comportement de votre application peut être plus difficile à raisonner.

Consultez mon autre article pour une explication plus approfondie du RSC de Next.js 13 :

Il y a eu des débats sans fin sur la meilleure façon de charger les données dans les applications Web complètes, et cela continuera de s’échauffer car il n’y a pas de meilleure solution unique qui s’adapte à tous les scénarios :

• Avez-vous une récupération de données lente ou non ?
  Le streaming RSC + fournit une excellente solution pour rendre et diffuser l’interface utilisateur de manière asynchrone avec une granularité fine.
• Devriez-vous vous soucier davantage de la taille du bundle ou du trafic réseau une fois la page interactive ?
  RSC réduit la taille du bundle au prix d’un trafic réseau accru lorsque les composants sont restitués, car il diffuse l’interface utilisateur (DOM virtuel) au lieu des données. Alors que le chargement de données basé sur un routeur traditionnel, comme ce que fait Remix, ne souffre pas d’un tel problème.
• Préférez-vous une séparation stricte des données et des composants, ou préférez-vous les colocaliser ?
  C’est plus une question de goût. Le dernier conseil que nous avons reçu de la plupart des frameworks est « récupérer » puis « rendre » (pour éviter les cascades de récupération de rendu), mais Next.js 13 (avec RSC et intégré récupérer la déduplication) offre une opportunité intéressante de faire « récupérer au fur et à mesure du rendu » de manière performante.

En même temps, n’oubliez pas que les écosystèmes non réactifs, comme Vue et Svelte, n’ont pas du tout la notion de composants serveur, et leurs développeurs s’en sortent très bien. Un autre incident intéressant est Remix rejoint Shopify. Le framework frontal de Shopify Hydroden initialement misé sur RSC. Acquérir Remix signifie effectivement qu’il change de direction, du moins pour le moment. Voici un commentaire intéressant du créateur de Vue 😄 :

Alors comment survivre dans ce monde chaotique ? Je suggère d’évaluer le cadre auquel vous vous en tenez en fonction d’autres aspects. Habituellement, un framework moderne ne vous laissera pas tomber sur son mécanisme de chargement de données. Ils ont des préférences et des accents différents, mais ont généralement des solutions suffisamment bonnes pour la plupart des scénarios. j’aime L’idée de Remix d’utiliser les « leviers » comme métaphore.

Les frameworks offriront tous les leviers, mais il est de votre responsabilité de tirer.

Bien sûr, je ne dis pas que les API vont disparaître. Ils sont la bouée de sauvetage du Web et deviendront encore plus vitaux. Cependant, dans le cadre du développement full-stack avec des frameworks Javascript, explicitement concevoir et implémenter des API est de moins en moins nécessaire. Ils se fondent dans les cadres.

Par exemple, techniquement parlant, getServerSideProps et getStaticProps de Next.js sont des API, bien que vous ne les appeliez jamais explicitement à partir de votre code côté client. Il en est de même pour loader et action dans Remix, ainsi que le load fonction dans SvelteKit. La communication réseau, à la fois son timing et son format, est si bien encapsulée que vous êtes à peine conscient qu’il s’agit d’API. Votre code client et serveur partagent également naturellement des définitions de type (si vous utilisez Typescript, oui, vous devriez). Ceux-ci résoudront probablement toutes vos exigences pour SSR, SSG et une partie des interactions côté client.

La plupart des frameworks vous permettent également de créer des points de terminaison d’API « explicites » pour prendre en charge des interactions côté client plus flexibles. Votre instinct initial sera probablement, dois-je alors créer un service RESTful ou GraphQL avec ? Mais réfléchissons-y à deux fois : votre code est déjà dans un dépôt unique, avec le code côté client et côté serveur étroitement liés, écrits dans le même langage. Alors pourquoi diable vous donnez-vous la peine d’introduire une chaîne d’outils et de construire une spécification de communication aussi solennelle entre eux ?

tRPC a donné un moyen fantastique de résoudre le problème avec moins de rigueur. Il tire pleinement parti de votre configuration : monorepo, cadre unifié, langage commun (TS) et transforme efficacement la construction d’API en méthodes d’écriture et en les appelant. C’est une autre approche pour laisser les API disparaître d’une manière indépendante du framework.

Il y a des sacrifices apparents : vos API sont désormais étroitement liées à votre application (et même à un cadre spécifique) et ne sont pas facilement consommables par un tiers. Mais en réalité, ce n’est souvent pas trop préoccupant.

Avec la puissance accrue des fonctionnalités de chargement de données des frameworks et les poussées d’idées folles comme le tRPC, en 2023, nous devrions voir plus de gens se sentir à l’aise avec le fait d’être « moins sérieux » à propos de la création d’API et, à la place, se concentrer davantage sur la création de leurs produits.

Les progrès des outils et des frameworks ne nous donnent pas seulement plus de pouvoir pour résoudre les problèmes. Ils en font également une expérience plus vive lors de notre travail. Un domaine particulier qui mérite votre attention est celui des IDE basés sur un navigateur.

Les gens utilisent des outils comme jsviolon pour des expériences rapides pendant des années, mais il a été limité à jouer avec des trucs côté client. Cependant, les IDE Web à part entière mûrissaient rapidement en 2022. Par exemple, Codesandbox fournit désormais une bonne prise en charge des frameworks à pile complète comme Next et Nuxt en faisant tourner des conteneurs distants pour exécuter la charge de travail côté serveur et émuler une expérience «locale» pour vous. GitpodGenericName adopte une technologie similaire mais semble plus ambitieuse pour aller plus loin dans les cycles de développement.
Le plus excitant de tous est StackBlitz. Il a pris la décision courageuse de mettre en œuvre une implémentation complète de NodeJS avec Web Assembly (appelée WebContainer). Avec cela, votre code backend peut s’exécuter directement dans votre navigateur. Pas besoin de faire tourner des conteneurs distants et pas besoin de transmettre des données dans les deux sens sur le réseau. C’est un environnement vraiment local. Cette approche semble être le seul moyen pratique de résoudre le problème et de transformer les IDE Web en usage courant.

C’est encore un domaine immature mais qui semble évoluer rapidement. Je crois donc qu’en 2023, il y a des chances d’adoptions sérieuses, au moins pour des tâches comme la révision de code ou la correction de bogues ad hoc.