Alfredo Mejía.

Un framework web de TypeScript con decoradores, DI y OpenAPI, publicado en npm.

Escribí el framework que quería usar: controladores declarativos con decoradores, inyección de dependencias, validación con Zod y un esquema OpenAPI 3.1 que se genera solo a partir de los tipos. Corre sobre Bun, Node, Deno y Workers.

3.5.1

versión en npm

4

runtimes

MIT

licencia

• Decoradores de controlador, ruta, guard y middleware con tipos completos.
• Contenedor de inyección de dependencias por constructor.
• Documentación OpenAPI derivada de los esquemas Zod, no escrita a mano.
• Gateways de WebSocket con el mismo modelo de decoradores que el HTTP.

Un marketplace completo: catálogo, carrito, checkout, pagos al vendedor, disputas y chat en vivo.

Varias tiendas venden en un mismo sitio. Un pedido se parte en subpedidos, uno por vendedor, y cada uno sigue su propio camino: se envía, se recibe, se opina y se le paga al vendedor. El dinero no se mueve hasta que el comprador confirma que recibió. Vive en tres repos: la API, la interfaz y los esquemas de Zod que ambas comparten, para que un cambio de contrato rompa la compilación y no la producción.

79

rutas HTTP

22

tablas

355

pruebas e2e

• El checkout concurrente no vende de más: el stock se descuenta con un UPDATE condicional dentro de la transacción.
• Un índice único parcial impide que el mismo comprador tenga dos pedidos pendientes de pago a la vez.
• El webhook de pago es idempotente por id de evento; los reintentos del proveedor no duplican nada.
• La autorización nunca sale del token: cada petición de vendedor relee su tienda en la base.
• Pedir un recurso de otra persona responde 404, no 403: un 403 confirmaría que ese id existe.
• Chat por WebSocket con boleto de un minuto, en vez de mandar el token en la URL.

La respuesta llega token a token, se puede cortar a media frase, y cada turno deja contados sus tokens y su costo.

Un chat sobre la API de un modelo, con conversaciones persistidas y documentos adjuntos que entran al contexto. Lo construí para contestar una pregunta concreta sobre mi propio framework: si sus piezas de streaming y cancelación aguantan un caso real. Aguantan, y el camino dejó tres hallazgos escritos en el README.

23

rutas HTTP

8

tablas

44

aserciones

• Cancelar corta la generación, no solo la pantalla: si solo se cierra el canal, el servidor sigue produciendo tokens que ya nadie va a leer pero que sí se cobran.
• Lo difícil de eso fue que el bucle del proveedor termine no quiere decir que la respuesta terminara: un adaptador que corta limpio al abortar sale por el mismo camino que uno que acabó. Lo que distingue los dos casos es la señal.
• El mensaje del asistente se inserta vacío antes del primer token. Si el proceso se cae a media respuesta queda el parcial, y no un hueco donde el usuario cree que escribió algo que nunca existió.
• El tope de gasto se revisa antes de llamar al modelo y contando los documentos adjuntos, que viajan en cada turno. Un bucle aquí no es un error de log: es una factura.
• Un yield por token hace que React re-renderice por carácter y el chat se traba justo cuando debería verse vivo; se agrupa por cuadro de 16 ms y se vuelca lo que quede al final.
• El modelo vive detrás de una interfaz con dos adaptadores. La demostración pública habla con Gemini de verdad, y lo que la hace sostenible no es la confianza sino el tope: el gasto se revisa antes de cada llamada y el adaptador falso sigue ahí para las pruebas, que no deberían costar dinero.