Files SDK
Files SDK es un SDK de almacenamiento unificado con una API consistente para backends de objetos y blobs como S3, R2, GCS y Azure, con adaptadores.
¿Qué es Files SDK?
Files SDK es un SDK de almacenamiento unificado que expone una única API consistente para interactuar con backends de almacenamiento de objetos y blobs. Su objetivo es permitirte usar las mismas operaciones de alto nivel —como subir, descargar, listar, eliminar y ayudantes relacionados— mientras utilizas diferentes proveedores en segundo plano.
Funciona enrutando las solicitudes a través de un adaptador específico del proveedor. Esto mantiene estables las partes compartidas de los flujos de almacenamiento y permite que las diferencias entre proveedores (como comportamientos relacionados con URLs o ciertos casos especiales) se gestionen dentro del adaptador sin modificar los puntos de llamada.
Características principales
- Una sola clase Files para todos los proveedores: Usa una única superficie de API para las operaciones de almacenamiento comunes (subir, descargar, listar, eliminar, head, exists, copiar y ayudantes de URL), en lugar de escribir código específico para cada backend.
- Selección de proveedor basada en adaptador al construir la instancia: El adaptador se fija al instanciar
new Files({ adapter: ... }), evitando patrones de “elegir proveedor por llamada” que complicarían el uso. - Soporte para entradas según estándares web: Acepta
File,Blob,ReadableStream,ArrayBufferystringcomo entradas para subidas. - Funciona donde se ejecuta
fetch: Diseñado para entornos como Node, Bun, Workers y Vercel (según se indica en la página) para un comportamiento consistente en tiempo de ejecución. - Escapada a proveedor mediante
files.raw: Cuando necesitas funcionalidad específica del proveedor, puedes acceder al cliente nativo a través de una propiedad (files.raw), tipada según el adaptador. - Gestión de errores normalizada: Los errores se presentan como un único tipo
FilesErrorcon un código normalizado entre proveedores, y el error original del proveedor se adjunta como causa.
Cómo usar Files SDK
- Instala el SDK (y solo los adaptadores que planees usar como dependencias pares):
npm install files-sdk
- Importa
Filesy un adaptador de proveedor, luego crea una instancia deFilescon el adaptador configurado para tu bucket/región (por ejemplo, S3). - Llama a los métodos compartidos en la instancia, como:
files.upload(key, input)files.download(key)files.head(key)files.list({ prefix })files.delete(key)
- Usa
files.rawsi necesitas acceder a características específicas del proveedor que no están en la superficie de la API común.
Un ejemplo mínimo de la página:
import { Files } from "files-sdk";
import { s3 } from "files-sdk/s3";
const files = new Files({
adapter: s3({ bucket: "uploads", region: "us-east-1" }),
});
await files.upload("hello.txt", "world");
const file = await files.download("hello.txt");
const meta = await files.head("hello.txt");
const items = await files.list();
await files.delete("hello.txt");
Casos de uso
- Construir una capa de almacenamiento que pueda cambiar de proveedor: Comienza con un backend (por ejemplo, almacenamiento compatible con S3) y luego migra a otro adaptador sin reescribir la lógica de subida/descarga/listado/eliminación de tu aplicación.
- Manejar entradas de archivos tipo navegador de forma consistente en código de backend: Usa los tipos de entrada admitidos por el SDK (
File,Blob,ReadableStream,ArrayBuffer,string) cuando tu servidor recibe objetos de archivos según estándares web. - Organizar subidas por prefijos y gestionar ciclos de vida de objetos al nivel de aplicación: Usa
list({ prefix })ydelete(key)pat
Alternativas
- SDKs de almacenamiento específicos del proveedor (por ejemplo, clientes nativos de S3/GCS/Azure): Estos ofrecen cobertura completa del proveedor, pero suelen requerir rutas de código diferentes para cada backend y manejo separado de tareas comunes.
- Capas de abstracción de almacenamiento de objetos sin entradas web estándar: Algunas abstracciones proporcionan una interfaz unificada, pero pueden no admitir el mismo conjunto de tipos de entrada nativos de la web ni suposiciones de tiempo de ejecución orientadas a
fetch. - Bibliotecas de carga de archivos del lado del servidor con opción de backend de almacenamiento: Útiles cuando tu objetivo principal es el manejo de cargas, pero pueden no exponer el mismo conjunto de operaciones estandarizadas (ayudantes de head/exists/copy/url) y acceso de escape a través del cliente nativo.
- Integración HTTP directa a endpoints de objetos/Blobs: Si necesitas el máximo control, llamar directamente a las APIs HTTP del proveedor evita la abstracción, pero traslada la gestión de listados, firmas, normalización de errores y diferencias entre proveedores a tu aplicación.
Alternativas
open-codex-computer-use
open-codex-computer-use es un servicio open source de “Computer Use” como servidor MCP para automatizar acciones GUI en macOS, Linux y Windows.
Lasso
Lasso es un PIM con IA para equipos de ecommerce: enriquece atributos y descripciones, procesa datos de proveedores y monitoriza competidores por app o API.
Codex Plugins
Usa Codex Plugins para combinar skills, integraciones de apps y servidores MCP en flujos reutilizables que amplían el acceso de Codex a Gmail, Drive y Slack.
Struere
Struere es un sistema operativo nativo de IA que reemplaza los flujos en hojas de cálculo por software estructurado: paneles, alertas y automatizaciones.
Ably Chat
Ably Chat es una API y SDK de chat para crear aplicaciones personalizadas en tiempo real: reacciones, presencia y edición/eliminación de mensajes.
garden-md
Convierte transcripciones de reuniones en un wiki de empresa estructurado y enlazado con archivos Markdown locales y vista HTML; sincroniza desde fuentes compatibles.