Live in ~15 seconds
A git pull is the whole deployment: no build, no pipeline, no restart. It applies completely or not at all.
The framework for AI era
The framework for AI era
Level 2 · GrowArchitecture 04 of 13
DEV, QA, UAT and PROD, each with its own servers and data. Git pull is the deployment.
Developers build on API Maker Local Run or on DEV and push to Git. Each environment pulls its branch and is live in about 15 seconds, with its own secrets and data. PROD pulls once, and every PROD server follows.
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/environmentsLiveBuild on your computer, push to Git. Developers build APIs in API Maker Local Run or on the DEV server, and push their work to Git for review.
The same steps as the diagram, in more detail.
Each developer has an account of their own, with their own secrets, and builds APIs in API Maker Local Run on their computer or on the DEV server. The definitions of the APIs are committed and pushed to your Git repository from the admin panel, and reviewed in a pull request like any other code.
On the DEV server, a git pull of the DEV branch applies the changes. API Maker writes them in a MongoDB transaction, so a pull is applied completely or not at all, and the new version is live in about 15 seconds. No build, no pipeline, no restart.
Promoting a change is a merge from one branch to the next, reviewed in a pull request, then a pull on the server of that environment. QA runs the inbuilt tests of API Maker, UAT lets the business try the change, each on a server and data of its own.
Production runs on several servers. The pull happens once, on any of them: the new definitions land in the shared MongoDB, and a cluster event through Redis makes every worker of every server reload them and recycle their sandboxes. Users do not see two versions for long.
Connection strings, keys and settings that differ between environments live in secrets, one set per environment and one per developer. The same instance "shop" reads the DEV database on DEV and the production database on PROD. Values that travel in Git are encrypted with passDBEncryptDecrypt, the same on every environment of the project.
Every item in API Maker has its Git history: compare two versions side by side and revert in one click, then commit and pull. Rolling back is the same 15-second pull as a deployment, on every server of the environment at once.
A git pull is the whole deployment: no build, no pipeline, no restart. It applies completely or not at all.
Every change goes through a pull request on GitHub, GitLab, Bitbucket or your own Git server before it moves on.
Secrets point the same APIs to the DEV, QA, UAT or production databases. Developers have secrets of their own.
Pull on one PROD server and a cluster event through Redis reloads every worker of every other server.
Every item has its Git history. Revert, commit and pull: the previous version is back in seconds.
API Maker Local Run brings the whole platform to the computer of each developer, on macOS, Windows or Linux.
Plain VPS from any provider, or your own servers, with Ubuntu 22.04 LTS. Sizes are a starting point: measure and adjust.
Runs
Ports
DEV can also be API Maker Local Run on each computer.
Runs
Ports
Runs
Ports
See the Load-balanced API servers architecture for the details of PROD.
# 1. In the admin panel of DEV or Local Run: commit and pushfeature/checkout → pull request → DEV # then Pull on the DEV server# 2. Promote, one merge and one pull per environmentDEV → pull request → QA # then Pull on the QA serverQA → pull request → UAT # then Pull on the UAT serverUAT → pull request → PROD # then Pull on any PROD serveram__passJWT="***" # tokens valid on every serveram__passDBEncryptDecrypt="***" # decrypts values stored in Git and MongoDBam__passCommunication="***" # admin panel ↔ backendKeep these three values identical everywhere, or encrypted values in Git cannot be read.
No. A git pull on the server of an environment is the deployment. API Maker applies the pulled changes in a MongoDB transaction, so they are applied completely or not at all, and the new version is live in about 15 seconds. A deployment hook URL can also trigger the pull, for example from a webhook of your Git host.
Connection strings live in secrets. Each environment has its own secrets, and each developer too, so the same instance and the same APIs read the DEV database on DEV and the production database on PROD.
Any Git repository: GitHub, GitLab, Bitbucket or your own Git server. The admin panel pulls, pushes, compares and reverts through it, and one repository can serve several admin users.