Migration
From your backend to API Maker
One API at a time
No big rewrite and no data to copy. API Maker joins on a new server and uses the database you have. The frontend moves over one API at a time, and each move can be undone.
See it live
The old backend on the left, API Maker on a new server, the same database for both. Slow it down, pause, go step by step, or open the full canvas and zoom in.
api-maker/architectures/migrationLive- APIs moved
- 0of 6
- Old backend
- onstatus
- Databases
- 1the same one
- Downtime
- 0seconds
Your backend answers every call today. The frontend calls your backend. Each API is a small box on its server, and they all use one database.
The move in three phases
The same steps as the diagram, in more detail.
Phase 1Get readyNothing changes for your users yet. Your backend answers every call today.
This is where most teams start: one backend, written in any language, with its APIs and the database on its server. Nothing has to stop for the move. The frontend keeps calling these APIs until each one has a new home, and the database stays where it is from the first step to the last.
API Maker joins on a new server.
API Maker Launchpad installs API Maker on a fresh Ubuntu server over SSH, with Caddy for HTTPS. Your project gets an admin account of its own. Nothing is taken away from the current server, and the users of the frontend see no change: every call still goes to your backend.
It points to the same database.
API Maker connects to the database of your current server: its connection string goes in the secret of the account. There is no copy and no sync. Both backends read and write the same rows, so the frontend can call either one for any API. Every table gets its generated APIs at once, with filters, sorting, paging and joins.
Phase 2Switch the easy partAuth, then the APIs API Maker makes for you. Set auth first.
Before the frontend calls anything, set who may call what. The frontend gets an API user, and its groups name the APIs it may use. A custom auth provider checks the tokens your backend gives at sign-in, with the same key: a person who signed in at /login calls both backends with the same token. Groups and pre hooks then narrow every call to the rows of that person.
The frontend moves to the generated APIs.
Reading and saving rows is most of what a backend does. The frontend points those calls to the generated APIs of API Maker, one screen at a time: same tables, same rows. /products and /customers of your backend get no calls any more, and there is no code to write for them. If a screen looks wrong, point it back.
Phase 3Move the logicEach custom API, when it is ready. Then the custom APIs, the first one.
Business logic moves one API at a time. /checkout is written again as a custom API, in TypeScript here, reading the same tables. Test it on the API testing page, with real data, before any user sees it. Then the frontend calls /api/custom-api/shop/checkout, and the old /checkout is left without calls. Going back is one URL in the frontend.
One by one, every API moves.
Each API moves when it is ready, in the language that suits it, and each move is small enough to test and to undo. Last comes /login: a token generator in API Maker signs the same tokens your backend did, so nobody signs in again. Your backend answers fewer calls every week.
Your backend answers nothing. Switch it off.
When the logs of your backend stay empty, stop it. The database is the one it always was: keep it on its server, or give it a server of its own later. What used to be one program is now an account of API Maker, with its APIs, auth, code and Git, on servers you can grow.