API et Eden Treaty
Le lien typé de bout en bout entre le serveur Elysia et les clients web et native.
Le projet a été généré avec --api none. Concrètement, Better-T-Stack n'a câblé que l'authentification, qui a son propre transport. Pour tout le métier (posts, feed, social), il n'y a pas encore de couche API.
C'est le premier chantier du backend. Tant que la couche API n'est pas branchée, aucune feature métier ne peut s'écrire proprement. Eden Treaty est la brique qui débloque tout le reste.
Pourquoi Eden plutôt qu'une couche RPC générée
Eden Treaty donne un typage de bout en bout, comme tRPC, mais reste du HTTP standard. Le client hérite directement des types du serveur Elysia, sans duplication et sans génération de code. Un futur client mobile ou un outil tiers peut aussi consommer l'API en HTTP classique.
Le principe
Le serveur exporte le type de son application. Le client l'importe et obtient un objet entièrement typé, où les routes, les entrées et les sorties sont connues à la compilation.
// apps/server/src/index.ts
const app = new Elysia().use(posts).use(feed);
export type App = typeof app;// côté client
import { treaty } from "@elysiajs/eden";
import type { App } from "@vantablvck/server";
const api = treaty<App>("http://localhost:3000");
// entièrement typé, sans schéma dupliqué
const { data } = await api.posts.post({ body: "hello" });Ce qui reste à câbler
- Exporter le type
Appdepuisapps/server. - Installer et configurer le client Eden côté web et, plus tard, côté native.
- Faire passer les macros de sécurité et les schémas Zod dans le contrat, pour que le typage couvre aussi les entrées validées.
Une fois ce lien en place, chaque nouveau module ajoute ses routes au serveur, et les clients en héritent immédiatement, sans étape de synchronisation manuelle.