Separate Sandboxes for Heavy APIs: Bun, Sandbox Count and Restarts

Intro

0:00 Separate sandboxes. Heavy APIs get sandboxes of their own : their runtime, their packages, their count, and restarts which drop no call. And code on the machine of the server gets the packages of Sandbox Settings.

Heavy APIs, the usual way

0:16 Heavy APIs usually mean a report which holds the sandboxes every other API waits for, a second service, built and deployed by hand, for another runtime, restarts at night for a library which leaks memory, and the calls they drop, and packages installed by hand on each server, for code which runs on the machine. With API Maker, a few lines of settings give an API sandboxes of its own, on the runtime and the version it names, restarted on a timer, without a failed call, and code on the machine finds the packages of Sandbox Settings.

0:51 In this video : a group of sandboxes for one API, a second API in the same group, what a save refuses, the sandbox count and x-am-run-in-sandbox, restarts which drop no call, and packages on the native process.

A group of its own

1:07 Every custom API of TypeScript runs in the sandboxes of TypeScript : one runtime, one list of packages, one sandbox count for all of them. Calm Home adds month-end reports : statistics over every order, heavy, and on Bun. They get a group of their own, reports : sandboxes of their own, with their own runtime and packages, so a long report never makes a cart wait. Custom API, the folder reports, Sales Report, Edit.

1:37 Under its access type, separateSandboxSettings : the group, reports, the runtime Bun, two sandboxes at most on each server, a new sandbox every hour, and the package simple-statistics, on top of the packages of Sandbox Settings. Update. The tree shows the group. Both reports are in the folder. Test API on Sales Report. In Header, x-am-meta, true, and Send. The orders of MySQL, in figures made by simple-statistics, on Bun.

2:09 And the meta says where the code ran : the group reports, the runtime bun, and the port of its sandbox. The code imports simple-statistics like any package of npm. It reads the totals of the orders of MySQL, and adds one to a count kept in g.shared : what the runner of a sandbox keeps between calls. The count tells which runner took a call. The code names no runtime : the group runs it on Bun.

A second API in the group

2:38 A second report, Top Products : Edit. Under its access type, it names the group, and nothing else. Update. Both reports share the group now : the same sandboxes, the same packages, and what one leaves in g.shared, the other finds. What if Top Products wants a count of its own? Under the group, four sandboxes. Update is refused, with the reason : Sales Report names two, and the APIs of a group share what its sandboxes are made of.

3:09 Name it in one of them, or the same in each. Close : nothing was saved.

What a save refuses

3:15 A save checks every key of the group, and says what to do. A runtime without a group : it would change nothing. A runtime of another language. A restart under sixty seconds. A count out of range, a version too old for its runtime, a package its registry does not take, a Dockerfile with CMD. A mistake fails on Update, never in the middle of a call.

Sandbox count and x-am-run-in-sandbox

3:41 Two sandboxes at most : the first call starts one, and the second starts beside it. Six calls in a row, with x-am-meta : they take turns, one sandbox, then the other, and each runner counts its own reports. Some code keeps state in memory : a connection a process initializer opened, a cache of its own. The header x-am-run-in-sandbox, one, sends every call to the oldest sandbox of the group : the same port every time, and the count climbs one by one.

4:12 Top Products, on the same sandbox, finds the count Sales Report left : one group, one g.shared. Two means one of the two oldest. Zero : any sandbox.

Restarts which drop no call

4:24 Some libraries hold on to memory. autoRestart gives a sandbox a lifetime. An hour, in production. Here, sixty seconds, the least it takes, so we can watch. Update. A call every second. Each sandbox gives its place after its own sixty seconds : the new one starts first, and the old one finishes what it runs, then goes. One sandbox at a time : the other keeps answering. Every call answered.

Packages on the native process

4:53 Product QR runs on the native process : on the machine of the server, for the lowest latency. Test API, Send : cannot find module qrcode. Until now, native code found only what was installed by hand. Operations, Sandbox Settings. Search npm for qrcode, pick it, Add, and Save. The menu, API Testing, Custom APIs, Product QR. Header, x-am-meta, true, and Send. The QR code of the label. runOnNativeProcess, true, and no port : no sandbox at all.

5:36 The first time the code runs, the packages are installed on the machine of the server, in a folder of their own, with the tool of each language : npm or Bun, pip, Composer, go, cargo, NuGet and Maven, in the versions the images get. Every account with the same packages shares that folder and its runner. And code of a group runs on the runtime of its group, with the packages of its group.

Good to know

6:01 Good to know. The hooks of the versions of an API run in the sandboxes of its group, in the same request. Accounts with the same settings share one image, built when the API is saved. The restart of Sandbox Settings is for the other sandboxes : a group has its own, or none. And the sandbox for debugging never restarts : you are looking at it. What a group is made of is said once, and checked on every save.

6:29 So code an AI assistant writes in another API of the group cannot quietly change the runtime of the reports : the save says why, in words, and what to do.

Recap

6:41 To sum up. A few lines give an API sandboxes of its own. The APIs of a group share its sandboxes, its packages and g.shared. A save refuses what cannot be made, with the reason. Calls take turns, or meet the oldest sandbox with x-am-run-in-sandbox. Restarts on a timer drop no call. Native code gets the packages of Sandbox Settings. Next : deploying a new version of API Maker. API Maker.

7:13 Build faster, spend smarter, deliver better.