Skip to main content

Principe fondamental

Règle d’or : Aucun composant ne doit appeler nhost.graphql directement. Toutes les interactions passent par le dossier src/api/ via les wrappers apiCall() et apiCallVoid().

❌ Ne jamais faire

✅ Toujours faire


Structure de l’API layer


Fichiers de base

client.ts - Client Nhost singleton

Pourquoi un singleton ?
  • Une seule instance partagée
  • Gestion de session centralisée par Nhost
  • Token JWT automatiquement injecté dans les requêtes

base.ts - Wrappers et gestion d’erreurs

Bénéfices :
  • Erreurs typées (ApiError) et prévisibles
  • Logging centralisé via logger (pas de console.log)
  • Détection automatique des erreurs réseau
  • Nom d’opération pour le debugging

Patterns d’utilisation

Pattern 1 : Query simple

Pattern 2 : Mutation avec variables

Pattern 3 : Update avec _set (convention Hasura)

Convention Hasura : Utilisez _set (avec underscore) pour les champs à mettre à jour dans les mutations. C’est le format attendu par Hasura.

Pattern 4 : Delete (void)


Authentification

auth.ts


Bonnes pratiques

✅ À faire

  1. Toujours utiliser apiCall/apiCallVoid
  2. Toujours typer les retours : Promise<EnhancedTool[]>
  3. Utiliser logger au lieu de console.log
  4. Nommer les opérations : 'tools.list', 'workflows.create'
  5. Valider les entrées côté client avant d’envoyer

❌ À éviter

  1. Appels nhost.graphql directs dans les composants
  2. Ignorer les erreurs silencieusement
  3. Types any — utiliser src/api/types.ts
  4. console.log en production — utiliser logger

Ressources

Nhost & GraphQL

Architecture backend complète

Database Schema

Structure des 13 tables

Hooks

Utiliser l’API dans des hooks

Testing

Tester l’API layer