SDK Node.js officiel d'Upsun
Le client TypeScript de l'API Upsun, complété et aligné sur le SDK PHP.
- Rôle
- Développement, au sein de l'équipe Advocacy : couverture complète de l'API, alignement avec le SDK PHP, outil de vérification des signatures
- Période
- déc. 2025 – en cours · Upsun
- Stack
- TypeScript
- Node.js
- OpenAPI Generator
- npm
- GitHub Actions
Contexte
Le SDK Node.js existait déjà sous une forme minimale : il couvrait juste ce dont le serveur MCP d'Upsun avait besoin pour fonctionner. Les développeurs JavaScript et les outils d'automatisation (scripts CI, intégrations, n8n…) attendaient un accès complet à l'API, avec le typage de TypeScript et le même confort que le SDK PHP.
Ce que j'ai fait
- Le même principe que le SDK PHP : une couche générée avec OpenAPI Generator, à partir de la même spécification OpenAPI, servie par Meta-Upsun, et une couche écrite à la main pour les développeurs.
- La couverture complète de l'API : toutes les ressources publiques (organisations, projets, environnements, variables, déploiements…), au-delà du sous-ensemble utile au MCP.
- L'alignement des deux SDK : mêmes ressources, mêmes noms de méthodes, mêmes paramètres dans le même ordre. Passer de PHP à TypeScript, ou porter un script d'un langage à l'autre, ne demande pas de réapprendre l'API.
- Un outil de vérification des signatures qui compare les méthodes publiques des SDK PHP et Node.js et signale chaque divergence : méthode manquante d'un côté, paramètre en plus, ordre ou nom différent. L'alignement ne repose plus sur la vigilance des relecteurs.
- Un typage complet : TypeScript sans configuration supplémentaire, JSDoc sur chaque classe, propriété et méthode pour l'autocomplétion.
- Des options claires sur les opérations sensibles : par exemple, une variable d'environnement se crée en précisant si elle est sensible et si elle est visible au build ou à l'exécution.
- Publication sur npm :
npm install upsun-sdk-node. Code source sur GitHub. - Une documentation de l'architecture et du code, interrogeable, sur DeepWiki.
Pourquoi c'est intéressant
Maintenir deux SDK à la main, c'est la garantie qu'ils divergent : une méthode ajoutée d'un côté, un paramètre renommé de l'autre. L'outil de vérification transforme cette cohérence en contrôle automatique, et c'est lui qui rend crédible l'ajout de nouveaux langages.
Résultats
- SDK officiel publié sur npm, open source, couvrant toute l'API publique.
- Deux SDK cohérents, et des divergences détectées dès qu'elles apparaissent.
- Une base commune pour les futurs SDK Python et Go.
