Backend de API para un producto multi-cliente
Un backend de API para un producto multi-cliente es un solo sistema del lado del servidor contra el que llaman una app web, una app móvil y, muchas veces, integraciones de socios, en vez de que cada cliente implemente su propia versión de la misma lógica de negocio. Aplica a empresas que ya tienen, o están por construir, más de una superficie de cliente y necesitan datos y comportamiento consistentes entre ellas: el mismo estado de pedido, la misma regla de precio, la misma validación de permisos. FreyreSoft diseña esto alrededor de autenticación y autorización claras, versionado explícito de la API para que los clientes existentes no se rompan al agregar otros nuevos, y un esquema de base de datos relacional para soportar acceso concurrente desde múltiples fuentes, no uno pensado solo para una sola app. El objetivo es un backend contra el que socios y equipos internos puedan integrar sin ingeniería inversa de comportamiento sin documentar.
¿Qué problema resuelve?
En cuanto un producto tiene más de un cliente, la lógica de negocio tiende a duplicarse: la app móvil calcula un descuento de una forma, la app web de otra, y una integración de socio de una tercera, porque cada una se construyó contra la base de datos o un endpoint antiguo directamente en vez de un contrato compartido. Los bugs entonces aparecen de forma inconsistente entre clientes, las correcciones hay que aplicarlas en varios lugares, y agregar un cliente nuevo implica hacer ingeniería inversa de cómo se comportan los existentes. La autenticación suele ser el primer punto donde esto se nota: las sesiones pensadas para un sitio web no se trasladan bien a una app móvil o a una integración de terceros, y sin versionado, un cambio hecho para un cliente rompe silenciosamente a otro que ya está en producción.
Cómo lo abordamos
El backend se construye como la única fuente de verdad para la lógica de negocio, con cada cliente, web, móvil o socio, llamando a la misma API versionada en vez de hablar directo con la base de datos o duplicar reglas del lado del cliente. La autenticación suele usar tokens (JWT u OAuth2), apropiados para clientes móviles y de socios sin estado de sesión, con scopes que controlan qué puede hacer cada tipo de cliente. El versionado se planea desde el inicio, normalmente por la ruta de la URL o un header, para que las integraciones existentes sigan funcionando al lanzar capacidades nuevas. La base de datos, casi siempre PostgreSQL por su manejo de concurrencia, o MongoDB cuando el modelo de datos es genuinamente de tipo documento, se diseña alrededor del dominio y no de las pantallas de un solo cliente. Se usa Node.js, Go o Ruby según el throughput y las herramientas que ya tenga el equipo. El rate limiting y el logging estructurado son parte de la construcción inicial, no algo agregado después cuando crece el tráfico.
Tecnología que solemos usar
- Node.js, Go o Ruby
- PostgreSQL o MongoDB
- Autenticación JWT u OAuth2
- API REST o GraphQL versionada
- Middleware de rate limiting
- Logging estructurado de requests
Qué suele implicar un proyecto así
- Diseñar el modelo de autenticación y autorización entre tipos de cliente
- Definir una estrategia de versionado que no rompa a los clientes existentes
- Modelar la base de datos alrededor del dominio y no de un solo cliente
- Configurar rate limiting y logging para soportar tráfico concurrente real
- Redactar documentación de API contra la que desarrolladores de socios puedan integrar directamente
¿Tienes en mente algo parecido a esto?
Contáctanos