API Maker

The backend engine for the AI era

Chapters

What you will learn

  • The Deploy API Maker page: from npm or from a bundle
  • What each server does, its hash checked
  • The way back: a watchdog
  • A whole cluster, and what stays in place
  • Servers that refuse what they can not do safely
  • Launchpad from your laptop, and the license of each server
In the docsDeploy API Maker
Transcript951 words · click a time to play from there

Intro

A new version of API Maker, on every server of the installation, from one page of the panel. In this video : how Deploy API Maker installs it, checks it, and goes back on its own when the new version does not start.

An upgrade, the usual way

Upgrading a backend usually means SSH into each server, one after the other, a build copied by hand, for the right processor, a restart, and the hope that it starts, and when it does not, the way back, by hand too, while the APIs are down. With API Maker, one page upgrades every server at once, each one takes the package of its own machine, its hash checked, the new program is checked before it is used, and a watchdog goes back to the old version on its own.

In this video : the page, two ways to deploy, what each server does, the way back, a whole cluster, what stays in place, servers that refuse, and the license of each server.

The page

Deploy API Maker is under Operations. The header shows the version this server runs, under the name of the page. On the left, upload a bundle : the file of a version. On the right, pick a version published on npm, and deploy it.

Two ways to deploy

From npm, every server downloads the package of its own machine, x64 or arm64, and checks its SHA 512 before anything is installed : a cluster of both kinds is upgraded in one go. An upload goes to one server, which hands it to the others through the Redis of the installation, in pieces of four megabytes, kept for an hour. Each server checks its SHA 256, and a server of another machine refuses it.

What each server does

On each server, the same steps. The package is downloaded, or received. It is unpacked next to the running version, in releases. Its program is checked : built for this machine, and it starts. The current link moves to it, all at once, and the three newest versions are kept. Then systemd starts the new version.

The way back

And if it does not start? A watchdog runs outside of API Maker, as a unit of systemd of its own. It restarts API Maker, then asks its port every two seconds, seventy five times. An answer, and its work is done. No answer within two and a half minutes : current goes back to the version which ran before, and that one is started again.

A whole cluster

The page asks one server. That server asks every other one at once, and the page shows a card for each server, with the progress of each step. Each server restarts on its own, once it answered. The server which took the request restarts last, so the page gets the result of every server. Then the page waits until every server answers on the new version, and reloads.

What stays in place

The env file, the license, the uploads and the logs are outside of the versions : nothing has to be put aside. A server which fails keeps the version it runs, and the page says why. A deployment waits up to twenty minutes for its servers. And when the WebSocket of the page is down, the deployment goes on, and the page reports the result when it ends.

Servers that refuse

A server refuses what it can not do safely. This demo server runs on a Mac : asked for the latest version, it refuses at the first step, before anything is downloaded, written or restarted. A server not installed by the installer, or not run by systemd, refuses too : run the installer again, with the version, as video sixty one shows. And versions of the Node.js edition can not run on version four.

API Maker itself

This page upgrades API Maker itself. Your APIs, schemas and websites go to every server with a pull from git, and the settings of every server are on Deployment Settings. Servers without API Maker yet? One command of the installer sets each one up, in video sixty one. Or the Cloud mode of API Maker Launchpad installs it from your laptop, over SSH : the same packages of npm, checked the same way, every change reviewed server by server first.

Then the deployment runs in stages, with the output of every server, from one server to a cluster. Video fifty eight shows it.

The license of each server

Licenses, under Operations, shows the license of every server of the installation, a card for each. This server has no key yet : invalid, no license key is set on this server, and the fix, Set Key. The key is written to the license file of this server only, and every process of it checks the license again at once. Here, the key of API Maker Launchpad : local, for this computer and private networks.

A card says one of four things : pending, until the first check, then valid, invalid, or local. The checks never refuse a request : a license which is not valid shows here, and as a warning in the header. Each server asks the license server a minute or two after it starts, every day around noon, India time, and at once after a new key. When it can not be reached, the last answer stays.

A key is bound to the MAC address of its machine : Reset MAC moves it.

Recap

To sum up. One page upgrades every server. Each one takes the package of its machine, its hash checked. The program is checked before it is used. A watchdog goes back on its own. A server refuses what it can not do safely. And Licenses shows the license of every server. Next : SSR websites, first steps. API Maker. Build faster, spend smarter, deliver better.