Case 02 · Health marketplace
Recovery Care Solutions: a React Native app and a new backend, route by route
Recovery Care Solutions is a bilingual platform connecting patients with recovery homes and services for medical travel. I built the React Native mobile client and am now replacing the legacy backend with a TypeScript API using onion architecture, role-based authorization, SQL migrations and tests against the previous system, without breaking current flows.
Updated:
What is Recovery Care Solutions?
It is a platform for people who travel for a medical procedure and need a place to recover. The patient searches for a stay by the reason for the trip (plastic surgery, bariatric surgery, hair transplant, mental health, rehabilitation or other), the location and the dates.
On the other side are hosts, who list their house or apartment and receive bookings, and health service providers, who offer their services on the same platform. Everything works in Spanish and English.
What problem did it solve?
The web platform already supports stay search and bookings. The work had two fronts: a React Native mobile client and a new backend to replace the legacy one.
The delicate part is the second: changing the foundation of a platform that already works without breaking the patient and host flows that depend on it.
What did I build?
I built the mobile client and now work on the backend migration:
- The React Native mobile client, now in pre-launch.
- A new TypeScript API with onion architecture that replaces the legacy backend.
- Role-based authorization in the new API.
- SQL migrations, so every database change is versioned.
- Tests against the previous system, to measure parity during the migration.
How is it put together?
While the migration lasts, the previous system and the new one run side by side. The change moves route by route:
-
One route at a time
A route from the legacy backend is taken and implemented in the new TypeScript API.
-
Rules at the center
With onion architecture, the business rules sit at the center, and the database and the framework live in the outer layers.
-
Permissions by role
The new API applies role-based authorization: patient and host flows are different, and each one reaches only what belongs to it.
-
Parity before the switch
The new route is tested against the previous system, and the database changes through SQL migrations. That way parity is measured, not assumed.
Which decisions mattered?
Migrate in parts, not all at once
Replacing the whole backend in one change bets the entire platform on a single day. Moving route by route keeps current flows working while the foundation changes. It is the idea behind the pattern Martin Fowler calls the Strangler Fig.
Strangler Fig, by Martin Fowler ↗Measure parity with tests
Tests against the previous system turn the question “did anything break?” into something you can measure before switching each route.
Onion architecture for the new API
The business rules do not depend on the database or the framework, so the logic can be tested without bringing up the whole infrastructure.
What does it solve today?
The web platform already supports stay search and bookings. The mobile app is in pre-launch, while the new API advances route by route without breaking current flows.
This case is still in progress, and I tell it as it is: what already works, what is in pre-launch and what is still being migrated.
What is it built with?
Each link goes to the official documentation.
- Next.js ↗
The web platform.
- React Native ↗
The mobile client.
- TypeScript ↗
The language of the new API.
- Express 5 ↗
HTTP framework for Node.js.
- PostgreSQL ↗
Relational database.
- PostGIS ↗
Geospatial extension for PostgreSQL.
- Stripe ↗
Payments.