Resources of its own
The database gets its own CPU, memory and NVMe disk. Heavy queries never slow down the workers of API Maker.
The framework for AI era
The framework for AI era
Level 1 · StartArchitecture 02 of 13
API Maker on one VPS, your databases on servers of their own.
The first split most teams make: each database gets its own CPU, memory and disk, stays off the internet and grows on its own. API Maker reaches it over the private network, along with any database you already run.
Every request is drawn as it travels. Slow it down, pause, go step by step, or open the full canvas and zoom in.
api-maker/architectures/separate-databaseLiveYour data gets servers of its own. Each database moves to a VPS sized for it. API Maker finds it again with a new connection string: no API changes.
The same steps as the diagram, in more detail.
Move each of your databases to a VPS of its own, sized for its data: more memory for its indexes, fast NVMe disks for its writes. In API Maker only the connection string of the instance changes, from 127.0.0.1 to the private IP of the new server. Every generated API, custom API and schema keeps working as it was.
The apps only ever reach API Maker. The database servers accept connections from the private IP of the API server alone, so their ports are closed to the internet. API Maker applies authentication, roles and field level access before any query reaches them, and keeps a pool of connections to each database.
API Maker speaks to all 8 database types at once. With deep populate, one request reads orders from PostgreSQL and fills in their products from MongoDB, across servers and database types. The apps get one response and never need to know where each part of the data lives.
Each server grows on its own schedule. When the orders database gets busy, resize its VPS: the database restarts, API Maker reconnects on its own, and the API server is never touched. Later, the database can become a cluster of its own, as the Resilient architectures show.
A database does not have to move to get APIs. Connect API Maker to the SQL Server of your ERP in your own data center, through a VPN or an SSH tunnel, and it generates the APIs of every table without changing the database. Old and new data are served side by side, by the same API layer.
The database gets its own CPU, memory and NVMe disk. Heavy queries never slow down the workers of API Maker.
Database ports open to the API server only. Every request passes the auth, roles and field level access of API Maker first.
Resize the database server without touching the API server, and the other way around.
PostgreSQL, MongoDB, SQL Server and 5 more types, on any servers, joined in one call with deep populate.
Generate APIs for databases you already run, even in your own data center, without migrating them.
Back up, restore and patch each database on its own schedule, with the tools made for it.
Plain VPS from any provider, or your own servers, with Ubuntu 22.04 LTS. Sizes are a starting point: measure and adjust.
Runs
Ports
Runs
Ports
Give it enough memory to keep the indexes you query most in RAM.
# Instance "orders": PostgreSQL on VPS 2, over the private networkpostgres://api_maker:***@10.0.0.21:5432/shop# Instance "catalog": MongoDB on VPS 3mongodb://api_maker:***@10.0.0.22:27017/catalog?authSource=admin# Instance "erp": the SQL Server you already have, through a VPNServer=10.8.0.2,1433;Database=erp;User Id=api_maker;Password=***;Only the connection string changes when a database moves: every API stays the same.
# On VPS 2: only the API server may reach PostgreSQLufw default deny incomingufw allow sshufw allow from 10.0.0.10 to any port 5432 proto tcpufw enableNo. Only the connection string of the instance changes. Generated APIs, custom APIs, schemas and permissions stay exactly the same.
Yes. Point an instance at any of the 8 supported database types, on any server API Maker can reach, and it generates the APIs of its tables without changing the database.
Custom code runs in Docker sandbox containers. When the database address is different from inside a container, set the sandbox connection string of the instance: it is used from the sandbox only.