API Maker

The backend engine for the AI era

Microservices

Microservices on one installation

One installation of API Maker holds many admin accounts. Give each service of your backend an account of its own: its own APIs, data, languages, secrets and Git. The services share the servers, so you run one installation, not a stack per service.

  • Many services, 1 installation
  • A service per admin account
  • 8 languages
  • One sign-in for all

One installation, many services

A shop split into six services. Each one is an admin account, with its own API path, language and database. They all run on the same servers.

api.example.com1 installation
  • Identity/identityTypeScript · PostgreSQL
  • Catalog/catalogTypeScript · MongoDB
  • Orders/ordersGo · PostgreSQL
  • Payments/paymentsC# · SQL Server
  • Shipping/shippingPython · MySQL
  • Notifications/notifyTypeScript · MongoDB
Shared by every service Servers Caddy API Maker DB Redis

A service is an admin account

Each service owns

  • Its API path /api/…/orders/… in every URL picks the service.
  • Its databases Connection strings in its own secret, of any of 8 types.
  • Its code Custom APIs, hooks, events and schedulers in 8 languages.
  • Its sandboxes Containers and packages of its own, for each language.
  • Its secrets Keys and passwords no other account can read.
  • Its Git repository With a deployment hook for its own CI.
  • Its access rules API users, groups and sign-in providers.
  • Its logs and traffic Dashboards that show its own calls only.

The installation shares

  • The servers One API Maker process per server answers every account.
  • Caddy HTTPS, certificates and one address for all.
  • API Maker DB The definitions of every account, kept apart.
  • Redis Cache, events between servers and locks.
  • The root user Creates accounts, updates, sees everything.

Sandboxes keep faulty code apart, not hostile code. Put services of one company, written by teams you trust, on one installation.

How services talk

API calls

A service calls the API of another one, with its token. Retries, timeouts and parallel calls are built in.

g.sys.system.callExternalApi(…)

Events

An API triggers an event once it answered. Its listeners tell the other services, in any language.

POST …/system-api/<service>/emit-event

Live updates

Any service pushes a message to the apps over WebSockets, whatever server they are connected to.

g.sys.system.emitEventWS(…)

See it live

A live diagram, the services it is made of, and the code to set it up.

Less to build and run

What microservices usually ask of a team, and what one installation of API Maker gives instead.

Run each serviceUsually: An image per service, and an orchestrator to run themWith API Maker: One process per server answers every account. Code runs in sandboxes made for you.
Route and secure callsUsually: An API gateway to set up and keep runningWith API Maker: One address. Caddy holds HTTPS, each account checks its tokens and groups.
Find the servicesUsually: Service discovery, DNS names per serviceWith API Maker: The API path of the account is the service.
Ship each serviceUsually: A pipeline per service, with its own deploy stepsWith API Maker: A Git repository and a deployment hook per account.
Guard each serviceUsually: Auth code in every serviceWith API Maker: API users, groups and sign-in providers in every account, no code.
Watch each serviceUsually: A log and metrics stack to set upWith API Maker: Logs per account, and Analytics of every account for the root user.

Need a message broker for heavy streams, like Kafka or RabbitMQ? The code of a service can use its client package, like any other package of its sandbox.

Splitting a backend into services?

Tell us about your services, your teams and your data. We will help you map them to admin accounts.