API en TypeScript Comment construire une application API prête à la production

Votre application TypeScript API semblait probablement solide le jour de sa mise en production. Les routes se compilaient, le frontend importait des types partagés, et l'éditeur donnait à tout le monde ce sentiment propre et vert qui signifie généralement « prêt à envoyer ».

Ensuite, le backend a changé un champ de réponse, une valeur nullable est apparue où personne ne s'y attendait, ou un client mobile continuait à appeler une forme de charge utile plus ancienne. C'est là que la plupart des API en TypeScript travaux se cassent. Pas en syntaxe. En dérive.

Contenu de la page

• Why Typed APIs Fail After Launch and How to Prevent It
• Créer un projet TypeScript API de manière optimale
  • Pick the framework that matches team shape
  • Utilisez un plan de dossier qui protège les limites
  • Utilisez une organisation de dossiers qui protège les limites
• Étanchez le compilateur avant d'ajouter des fonctionnalités
  • Les contrats publics et les modèles internes ne devraient pas être les mêmes
  • Valider avant que la logique commerciale touche les données
  • Mapping code n'est pas gaspiller. C'est là où le dérive devient visible
  • Les types partagés ne sont utiles que lorsque la source de vérité est explicite
  • Une limite maintenable ressemble à du plomb fondu par intention
• Générez et consommez un client API entièrement typé
  • Choisissez votre stratégie de client typé
  • Les clients personnalisés fonctionnent pour de petites surfaces
  • La génération OpenAPI est le choix pratique par défaut
  • Enveloppez les clients générés avant que l'application code les touche
  • Les clients de style SDK ont du sens lorsque l’API est un produit
• La gestion des erreurs, les tests et l'observabilité qui aident vraiment
  • Réduire les erreurs avant de les toucher
  • Réessayer uniquement lorsque l'erreur est transitoire
  • L'observabilité doit expliquer les échecs, et non simplement les enregistrer
  • Tester le contrat, et non seulement l'implémentation
• Livraison en Production avec Confiance et Contrôle
  • Le boucle de mise à jour qui bloque
  • Le contrôle compte autant que la correction

Pourquoi les API de type échouent après le lancement et comment les prévenir

Un API de type habituel se brise généralement lors d'une mise à jour ordinaire. Une équipe renomme un champ de réponse. Une autre ajoute une branché nullable pour une migration partielle. Un client plus ancien continue à envoyer le payload précédent car les mises à jour mobiles sont en retard par rapport à celles du web. TypeScript compile toujours dans chaque répertoire qui a mis à jour ses types locaux. Le contrat en production est déjà faux.

Cette échec a un nom : dérive de contrat.

TypeScript a rendu API plus agréable, mais il a également rendu les contrats faibles plus faciles à sur-trouver. Les interfaces partagées, les génériques de route et un API fetch wrapper aide pendant le développement. Ils ne prouvent pas que le JSON traversant le réseau correspond toujours à ces types après la deuxième ou la dixième mise à jour.

La règle qui tient en production est simple.

Si un JSON non validé peut passer directement dans la logique de l'application, les types TypeScript décrivent l'intention, pas la réalité.

La correction est moins liée à des acrobaties de type ingénieuses et plus à l'endroit où la vérité réside.

• Valider à la frontière. Analysez les corps de requête, les paramètres, les en-têtes et même les réponses des services downstream avant que le reste de code ne les touche.
• Mappez les DTO à des modèles de domaine. Gardez les formes de transport distinctes des objets métier afin que les modifications API ne se propagent pas dans tout le codebase.
• Générez des types à partir d'un contrat. OpenAPI, JSON Schema ou un framework de type schéma donne un point de référence partagé aux clients et serveurs.
• Treat breaking changes as public events. Si un champ change de forme, versionnez-le délibérément et communiquez-le comme n'importe quel autre changement de contrat externe.

La mise en correspondance des DTO est la pièce que les équipes sautent le plus souvent. Cela ressemble à une répétition à première vue. Après quelques sorties, il devient la couche qui vous sauve de la diffusion string | null et les anciens alias de champs à travers chaque service et écran frontal. Un petit pas de traduction à la frontière est moins coûteux qu'un large refactor ultérieur.

Les API typées échouent également car les contrats d'erreur sont généralement une pensée après-coup. Les payloads de succès reçoivent l'attention. Les payloads d'erreur se transforment en ce que les exceptions lancées se sont trouvées pour s'assimiler cette journée. Les clients construisent ensuite une logique de relecture, des messages d'utilisateur et des tâches de monitoring sur des formes qui n'ont jamais été conçues. Le résultat est le même problème sous une forme différente. Drift.

Versioning deserves the same discipline. Teams rarely break clients with one dramatic rewrite. They break them with a series of reasonable local changes that add up to incompatibility. A clear Stratégie de versionnage API pour les contrats évoluants rend les modifications visibles avant qu'elles ne touchent les consommateurs.

The goal is not to have TypeScript everywhere. The goal is to keep the contract truthful after launch, when multiple deploys, multiple clients, and real production data start pushing against the neat types you had on day one.

Créer un Projet TypeScript API de A à Z

Un API typé est généralement propre le jour même. Six mois plus tard, une route accepte des entrées non contrôlées, une autre lit des données brutes. process.envet une troisième renvoie une forme qui n'a jamais été codée par un client. Le squelette ne se brise rarement tout à la fois. Il crée suffisamment de place pour que le dérive du contrat s'infiltre dans le travail normal des fonctionnalités.

Démarrez avec une forme de projet qui rend le contrat difficile à contourner.

Pick the framework that matches team shape

Pour un API en TypeScript, la première décision de framework est moins liée à la syntaxe et plus liée à où le contrat discipliné vivra.

• Express convient aux équipes qui veulent une abstraction minimale et qui connaissent déjà le modèle de middleware. Il se tient à l'écart, ce qui est utile jusqu'à ce que chaque route invente sa propre validation, sa forme d'erreur et ses conventions de réponse.
• Fastify est un choix par défaut solide pour les équipes backend de petite et moyenne taille. Son système de plugins est propre, et il pousse le travail de schéma plus près de la couche de route, ce qui aide à maintenir la cohérence de la comportement de runtime avec les types.
• Nest fonctionne bien pour les grandes bases de code avec de nombreux contributeurs, des modules partagés et des limites d'ownership explicites. Le coût est de cérémonie, et ce coût est réel si le service lui-même est petit.

Je préfère généralement ne pas acheter plus de framework que l'équipe n'en utilisera. Un petit service avec Fastify, une bibliothèque de validation et des types de contrat générés survivra souvent mieux aux refacteurs qu'un empilement plus lourd avec des conventions incohérentes superposées.

Utilisez une organisation de dossier qui protège les limites

Les noms de dossier comptent moins que la pression des importations. Si les routes peuvent atteindre les modèles de base de données, ou les services peuvent retourner des entités ORM directement aux clients, la structure est déjà invitante à la dérive.

Une organisation qui tient bon en production sépare généralement les préoccupations de transport des préoccupations d'application :

• src/routes pour la mise en câble HTTP uniquement
• src/schemas pour les schémas de requête et de réponse
• src/dto for transport types and mapping code
• src/services pour les cas d'utilisation et l'orchestration
• src/domain for business models that should outlive any single endpoint
• src/clients pour les intégrations en aval
• src/errors pour les types d'erreurs partagés et les aides de réduction
• src/config pour la configuration de démarrage de parsing

pour cela src/dto Un layer n'est pas du bricolage. Il donne au API un endroit pour absorber les changements externes sans les faire passer dans la logique de domaine ou les faire sortir par des points de terminaison non liés.

La configuration mérite le même traitement. Analysez les variables d'environnement une seule fois au démarrage, échouez rapidement sur des valeurs invalides et exportez un objet de configuration typé vers le reste de l'application. process.env Dans les gestionnaires, les traitements usuels aboutissent à un comportement d'exécution complexe qui ne peut être aidé par TypeScript. Ce guide sur La configuration de l'environnement est une bonne référence si vous avez besoin de standardiser ce modèle.

Raffiner le compilateur avant d'ajouter des fonctionnalités

Une production API devrait rendre les code non sécurisés gênants à écrire.

Les valeurs par défaut utiles incluent :

• strict enabled
• useUnknownInCatchVariables enabled
• noUncheckedIndexedAccess si l'équipe peut gérer la discipline supplémentaire
• Aucun alias de chemin sauf si Node, les tests, la mise en boîte, et les outils résolvent tous les mêmes chemins
• Separé build, typecheck, et linter les scripts dans CI

Un faible tsconfig Laissez les incohérences se transformer en comportements visibles avant qu'ils ne deviennent des comportements de production.

Les règles de linter aident également, surtout les règles contre any, les promesses flottantes, et les exports accidentels de modules de contrat public. Rien de cela remplace la validation en temps réel, mais cela réduit le nombre de lieux où les erreurs de contrat peuvent se cacher.

Une autre choix de mise en place importe tôt. Décidez d'où votre spécification OpenAPI viendra et gardez cette décision proche de la couche de route. Certaines équipes la génèrent à partir de schémas code-premiers. D'autres génèrent des stubs de serveur et des types à partir de la spécification en premier. L'une ou l'autre approche peut fonctionner. Ce qui échoue, c'est de traiter la spécification comme un artefact secondaire que personne ne vérifie après la première mise à jour.

Après la structure initiale, il est utile de comparer le comportement des contrats typés en dehors de services de requête-réponse simples. Guide de TypeScript Streamkap Flink est utile pour les équipes travaillant avec des flux ou des systèmes à événements lourds, où la dérive de contrat se manifeste le long de pipelines plus longs, et pas seulement dans les gestionnaires HTTP.

Conception de DTO et validation de l'entrée à la frontière

Un API typé ressemble généralement correct le jour de la mise en production. Six mois plus tard, les bogues se manifestent à la frontière. Un client mobile envoie toujours un champ ancien. Un partenaire omet une propriété que votre frontend suppose toujours présente. Un refactor expose une colonne ORM interne dans une réponse publique. TypeScript a fait son travail à l'intérieur du codebase. Le contrat a encore dérivé.

C'est pourquoi le design des DTO compte. Il ne s'agit pas de rendre les corps de requête propres. Il s'agit de garder les types publics honnêtes après la première mise à jour.

Les contrats publics et les modèles internes ne devraient pas être les mêmes

A DTO décrit ce qui traverse la liaison. A modèle de domaine décrit ce que l'application doit faire pour effectuer du travail réel. La fusion de ces préoccupations économise quelques lignes au début et crée une couplage coûteux plus tard.

Si votre route reçoit ceci :

type CreateOrderRequestDto = {
  customerId: string
  items: Array<{ sku: string; quantity: number }>
  note?: string | null
}

votre couche de service devrait toujours accepter quelque chose de plus étroit et plus propre, comme un OrderDraft with normalized strings, validated quantities, and defaults applied in one place.

La frontière a généralement besoin de ces étapes:

1. Analyser le flux entrant
2. Valider la forme et les contraintes de champ
3. Mapper l'entité de données à un objet de domaine
4. Exécuter la logique métier sur l'objet de domaine
5. Mapper le résultat à un DTO de réponse
6. Valider la réponse de sortie avant de l'envoyer

Étape six est souvent ignorée. Il s'agit également de l'étape qui détecte les champs privés, les valeurs nulles qui ont échappé à une réponse stable, et les modifications de schéma accidentelles lors des réfacteurs.

Valider avant que la logique métier touche les données

Les types de compilation ne valident pas les JSON provenant du réseau. Ils ne protègent pas non plus contre un autre service qui retourne une forme qui satisfait toujours unknown et brise vos hypothèses en temps d'exécution.

For API work in TypeScript, Zod is a common choice because it parses at runtime and infers types for the rest of the code. Valibot, io-ts, and similar libraries can work too. The library matters less than the rule. Untrusted data gets parsed before anything else uses it.

Un modèle qui résiste aux réfacteurs ressemble à ceci:

• Inbound schémas rejeter les données de requête malformées
• Dépendances schématiques valider les réponses provenant d'APIs tierces et de services internes
• Schémas de sortie vérifier la réponse que votre API est sur le point de publier

C'est cette couche intermédiaire où de nombreuses APIs typées échouent après le lancement. Les équipes valident les requêtes, ignorent la validation des réponses downstream et se demandent ensuite pourquoi un renommage de champ de fournisseur se transforme en incident de production.

Ici est la règle pratique que j'utilise. Le JSON brut s'arrête à la couche de route.

La cartographie de code n'est pas inutile. C'est là où le dérive devient visible.

Les équipes résistent souvent à la mise en correspondance de DTO car cela ressemble à du répétitif. J'ai vu l'opposé en production. Une couche de mise en correspondance mince est là où les changements de contrat deviennent évidents, revus et locaux.

Par exemple :

• transport permet note?: string | null
• le modèle de domaine peut stocker note: string avec "" comme le modèle par défaut
• le DTO de réponse peut omettre note entièrement lorsqu'il est vide

Ces sont trois vérités différentes pour trois publics différents. Les traiter comme une interface partagée cache la différence jusqu'à ce qu'un client se brise.

Un webhook rend cela encore plus clair car les consommateurs peuvent conserver la forme de votre charge utile pendant des années. Si votre équipe travaille sur ce problème, cet exemple de conception de payload de webhook est un compagnon utile.

Les types partagés ne sont utiles que lorsque la source de vérité est explicite

Copier les interfaces backend vers le frontend est un décalage dans le temps. Les packages partagés peuvent aider, mais uniquement pour les types qui sont intentionnellement publics.

Une configuration qui tient mieux dans les grandes bases de code ressemble à ceci :

• définir les schémas de requête et de réponse publics séparément des modèles de persistance
• générer OpenAPI à partir de ces schémas publics, ou générer les types de serveur à partir d'OpenAPI en premier
• garder les types de contrat générés proches des gestionnaires et des clients
• garder les types de domaine et les modèles ORM internes
• versionner délibérément les DTOs publics lorsque la compatibilité compte

Cela est également cohérent avec le Lignes directrices de conception TypeScript de l'équipe Azure SDKqui met l'accent sur les surfaces publiques stables et garde les détails d'implémentation internes hors du contrat.

La bonne version est moins ingénieuse.

Avant, le frontend faisait confiance

Avant, le frontend se fiait fetch().json() Avant, le frontend faisait confiance à la backend comme si c'était la vérité, le backend renvoyait des objets ORM directement, et une interface partagée essayait de représenter chaque couche. Après, chaque seuil de parse les données, les DTOs restent étroits, les modèles de domaine restent internes, les types générés couvrent le contrat public, et la mise à jour code fait les changements explicites.

It ajoute une cérémonie. Il vous donne également un seul endroit pour examiner la dérive avant que les appelsants ne la trouvent pour vous.

Génération et consommation d'un client API entièrement typé

Un client typé peut paraitre terminé le jour de la mise en production. Trois mois plus tard, une fonctionnalité commence à retourner un champ nullable, une autre ajoute une pagination par curseur, et une application mobile fixe une version plus ancienne du contrat. Les types TypeScript continuent à compiler. Les appelsants continuent à se rompre.

C'est là le travail de la couche client. Elle doit garder le contrat publié véridique après la première mise en production, et non seulement rendre l'autocomplétion de l'éditeur jolie.

Choisir votre stratégie de client typé

La forme du client doit correspondre à la complexité réelle du API, et non à la préférence de l'équipe.

Les clients personnalisés fonctionnent pour les surfaces petites

Un fetch wrapper personnalisé est une bonne option lorsque l'API est interne, la surface est petite ou le comportement de transport compte plus que la génération de schéma. Je continue d'utiliser cette approche pour les outils d'administration et les services en phase de démarrage.

Le mode de panne est le dérive. Une équipe ajoute une règle de réessai dans le wrapper. Une autre l'ignore. Une troisième copie un type de réponse dans le frontend et l'élargit à any après la première incohérence. Vous finissez par avoir des appels « typés » qui ne représentent plus ce que le serveur retourne.

Utilisez un client personnalisé lorsque ces conditions sont vraies :

• l’API est petit et interne
• le contrat change souvent, ce qui rend la régénération de code inutile
• le comportement de transport personnalisé domine le travail
• Vous êtes prêt à conserver l'analyse de temps d'exécution côté client, et non seulement les annotations TypeScript.

Cette dernière considération compte. response.json() renvoie des données inconnues en temps de exécution, même si la signature de la fonction le dit autrement.

Génération OpenAPI est la solution par défaut pratique

Pour les APIs REST stables, les types générés donnent le meilleur rapport entre maintenance et sécurité. Ils suppriment une grande partie de l'écriture de types dupliqués et rendent les changements de contrat visibles dans les demandes de tirage.

Le modèle qui survit aux réfacteurs est simple. Générez à partir du contrat public, gardez la couche générée mince et ajoutez un petit enveloppe où vos consommateurs ont besoin d'une meilleure ergonomie. Le L'workflow de génération TypeScript OpenAPI suit bien ce modèle.

Un split utile ressemble à ceci :

• généré code possède les formes de requête et de réponse
• un enveloppe SDK mince possède l'injection d'authentification, les aides de relecture et de pagination
• la validation en temps réel se produit toujours à la frontière du serveur et en tout point où l'entrée non fiable re-pénètre le système
• La mise en correspondance DTO reste explicite, donc les changements internes du modèle ne filtrent pas dans le contrat du client.

Cet approche hybride garde le code généré banal, ce qui est bon. Un code banal est plus facile à regénérer, à réviser et à remplacer.

Enveloppez les clients générés avant qu'ils ne touchent l'application code

Les fonctions générées sont généralement trop brutes pour être utilisées largement dans un codebase. Elles exposent des détails de transport que chaque appelant doit revoir.

Un enveloppe mince vous donne un endroit unique pour maintenir la politique cohérente :

• attach default headers and request IDs
• normaliser les formes d'erreur
• exposer la pagination sous forme d'itérateur ou de méthode d'aide
• supporter les overrides d'authentification par requête pour les cas multi-locataires
• conservez les types de requête et de réponse générés au lieu de les réécrire à la main

Par exemple, l'application code doit appeler client.orders.listAll() ou client.orders.list({ cursor })ne pas assembler manuellement les chaînes de requête et analyser les métadonnées de pagination à chaque emplacement d'appel.

clients de style SDK ont du sens lorsque l’API est un produit

Public APIs and shared platform services need more than generated endpoint functions. Consumers expect naming consistency, predictable errors, and transport details hidden behind methods that match the domain.

Une bonne ergonomie client ressemble généralement à ceci :

• client.orders.list() Par exemple, l'application __CAPGO_KEEP_0__ doit appeler
• client.files.stream() Par exemple, l'application __CAPGO_KEEP_0__ doit appeler
• auth peut être défini globalement et surchargé par requête.
• Par exemple, l'application __CAPGO_KEEP_0__ doit appeler

Cela ajoute des coûts de maintenance. Il empêche également chaque équipe consommatrice de reconstruire les mêmes règles de limite légèrement différentes, ce qui est la façon dont le dérive des contrats se propage.

A la fin, un client typé n'est pas la ligne d'arrivée. La ligne d'arrivée est un client dont les types correspondent toujours à la réalité même après que l’API ait évolué, car la génération commence à partir du contrat public, la validation en temps de exécution protège la frontière, et la mise en correspondance des objets de transfert de données empêche les changements internes de se répandre à l'extérieur.

La gestion des erreurs, le testage et l'observabilité qui aident vraiment

La plupart des exemples TypeScript API sont trop calmes. Les requêtes réussissent, le JSON correspond à l'interface, et les échecs deviennent throw new Error("something went wrong")La production ne se comporte jamais ainsi.

La première correction est mécanique. En TypeScript, les valeurs capturées doivent être traitées comme unknownEnsuite, elle s'est resserrée avant de pouvoir être lue. message, stackou des propriétés de réponse. Une guidance d'expert recommande également des classes d'erreur personnalisées, en conservant l'échec original avec cause, la validation aux limites, la normalisation des exceptions non d'erreur et l'attachement du contexte de requête pour l'observabilité.Conseils de gestion des erreurs en TypeScript).

Étroit les erreurs avant de les toucher

Les blocs de catch non sécurisés sont encore courants :

try {
  await client.orders.create(input)
} catch (error) {
  logger.error(error.message)
}

Cela suppose trop de choses. error peut ne pas être un Error du tout.

Un modèle plus sûr :

try {
  await client.orders.create(input)
} catch (error: unknown) {
  if (error instanceof Error) {
    logger.error({ message: error.message, stack: error.stack })
    throw new OrderSyncError("Order sync failed", { cause: error })
  }

  logger.error({ error })
  throw new OrderSyncError("Order sync failed", { cause: new Error("Non-Error thrown") })
}

Cela semble légèrement plus lourd. Il résiste mieux aux échecs lorsque ceux-ci proviennent de bibliothèques SDK tierces, d'erreurs de parsing JSON ou d'exceptions inattendues.

Réessayer uniquement lorsque l'erreur est transitoire

La deuxième grande amélioration est la classification des erreurs. La guidance pour les opérations TypeScript SDK et API converge vers une règle propre : réessayer les erreurs transitoires telles que les erreurs de réseau ou les réponses HTTP 429 et 503, valider tôt, conserver le contexte d'erreur et éviter les réessais pour les erreurs de règles commerciales. La même guidance recommande également Promise.all pour le travail parallèle rapide et Promise.allSettled lorsque le succès partiel est acceptable (SDK gestion des erreurs).

J'aime trois récipients :

• Les erreurs de validation indique que la requête était incorrecte avant qu'elle ne quitte votre processus.
• Les erreurs transitoires peuvent réussir à nouveau avec un recul.
• Les erreurs permanentes refléter les règles commerciales, les permissions ou les ressources manquantes et les afficher directement.

Cette classification conduit à une meilleure code qu'un assistant générique 'reproposer à l'échec' ne le fera jamais.

Règle de champ : Les redoublements appartiennent à l'incertitude de transport, pas à la désaccord de domaine.

La visibilité devrait expliquer les échecs, et non simplement les enregistrer.

Les journaux sans contexte ne sont pas l'observabilité. Pour API en TypeScript, attachez un ID de corrélation, un nom de route, des métadonnées de requête et une forme d'erreur normalisée à chaque fois qu'une requête franchit une limite.

A un bon point de départ :

• Les IDs de corrélation lient une requête entrante à des appels downstream
• Les journaux structurés stockent des champs, pas des blocs de prose
• Les journaux de limite captent les échecs de parsing séparément des exceptions commerciales
• Alerting s'attache aux classes d'erreur et aux routes, pas seulement au statut code volumétrique

Si vos applications mobiles ou clientes consomment ces APIs, l'actualisation de l'observabilité compte également. Une option pratique dans la couche de mise à jour est Capgoqui fournit des API typées pour l'envoi et la traçabilité des mises à jour en direct dans Capacitor et les environnements Electron. Cela est utile lorsque la correction d'un contrat côté client nécessite un lancement contrôlé et une visibilité par version plutôt qu'une autre attente aveugle de l'app-store. Pour les équipes qui resserrent le boucle de feedback complète, ce guide sur l'observabilité de l'application se marie bien avec la journalisation côté serveur.

Testez le contrat, et non seulement l'implémentation

Les tests unitaires ne détecteront pas le dérive. Ajoutez des tests là où le dérive se produit.

• Tests de validation de limites : Alimentez des entrées malformées dans des schémas et affirmez la forme de l'échec.
• Tests de contrat : Confirmez que les réponses HTTP réelles correspondent au contrat publié.
• Assertions d'erreurs typées : Vérifiez que les échecs transitoires et permanents se normalisent correctement.
• Tests d'intégration côté client : Assurez les clients générés ou enveloppés de traiter les réponses réelles.

Un ensemble de tests solide pour les APIs typées ne prouve pas seulement les chemins code. Il prouve que votre contrat est toujours véridique.

Expédition vers la Production avec Confiance et Contrôle

Qualité de version finale provient d'un boucle répétitif. Pas de prouesses héroïques.

A reliable API in TypeScript pipeline usually has a few essentials: schema checks in CI, type checks on generated artifacts, contract diff review before merge, and a deployment path that can slow down or roll back when a client population isn’t ready.

Le cycle de mise en production qui tient bon

J'aime garder la liste de vérification de production courte au point que les équipes la suivent :

• Échouez CI sur le dérive du contrat : Si OpenAPI change, les types et les clients générés doivent mettre à jour dans la même modification.
• Partagez les contrats partagés délibérément : Public DTO packages need release discipline, not casual refactors.
• Roulez par canal ou par cohorte : N'éxposez pas tous les consommateurs à une modification d'intégration brisante en même temps.
• Gardez le rollback simple : Rétablir le contrat, le client ou le bundle web devrait être opérationnellement banal.

Pour les équipes qui déplacent à la fois leurs infrastructures et leurs flux de déploiement, ce guide à. migration cloud pour les développeurs C'est une référence de planification utile car l’API fiabilité dégrade souvent lors des transitions de plateforme, pas seulement lors des mises à jour code.

Le contrôl’est aussi important que la précision

Si votre pile inclut __CAPGO_KEEP_0__ ou Electron, les outils __CAPGO_KEEP_1__ peuvent réduire le retard entre la correction d’un bug de contrat et la mise à jour des utilisateurs. La partie importante n’est pas « des mises à jour plus rapides » en soi. C’est d’avoir

If your stack includes Capacitor or Electron, live update tooling can reduce the lag between fixing a contract bug and getting the fix into users’ hands. The important part isn’t “faster updates” in the abstract. It’s having afin que les correctifs de contrat restent contrôlés. Les correctifs de contrat restent sous contrôle.

Typed APIs stay healthy when schema, runtime validation, client generation, and release operations all reinforce each other. Miss one layer and the others end up compensating badly.

Capgo offre aux équipes expédiant des applications Capacitor et Electron une façon typée de livrer des correctifs de paquet web, de contrôler les canaux de déploiement et de surveiller l'adoption et les échecs par version. Si vos contrats de API nécessitent également d'atteindre les clients rapidement sans attendre la revue de la boutique, visitez Capgo.