API Maker

The framework for AI era

Level 3 · ScaleArchitecture 07 of 13

Many projects, one platform

One API Maker fleet hosts many projects, each with its own APIs, databases, sandboxes and Git.

Every project is an admin account of the same platform: its own API path, databases, users, secrets and sandbox containers. The servers, API Maker DB and Redis are shared and run once. New projects come from a single API call.

Watch it live Server configuration

See it live

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/multi-projectLive
  • Shop
  • CRM
  • IoT
  • Delivery
  • Management API
  • Analytics
Projects
3active
Servers
2shared
Workers
12CPU cores
Capacity
~7,288req/s

Every project, a space of its own. Shop, CRM and IoT are admin accounts of one platform. Each has its own API path, databases, users and secrets.

How it works

The same steps as the diagram, in more detail.

  1. Every project, a space of its own.

    Each project is an admin user of the same API Maker installation, with a path of its own in every URL, like /api/gen/shop/… and /api/gen/crm/…. It has its own database instances, schemas, custom APIs, secrets, auth providers, users, roles and developers. Projects never see each other's data or code.

  2. Custom code stays in its project.

    Custom APIs, hooks and schedulers of a project run in sandbox containers created for that admin user only, with the npm packages it chose. A heavy job of one project cannot read the files or the memory of another, and idle sandboxes are removed after a few minutes to free resources.

  3. One fleet to run for everyone.

    The projects share the servers, the load balancer, API Maker DB and Redis, each item stored under the admin it belongs to. You run, monitor, back up and update one platform instead of one per project, and the spare capacity of quiet projects serves the busy ones.

  4. The root user sees the whole fleet.

    The root user manages the installation: root settings, the servers of the fleet, their Docker containers and logs, and the admin accounts. The Analytics dashboard gives the root user every server and every project, while each admin and developer sees only their own APIs and traffic.

  5. A new project from one API call.

    Projects can be created by a script or by your own product: one call to the management API of API Maker creates the admin user, saves its secrets, pulls its APIs from its Git repository and returns a deployment hook. The new project is served by the fleet at once.

  6. Pause a project, keep its data.

    The root user can make an admin user inactive: its sandboxes are removed and its resources freed, while its APIs, settings and data stay in place. Activate it again and it is back as it was. Useful for seasonal projects, trials, and clients who stop paying.

Why choose this architecture

Spaces that never mix

Each project has its own API path, instances, schemas, users, roles, secrets and developers.

Code in its own sandboxes

Custom code of each project runs in sandbox containers of its own, with the packages it chose.

One platform to pay for

Quiet projects leave room for busy ones on shared servers, instead of a half-idle server per project.

Projects on demand

One call to the management API creates an admin, saves its secrets and pulls its APIs from Git.

Pause without losing anything

An inactive project frees its sandboxes and keeps its APIs, settings and data until it comes back.

The right view for each

The root user sees the whole fleet in the dashboards, each admin and developer sees only their own traffic.

Server configuration

Plain VPS from any provider, or your own servers, with Ubuntu 22.04 LTS. Sizes are a starting point: measure and adjust.

Load balancer

×1
CPU
2 vCPU
Memory
2 GB
Storage
20 GB SSD

Runs

  • TLS for your API domain
  • HTTP to 38246, WebSockets to 38245

Ports

  • 443

API servers

×2 or more
CPU
6 – 8 vCPU
Memory
12 – 16 GB
Storage
60 GB SSD

Runs

  • API Maker, cpuCount AUTO
  • Docker: sandboxes of every project

Ports

  • 38246 and 38245: from the load balancer only
  • 4626: admin panel

Sandboxes are per project: give the servers memory for the projects that run custom code at the same time.

Platform data

×1
CPU
4 vCPU
Memory
16 GB
Storage
150 GB NVMe

Runs

  • API Maker DB: definitions of every project
  • Redis: cache and events of every project

Ports

  • From the API servers only

Project databases

1+ per project
CPU
as needed
Memory
as needed
Storage
as needed

Runs

  • Any of the 8 database types, chosen by each project
  • Small projects can share a database server
Create a project with one callmanagement API
// POST https://api.example.com/api/sites/root-user-settings/operate-api-maker-using-api{    "token": "<communication token of the root settings>",    "operation": "CREATE_ADMIN_USER",    "payload": {        "user": {            "name": "Delivery",            "email": "[email protected]",            "password": "***",            "apiPath": "delivery",            "gitUrlWithCredentials": "https://user:[email protected]/delivery.git",            "gitBranch": "main"        },        "secret": { "name": "Default", "keysCode": "" }    }}

Enable it in Root Settings → Deployment Settings → API Access. The answer holds the new admin, the result of the Git pull and a deployment hook.

Good to know

  • Projects share the fleet: one very busy project uses capacity the others would like. Watch the traffic per project.
  • One platform to update: every project moves to a new version of API Maker together.
  • Projects that need strict physical separation, like regulated customers, are better served by the multi-tenant architecture.
When you outgrow itOne product serves many customers, each needing a database of its own. Multi-tenant: a database per customer

Questions

What is shared between projects, and what is not?

Shared: the servers, the load balancer, API Maker DB and Redis. Separate: API paths, database instances, schemas, custom APIs, secrets, auth providers, users, roles, developers, sandbox containers and Git repositories.

Can a user log in to several projects?

By default a token works only in the admin account that issued it. A root setting lets the same token be used in other admin accounts where a user with the same username and password exists, with the permissions of that account.

How is this different from multi-tenant?

Here each project is a different product with its own APIs. In the multi-tenant architecture one product and one set of APIs serve many customers, each with a database of their own.