Rocket Forge Studio logo
Rocket Forge Studio
Estudio web y de producto

Negocio y crecimiento

SDK de almacenamiento full-stack: una API de Next.js al navegador React

Amir Behrouzi8 min de lectura
  • Files SDK
  • Next.js
  • React
  • File upload
  • Developer tools
Hero Files SDK almacenamiento full-stack: gráfico de landing con gateway servidor conectando Next.js y Hono a AWS GCS y R2, clientes React Vue Svelte, auth deny-by-default, UI explorador Campaign Assets y grid de componentes shadcn ui

El almacenamiento full-stack suele ser tres implementaciones distintas: ruta de upload, formulario cliente y panel con otra API. Files SDK lo trata como un solo problema—una API de almacenamiento de servidor a navegador.

Si evalúas un **SDK de almacenamiento full-stack** para Next.js o un portal cliente, esta release merece mirada: gateway, cliente browser, adaptadores y componentes shadcn/ui opcionales sobre los mismos verbos.

Un gateway, muchas superficies

Centro: **`@files-sdk/api`**. Un endpoint expone upload, download, list, search, url, copy, move, delete, capabilities y URLs firmadas.

Servidor: **`@files-sdk/next`**, **`@files-sdk/hono`**, Express, Fastify, Koa, Elysia, Nitro, SvelteKit, Astro, Bun, Deno. Cliente: **`createFilesClient`**; **`useFiles`** en React, Vue y Svelte con **`useList`**, **`useFile`**, **`useSearch`**. Con **`versioning()`** o **`softDelete()`**: versiones, restore, papelera y purge.

Por qué fallan los stacks partidos

Route handler + dropzone funciona hasta presign, Range, papelera o permisos por prefijo. Sin **gateway API**, cada feature es una ruta nueva y la auth deriva.

Auth y transporte

**Deny-by-default** por operación: prefijos, expiries, solo lectura, allowlists de origen. Downloads redirect o **proxy stream**; proxy con **Range/206** y abort si el cliente se desconecta. Uploads **presign → complete** con fallback proxy.

Adaptadores servidor

Para **Files SDK Next.js**: montar una ruta con el verbo completo. Misma forma en Hono, Express, etc.—auth una vez, cliente igual en Vercel o VPS.

Hooks React

**`createFilesClient`** tipado; **`useFiles`** con progreso y errores. Versioning y soft delete en la misma API del cliente—not capa admin separada.

Registry shadcn/ui

Componentes ligados a **`useFiles`**: dropzone, explorador + breadcrumbs, search, preview, share, progreso, acciones, historial de versiones, papelera.

Cuándo usar SDK vs custom

  • Upload browser + procesamiento servidor en el mismo namespace
  • Presign y proxy sin dos codebases
  • Versioning o trash como requisito de producto
  • Varios frameworks, una política de bucket
  • UI shadcn sin file manager custom

Checklist

  • Montar **`@files-sdk/api`**
  • Reglas deny-by-default
  • Redirect vs proxy downloads
  • **`createFilesClient`** + allowlists
  • **`useFiles`** en formularios y admin
  • shadcn: dropzone primero
  • Probar presign en redes lentas

Para agencias

Portales cliente y bibliotecas de assets chocan con permisos custom. Un **SDK full-stack** unifica upload, list, search y delete.

Conclusión

Apuesta **one-storage-API**: gateway, adaptadores, **`createFilesClient`**, **`useFiles`**, shadcn—mismos verbos Files. ¿Segunda opinión en arquitectura de uploads? Escríbenos.

← All articles