gm-libs, los paquetes base de cada frontend y backend de Webanion
Una familia de paquetes versionados e independientes del framework de la que parte cada frontend y backend de Webanion, con una capa de NestJS en el servidor y bindings para React, Vue y Expo en el cliente: autenticación con passkeys e inicio de sesión único, feature flags, un registro de auditoría, datos multi-tenant, cifrado, archivos, documentos, mensajería, tiempo real y modo sin conexión, webhooks, workers y un kit de UI. Cada paquete vive en su propio repositorio privado con sus propias versiones y se instala desde el registro npm privado del estudio, y la consola del estudio muestra qué consumidor va por detrás en qué versión.
Md Moniruzzaman
La historia completa
Por qué a los clientes de un estudio les conviene que la autenticación, la auditoría y los feature flags se resuelvan una vez, se versionen y se reutilicen en todas partes.
Cada backend empezaba desde cero
Todo backend por el que paga un cliente necesita las mismas bases antes de hacer nada que al cliente le importe: inicio de sesión, sesiones, permisos, configuración, almacenamiento de archivos, correos, PDF, tareas en segundo plano y un registro de auditoría. Escritas de nuevo en cada proyecto, esas piezas cuestan semanas, cambian de un proyecto a otro y arrastran sus propios errores.
gm-libs es la respuesta: la infraestructura de base extraída de trabajos donde ya había demostrado su valor, reforzada en paquetes con versiones, documentación y changelogs, y reutilizada en los frontends y backends que construye el estudio.
Inicio de sesión y permisos, resueltos una vez
El paquete de autenticación trae hash de contraseñas con Argon2id, tokens de acceso de corta duración con sesiones de refresco rotativas y permisos basados en relaciones sobre OpenFGA, de modo que una regla como «el personal de una sucursal solo ve su sucursal» es un modelo declarado y no comprobaciones dispersas por el código. También incluye inicio de sesión social y OIDC con vinculación de cuentas, inicio de sesión sin contraseña, autenticación multifactor, passkeys e inicio de sesión único. Un backend nuevo lo obtiene todo importando un solo módulo.
Para el cliente, eso significa una seguridad ya reforzada y probada en una plataforma financiera, no reinventada con prisas ante una fecha límite.
Funciones que se activan con seguridad
El paquete de flags decide qué se muestra y qué se ejecuta para cada tenant, sucursal, rol o persona, y nunca bloquea una petición: los flags se leen de memoria, y si no se puede llegar al servidor de flags, cada flag vuelve a un valor por defecto seguro, desactivado salvo que el equipo haya elegido otra cosa. Complementa la autorización en lugar de sustituirla, de modo que nada aparece si el flag y el permiso no dicen que sí a la vez.
Los clientes pueden lanzar una función primero para una sucursal o una persona, observarla y ampliarla sin un nuevo despliegue, que es como el equipo de Al-Insaf gestiona sus propias funciones.
Un registro de auditoría que nunca frena a nadie
El paquete de auditoría registra quién hizo qué, dónde y cuándo en cada escritura, con su categoría y su gravedad, y saca cada entrada del camino de la petición para escribirla por lotes. Si el almacén de auditoría va lento o falla, queda constancia en el log y nunca se bloquea a la persona que usa el sistema, y eso es lo que permite auditar con seguridad todo lo que importa.
Cada paquete, una sola tarea
Junto a auth, flags y audit, la familia cubre el resto de lo que necesitan un frontend y un backend, cada paquete con una sola tarea y conectado de la misma manera: código independiente del framework por debajo, una capa de NestJS para el servidor y bindings para React, Vue y Expo allí donde un paquete llega al cliente.
- Base y datos: core (errores, contexto de la petición, un logger que oculta las credenciales, configuración tipada que falla de inmediato si falta un secreto, dinero, paginación, limitación de peticiones, idempotencia y health) y db (Postgres multi-tenant, con una base de datos por tenant, migraciones y modelos).
- Identidad y acceso: auth, flags, audit y crypto, para el cifrado de sobre de campos y secretos con claves que rotan.
- Archivos, documentos y mensajes: media para el almacenamiento y las subidas firmadas, pdf, tabular para exportar CSV y XLSX en streaming e importar con validación, notifications para correo, SMS, push y chat de equipo, y chat para conversaciones en tiempo real.
- Tiempo real y sin conexión: realtime para eventos autenticados por canal, con un cliente que se reconecta para React, Vue y Expo, y offline para una caché por usuario y una cola de escritura que envía exactamente una vez, en el navegador y en apps de Expo.
- Integración y ejecución: webhooks firmados según la especificación Standard Webhooks, worker para Temporal, web para un navegador headless reforzado y un fetch saliente que rechaza direcciones internas, datavault para copias de seguridad de bases de datos cifradas y en streaming, y mcp para construir servidores MCP.
- Interfaz: ui, desde los design tokens hasta los componentes de React, Vue, Next.js y Expo.
A su lado, devkit es la comprobación que cada biblioteca ejecuta antes de publicar una versión. Cada paquete vive en su propio repositorio privado con sus propias versiones, así que el sistema de un cliente solo cambia cuando su equipo adopta la nueva versión.
Una corrección, todos los sistemas
Como los frontends y backends del estudio comparten las mismas bases, una corrección de seguridad o una mejora hecha una vez llega a todos ellos mediante un cambio de versión, con un changelog que explica qué cambió y por qué. Las versiones semánticas se respetan de una publicación a otra, así que el sistema de ningún cliente se rompe porque otro cliente necesitara algo nuevo, y la consola muestra ese mismo día qué consumidor aún no ha adoptado una versión.
Para los clientes, el resultado es una entrega más rápida, menos sorpresas y un producto construido con piezas que ya han pasado por producción en otros proyectos, entre ellos la plataforma financiera con rigor de libro mayor de la historia de Al-Insaf.
Cada paquete, publicado y vigilado
Cada paquete se instala desde el registro npm privado del estudio, y la consola del estudio lee ese registro como lo haría un consumidor. Hace ping al registro, lee cada versión de cada paquete con su fecha de publicación, su tamaño empaquetado y su integridad, y lee los propios manifiestos de los consumidores en su rama por defecto para juzgar si cada dependencia apunta a la última versión. Una familia de bibliotecas solo es tan útil como la prueba de que cada sistema que la usa está al día, y esa prueba vive aquí.
El día de la captura, el 30 de septiembre de 2026, la vista mostraba el registro en marcha, cada paquete publicado, una copia de seguridad reciente del propio registro y a todos los consumidores en las últimas versiones, salvo las herramientas propias del estudio, que seguían con versiones anteriores de core y pdf.
De un GitHub Release a npm install, a través del registro del estudio
Una etiqueta en una biblioteca lanza su publicación en GitHub y adjunta un único archivo empaquetado al release. Una sincronización dentro del clúster publica ese mismo archivo cada cinco minutos, de modo que el release y el registro guardan los mismos bytes, que se comprueban de nuevo cada noche. Para leer hace falta iniciar sesión, y el nombre público rechaza las escrituras. GitHub Packages quedó descartado porque las bibliotecas y sus consumidores viven en organizaciones distintas.
También te puede gustar
Fully Booked - Producción de videos promocionales y tutoriales
Un vídeo promocional que recorre con un operador de minibuses del Reino Unido las ventajas de Fully Booked en el orden en que le importan, hecho con la app real y no con imágenes de archivo. Empieza por el propio problema del operador, dedica a cada ventaja un momento en una pantalla real y se editó en varias duraciones, desde un gancho de pocos segundos para redes sociales hasta una versión completa para páginas de destino y las fichas de las tiendas.
Md Moniruzzaman
jun 24, 2025
Fully Booked - Diseño de activos visuales con Photoshop
Capturas para las tiendas, un gráfico destacado, un icono de app y el arte de los correos, creados en Photoshop a partir de pantallas reales para que una plataforma joven parezca consolidada ante los operadores. Las capturas cuentan la propuesta en cinco deslizamientos en cada tamaño que exigen Apple y Google, cada correo se abre con su propia ilustración en los colores de la marca, y el icono y las pantallas de bienvenida llevan el logotipo de dos manos que se encuentran.
Md Moniruzzaman
jun 24, 2025
Fully Booked - Diseño UI/UX para app móvil y panel de administración
Cada pantalla de Fully Booked empezó como un boceto que el fundador aprobaba antes de pagar una sola línea de código, y cada una responde a un problema de un operador o de un cliente. La pantalla de inicio del operador se convirtió en un menú de ingresos, Get Covered mantuvo el orden de su flujo dibujado a mano, los presupuestos y las cartas de cancelación salieron de las propias palabras del fundador, y la administración pasó de cinco pestañas en wireframe a la sala de control de la red. Las pantallas del MVP las diseñó otro miembro de Webanion; las fases 2, 3 y 4 las rediseñé yo mismo en Figma, a partir de estos flujos.
Md Moniruzzaman
jun 24, 2025
El blog son notas de campo desde producción: decisiones de arquitectura, sistemas de AI que sobrevivieron al contacto con usuarios reales e infraestructura que se paga sola. Escrito desde el trabajo, no sobre él.