SDK stockage full-stack : une API du serveur Next.js au navigateur React

Le stockage full-stack, c'est souvent trois implémentations : route upload, formulaire client, dashboard avec une autre API. Files SDK traite cela comme un seul problème—une API de stockage du serveur au navigateur.

Pour un **SDK de stockage full-stack** sur Next.js ou un portail client, cette release vaut le détour : gateway, client navigateur, adaptateurs et composants shadcn optionnels sur les mêmes verbes.

Un gateway, plusieurs surfaces

Cœur : **`@files-sdk/api`**. Un endpoint expose upload, download, list, search, url, copy, move, delete, capabilities et URLs signées.

Serveur : **`@files-sdk/next`**, **`@files-sdk/hono`**, Express, Fastify, Koa, Elysia, Nitro, SvelteKit, Astro, Bun, Deno. Client : **`createFilesClient`** ; **`useFiles`** pour React, Vue, Svelte avec **`useList`**, **`useFile`**, **`useSearch`**. Avec **`versioning()`** ou **`softDelete()`** : versions, restore, corbeille, purge.

Pourquoi les stacks séparés échouent

Route handler + dropzone suffit jusqu'aux presign, Range, corbeille ou permissions par préfixe. Sans **gateway API**, chaque feature devient une route et l'auth diverge.

Auth et transport

**Deny-by-default** par opération : préfixes, expiries, lecture seule, allowlists d'origine. Téléchargements redirect ou **proxy stream** ; proxy avec **Range/206** et abort si déconnexion client. Uploads **presign → complete** avec repli proxy.

Adaptateurs serveur

Pour **Files SDK Next.js** : une route montée avec le jeu complet de verbes. Même contrat sur Hono, Express, etc.—auth une fois, client identique sur Vercel ou VPS.

Hooks React

**`createFilesClient`** typé ; **`useFiles`** avec progression et erreurs. Versioning et soft delete dans la même API client—not couche admin séparée.

Registry shadcn/ui

Composants branchés sur **`useFiles`** : dropzone, explorateur + fil d'Ariane, search, preview, partage, progression, actions, historique versions, corbeille.

Quand choisir un SDK

• Upload navigateur + traitement serveur sur le même namespace
• Presign et proxy sans deux codebases
• Versioning ou corbeille comme exigence produit
• Plusieurs frameworks, une politique bucket
• UI shadcn sans file manager custom

Checklist

• Monter **`@files-sdk/api`**
• Règles deny-by-default
• Redirect vs proxy downloads
• **`createFilesClient`** + allowlists
• **`useFiles`** sur formulaires et admin
• shadcn : dropzone d'abord
• Tester presign sur réseaux lents

Pour les agences

Portails clients et bibliothèques d'assets butent sur des permissions ad hoc. Un **SDK full-stack** unifie upload, list, search et delete.

Conclusion

Pari **one-storage-API** : gateway, adaptateurs, **`createFilesClient`**, **`useFiles`**, shadcn—mêmes verbes Files. Deuxième avis sur l'architecture upload ? Contactez-nous.