Un générateur, toutes les sorties
Cloudflare vient de sortir Forge en open source, sous licence Apache 2.0.
Le principe : vous lui donnez votre spec OpenAPI, il génère tout ce qui permet de consommer votre API. SDK, CLI, doc, serveur MCP, schémas de validation.
Il ne touche pas à votre implémentation. Il se cale sur le contrat d'interface et produit le code d'en face, celui de vos utilisateurs.
Et ce n'est pas un jouet : Cloudflare l'utilise déjà pour son CLI cf, sur une API de plus de 3 500 opérations.
Ce qui m'intéresse vraiment : le chaînage
Chaque sortie peut servir d'entrée à la suivante :
- la spec génère le SDK TypeScript
- le SDK génère le CLI
- le CLI alimente la doc
Résultat : là où vous aviez trois outils et trois étapes à synchroniser, vous n'en avez plus qu'un. Et c'est vous qui décidez de l'ordre de la chaîne, pas l'outil.
Mais le vrai gain, c'est le moment où ça tourne. Forge s'exécute dans votre CI, sur chaque PR qui touche l'API, et vous donne une preview installable du SDK, du CLI et de la doc. Vous voyez la casse avant de merger, pas le jour de la release.
SDK ou simple API REST ?
Je vais être honnête : sur une petite API CRUD, un SDK n'apporte pas grand-chose. Un fetch typé fait le job.
Mais dès que l'API grossit, le SDK absorbe tout ce que chaque client recoderait mal dans son coin :
- la pagination
- les retries et le rate limiting
- l'auth et le refresh de token
- les erreurs typées
Et côté fournisseur, vous contrôlez enfin le comportement de vos clients au lieu de subir ce que chacun a bricolé.
Deux limites quand même. Forge ne lit que de l'OpenAPI pour l'instant, donc si votre spec est bancale, tout ce qui en sort le sera aussi. Et le projet est jeune.
La vraie question, c'est celle que pose Cloudflare en creux : à l'ère des agents, un SDK, un CLI et un serveur MCP ne sont plus des bonus. Combien de produits sont prêts pour ça ?
Merci Kevin pour la news.
