Caso 02 · Health marketplace
Recovery Care Solutions: una app en React Native y un backend nuevo, ruta por ruta
Recovery Care Solutions es una plataforma bilingüe que conecta pacientes con hogares y servicios de recuperación para viajes médicos. Construí el cliente móvil en React Native y ahora reemplazo el backend heredado por una API en TypeScript con arquitectura onion, autorización por rol, migraciones SQL y pruebas contra el sistema anterior, sin romper los flujos actuales.
Actualizado:
¿Qué es Recovery Care Solutions?
Es una plataforma para personas que viajan a hacerse un procedimiento médico y necesitan un lugar dónde recuperarse. El paciente busca una estancia según el motivo del viaje (cirugía plástica, cirugía bariátrica, implante capilar, salud mental, rehabilitación u otro), el lugar y las fechas.
Del otro lado están los anfitriones, que publican su casa o apartamento y reciben reservas, y los proveedores de servicios de salud, que ofrecen lo suyo en la misma plataforma. Todo funciona en español y en inglés.
¿Qué problema resolvía?
La web ya permite buscar estancias y gestionar reservas. El trabajo tenía dos frentes: un cliente móvil en React Native y un backend nuevo que reemplace al heredado.
La parte delicada es la segunda: cambiar la base de una plataforma que ya funciona sin romper los flujos de pacientes y anfitriones que dependen de ella.
¿Qué construí?
Construí el cliente móvil y ahora trabajo en la migración del backend:
- El cliente móvil en React Native, hoy en pre-lanzamiento.
- Una API nueva en TypeScript con arquitectura onion, que reemplaza al backend heredado.
- La autorización por rol en la nueva API.
- Las migraciones SQL, para que cada cambio en la base quede versionado.
- Las pruebas contra el sistema anterior, para medir la paridad durante la migración.
¿Cómo está armado?
Mientras dura la migración conviven el sistema anterior y el nuevo. El cambio avanza ruta por ruta:
-
Una ruta a la vez
Se toma una ruta del backend heredado y se implementa en la nueva API en TypeScript.
-
Las reglas en el centro
Con arquitectura onion, las reglas del negocio quedan en el centro, y la base de datos y el framework en las capas de afuera.
-
Permisos por rol
La nueva API aplica autorización por rol: los flujos de paciente y de anfitrión son distintos, y cada uno accede solo a lo suyo.
-
Paridad antes del cambio
La ruta nueva se prueba contra el sistema anterior, y la base cambia con migraciones SQL. Así la paridad se mide en lugar de suponerse.
¿Qué decisiones importaron?
Migrar por partes, no de golpe
Reemplazar todo el backend en un solo cambio obliga a apostar la plataforma entera a un día. Avanzar ruta por ruta mantiene funcionando los flujos actuales mientras la base cambia. Es la idea detrás del patrón que Martin Fowler llama Strangler Fig.
Strangler Fig, de Martin Fowler ↗Medir la paridad con pruebas
Las pruebas contra el sistema anterior convierten la pregunta «¿se rompió algo?» en algo que se puede medir antes de cambiar cada ruta.
Arquitectura onion para la API nueva
Las reglas del negocio no dependen de la base de datos ni del framework, así que la lógica se puede probar sin levantar toda la infraestructura.
¿Qué resuelve hoy?
La web ya permite buscar estancias y gestionar reservas. La app móvil está en pre-lanzamiento y la nueva API avanza ruta por ruta para cambiar la base sin romper los flujos actuales.
Este caso sigue en curso y lo cuento tal cual: lo que ya funciona, lo que está en pre-lanzamiento y lo que todavía se está migrando.
¿Con qué está construido?
Cada enlace lleva a la documentación oficial.
- Next.js ↗
La plataforma web.
- React Native ↗
El cliente móvil.
- TypeScript ↗
El lenguaje de la nueva API.
- Express 5 ↗
Framework HTTP para Node.js.
- PostgreSQL ↗
Base de datos relacional.
- PostGIS ↗
Extensión geoespacial de PostgreSQL.
- Stripe ↗
Pagos.