API Maker

The backend engine for the AI era

Chapters

What you will learn

  • Where code marked runOnNativeProcess finds its language
  • Install a version of Node.js on every server from Sandbox Settings
  • Run a native custom API on that version, chosen in one click
  • A second language: Python from python-build-standalone
  • What stays apart for each admin, and what two admins share
  • Remove a version: the server deletes it once nobody uses it
In the docsSandbox settings : native languages
Transcript820 words · click a time to play from there

Intro

Native languages. Code on the native process needs its language on the servers. Now each admin installs the versions it needs from Sandbox Settings, on every server, from the official builds.

Languages on servers, the usual way

Code on the machine of the server usually means a session on every server, to install the language by hand, one version for every team, so one upgrade breaks another team's code, downloads from wherever a blog pointed, without a checksum, and a new server which has none of it. With API Maker, you pick a version in the panel, every server installs it from its publisher, checked, each admin runs the version it chose, and a new server installs it by itself.

In this video : where native code finds its language, a version of Node.js installed on every server, native code running on it, a second language, what stays apart for each admin, and a version removed.

Where native code finds its language

Most code runs in sandboxes, and the image of a sandbox has its runtime. Code marked run on native process runs on the server itself : for the lowest latency, or for a program of the server. It needs its language there. Until now, that was whatever the PATH of the server found, installed by hand. Now each admin installs the versions it needs, in a folder of API Maker, on every server.

A version of Node.js

Sandbox Settings, from the dashboard. Under the version of TypeScript, a new part : Native process, for code marked run on native process only. That code runs on the server's own Node.js today, the one its PATH finds, said for each server. The releases come from nodejs.org as it publishes them, with their tags, their sizes, and a star on the one recommended. What it takes, and the checksum which is checked.

Install. Every server downloads it, and says ready once its program said the version which was downloaded. Each server reads the release from its publisher, downloads the build of its own system and processor, checks it against the checksum the publisher gives, unpacks it into a folder of its own, in the native languages folder next to API Maker, and runs it once : only a program which says the right version becomes ready.

Nothing else on the server changes : not its PATH, not the Node.js it had.

Native code on that version

API Testing. Custom APIs, Runtime Check : a custom API on the native process, which says what runs it. Send : the server's own Node.js. Operations, Sandbox Settings. Choose the version you installed. APIs and Logic, API Testing, Custom APIs, Runtime Check, and Send again : the same code, on the version of the account, installed by Sandbox Settings.

Each admin, its own versions

Every admin chooses for its own account. Calm Home runs one version of Node.js, and another admin of the same server keeps the version it chose, or the server's own. Two admins who install the same version share its files on the disk, and removing it from one list never takes it from the other. The admins who chose the same version share its runner.

A second language

A second language : Python. Its native code runs on the server's own Python today. The builds of python-build-standalone, the ones uv installs, with pip. Install, ready, and chosen. The list of languages says what the native code of each one runs on. Every language of API Maker : Node.js and Bun, Python, PHP, .NET, Go, Rust, Java and Kotlin. Each from its publisher, checked with the checksum it gives.

On Linux, macOS and Windows, on Intel and on ARM. Kotlin runs on the Java version you chose. And the packages of Sandbox Settings are installed with the version chosen.

A version removed

A version you no longer need. The native code runs on it. Remove : the code goes back to the server's own Node.js, and the versions of the other admins stay. Yes. The server deletes the build once no admin wants it, and no runner runs on it.

Good to know

Good to know. A failed install says why, on the server where it failed, and Try again asks every server again. A new server installs what the admins want when it starts. A request which reaches a server while it installs waits for it, within the time of the request. And the choices are saved with the admin user : with a history, and through git. Official builds, checked, and the same version on every server.

Your code names no version : the settings of the account do. So code an AI assistant writes runs on the version you chose.

Recap

To sum up. Native code needs its language on the servers. Sandbox Settings installs the versions you need, on every server. From each publisher, checked, and run once. Your native code runs on the version you choose. Each admin has its own versions, and nothing else changes. Next : deploying a new version of API Maker. API Maker. Build faster, spend smarter, deliver better.