Une race différente de méta cadre –

Le paysage actuel des outils Web est de plus en plus complexe que jamais. Nous avons des bibliothèques telles que Solid, Vue, Svelte, Angular, React et d’autres qui gèrent les mises à jour de l’interface utilisateur (User Interface) de manière ergonomique. Le sujet de plus en plus important qui pèse sur les développeurs est l’équilibre et le compromis entre les meilleures pratiques en matière de performances et d’utilisabilité.

Les développeurs brouillent également les frontières entre le code front-end et back-end. La façon dont nous colocalisons la logique et les données devient de plus en plus intéressante à mesure que nous intégrons et maillons la façon dont elles fonctionnent ensemble pour offrir une expérience d’application unifiée.

Compte tenu de ces changements idéologiques, les méta-cadres ont évolué de manière unique autour des bibliothèques principales. Pour encapsuler les paradigmes dans lesquels l’interface utilisateur est rendue et créer une interopérabilité transparente entre notre code serveur et notre code navigateur, de nouvelles pratiques émergent.

Alors que l’idée initiale d’avoir un cadre « méta » était de rassembler différents ensembles d’outils afin de créer des expériences fluides, il est difficile de créer des intégrations sans prendre un certain niveau de décisions avisées. Ainsi, des frameworks tels que QwikCity, SvelteKit, Redwood et Next.js sont allés jusqu’au bout de leur propre territoire d’opinion et ont fourni un chemin de fer solide pour garantir un ensemble défini de conventions.

Pendant ce temps, d’autres comme Nuxt, Remix et Analog sont restés avec une abstraction plus superficielle de leurs intégrations, permettant un mélange de leurs outils et utilisant plus facilement les ressources de la communauté (Vite est un bon exemple d’outil utilisé de manière superficielle par tous). eux).

Cela réduit non seulement la dépendance vis-à-vis du fournisseur pour les développeurs, mais permet également de réutiliser la configuration dans certains cas, car ces décisions sont supprimées des opinions en faveur d’abstractions plus fortes. SolidStart fait un pas de géant au-delà cela en territoire impartial. Son propre noyau comprend environ 1 500 lignes de code, et les plus grandes fonctionnalités sont fournies avec un maillage d’outils bien intégrés.

Modules sur monolithes

L’objectif du découplage complet de l’architecture est de donner au développeur consommateur le pouvoir de choisir le framework et de le construire selon ses souhaits. Un développeur souhaitera peut-être utiliser Solid et SSR, mais imaginons que le code existant dépend fortement du routeur TanStack, tandis que SolidStart et la plupart des projets Solid ont plutôt Solid-Router. Avec une architecture découplée, il devient possible de créer une couche d’adoption ou d’intégration incrémentielle afin que tout fonctionne de manière adaptée au meilleur bénéfice de l’équipe.

L’architecture découplée supportant les nouveaux frameworks permet également au développeur de bénéficier d’un meilleure expérience de débogage au sein et au-delà de sa communauté. Si un problème survient sur le serveur, vous n’êtes pas limité à la connaissance d’un framework spécifique.

Par exemple, puisque les deux sont basées sur Nitro, les communautés Analog et SolidStart peuvent désormais partager leurs connaissances entre elles. Au-delà de cela, comme ils sont tous basés sur Nitro et Vite, Nuxt, Analog et SolidStart peuvent se déployer sur les mêmes plates-formes et partager les détails de mise en œuvre pour faire croître ensemble chaque écosystème. La communauté gagne avec cette approche, et les développeurs de bibliothèques/framework gagnent également. C’est radicalement nouveau modèle et approche au partage conjoint du poids de la maintenance du méta-framework (l’une des responsabilités les plus redoutées des responsables).

Qu’est-ce que SolidStart exactement ?

SolidStart repose sur cinq piliers fondamentaux :

1. Solide: la bibliothèque de vues qui fournit des abstractions de rendu.
2. Vite (au sein de Vinxi) : le bundler pour optimiser le code pour l’exécution dans différents environnements d’exécution.
3. Nitro (au sein de Vinxi) : le serveur web agnostique créé par l’équipe Nuxt et basé sur h3 avec Rollup.
4. Vinxi: l’orchestrateur, ce qui détermine où se trouvent les runtimes et le code de chacun.
5. Séroval: le sérialiseur de données qui reliera les données du serveur au navigateur et inversement.

1. Solide

Solid en tant que bibliothèque de rendu est devenu de plus en plus populaire en raison de ses incroyables performances de rendu et de sa fine couche d’abstraction. Il est construit sur Signals, une implémentation renouvelée et moderne du classique Observer Pattern, et fournit une série d’aides pour permettre au développeur de créer des environnements extrêmement code performant et facile à lire.

Il utilise JSX et a une syntaxe très similaire à celle de React, mais sous le capot, il fonctionne d’une manière complètement différente. Rapprocher le développeur du DOM tout en offrant l’ergonomie nécessaire pour être productif dans l’environnement du développeur. Avec seulement 3 Ko de taille de paquet, c’est souvent un choix, même pour les sites pour la plupart statiques. Par exemple, de nombreuses personnes utilisent Solid pour apporter de l’interactivité à leurs sites Web Astro basés sur le contenu lorsque cela est nécessaire.

Solid apporte également des primitives de première classe, des composants Control Flow intégrés, une gestion des états de haute qualité et une prise en charge complète de TypeScript. Solid a du punch dans un petit package efficace.

2. Vite

Sans doute le meilleur bundler de l’écosystème JavaScript, Vite offre le bon équilibre entre configuration déclarative et personnalisable. Il est entièrement basé sur TypeScript, ce qui facilite son extension par la bibliothèque ou le framework consommateur, et dispose d’une base d’utilisateurs suffisamment large pour garantir sa polyvalence. Vite travaille avec et est devenu le outil de facto pour de nombreux frameworkstels que Astro, Vue, Preact, Elm, Lit, Svelte, Nuxt, Analog, Remix et bien d’autres.

Outre sa popularité, il est particulièrement apprécié pour son temps de démarrage rapide du serveur, sa prise en charge HMR, ses versions optimisées, sa facilité de configuration, son riche écosystème de plug-ins, ses outils modernes et son expérience globale de développement de haute qualité.

3. Nitro

Framework en soi, Nitro est écrit en TypeScript et est complètement agnostique et ouvert à tous. méta-framework à utiliser comme base. Il fournit un ensemble puissant d’outils et d’API pour gérer la mise en cache, les itinéraires et l’arborescence. Il s’agit d’une base rapide sur laquelle tout projet basé sur JavaScript peut créer son serveur. Nitro est hautement évolutif, s’intègre facilement aux pipelines DevOps et CI/CD, est axé sur la sécurité, robuste et dispose d’un riche ensemble d’adaptateurs, ce qui le rend déployable sur la plupart, sinon la totalité, des plates-formes des principaux fournisseurs.

Considérez Nitro comme une extension boulonnée qui rend Vite plus facile à construire et plus flexible. Il résout la majorité des problèmes de niveau d’exécution qui devraient être résolus dans Vite.

4. Vinxi

Vinxi est un SDK (Software Development Kit) qui apporte un ensemble puissant d’outils basés sur la configuration pour créer des applications full-stack. Il compose Nitro sous le capot pour établir un serveur Web et exploite Vite pour le regroupement des composants. Il s’inspire de l’API Bun App et fonctionne via une interface très déclarative pour instancier une application en définissant des routeurs pour chaque runtime.

Par exemple:

import { createApp } from "vinxi";
import solid from "vite-plugin-solid";

const resources = {
    name: "public",
    mode: "static",
    dir: "./public",
};

const spa = {
    name: "client",
    mode: "build",
    handler: "./app/client.tsx",
    target: "browser",
    plugins: () => [solid({ ssr: true })],
    base: "/_build"
}

const server = {
    name: "ssr",
    mode: "handler",
    handler: "./app/server.tsx",
    target: "server",
    plugins: () => [solid({ ssr: true })],
}

export default createApp({
    routers: [resources, spa, server],
});

Comme les routes de ressources fonctionnent comme un bucket, en définissant mode: "static" il n’est pas nécessaire de définir un gestionnaire. Votre routeur peut également être construit de manière statique (mode: “build”) et ciblé sur le runtime du navigateur, ou il peut être sur le serveur et traiter chaque requête via son point d’entrée handler: "./app/server.tsx".

Vinxi exploitera le bon ensemble d’API de Nitro et Vite afin que vos ressources ne soient pas exposées aux mauvais environnements d’exécution et pour que le déploiement fonctionne correctement pour les fournisseurs de plates-formes définis.

5. Séroval

Une fois que les routeurs sont configurés et que l’application peut gérer la navigation (navigation dure via le gestionnaire « ssr » et navigation douce via le gestionnaire « client »), il est temps de les assembler. C’est la partie où le noyau de SolidStart entre en place. Il fournit des API qui apportent l’ergonomie à récupérer et muter les requêtes.

Toutes ces API sont alimentées par une autre bibliothèque agnostique appelée Seroval. Afin d’envoyer des données entre le serveur et le client de manière sécurisée, tout doit être sérialisé. Seroval se définit de manière trop simpliste : « Stringify JS Values ». Cependant, cette définition ne tient pas compte du fait qu’il le fait de manière extrêmement puissante et rapide.

Grâce à Seroval, SolidStart est capable de traverser de manière sûre et efficace le limite de sérialisation. La sérialisation des ressources est sans doute la fonctionnalité la plus importante d’un framework full-stack : sans elle, le pont back-end et front-end ne fonctionnera tout simplement pas de manière fluide.

Outre la sérialisation des ressources, SolidStart peut également utiliser actions du serveur. Directement du Documentationc’est ainsi que les actions du serveur nous recherchent (notez le "use server" directive qui permet à Vinxi de mettre le code au bon endroit.

import { action, redirect } from "@solidjs/router";
 
const isAdmin = action(async (formData: FormData) => {
  "use server";
  await new Promise((resolve, reject) => setTimeout(resolve, 1000));
  const username = formData.get("username");
  if (username === "admin") throw redirect("/admin");
  return new Error("Invalid username");
});
 
export function MyComponent() {
  return (
    <form action={isAdmin} method="post">
      <label for="username">Username:</label>
      <input type="text" name="username" />
      <input type="submit" value="submit" />
    </form>
  );
}

Tout s’assemble

Après cette panne, les choses sont peut-être encore un peu en suspens. Alors, bouclons la boucle en assemblant les pièces :

Espérons que ce petit exercice consistant à démonter le cadre et à reconstituer les pièces a été intéressant et perspicace. Faites-le-moi savoir dans les commentaires ci-dessous ou sur X si cela vous a aidé à mieux comprendre voire choisir les outils pour votre prochain projet.

Considérations finales

Cet article n’aurait pas été possible sans l’aide technique de mes formidables collaborateurs de l’équipe Solid : Dave Di Biase, Alexis Munsayac, Alex Lohr, Daniel Afonsoet Nikhil Saraf. Merci pour vos critiques, vos idées et, dans l’ensemble, cela me fait paraître plus intelligent !

(je)