Skip to content
This page View Markdown Open in ChatGPT Open in Claude

Upgrade from API Maker v3

API Maker v4 takes over a server of v3 where it is. The data of MongoDB and Redis stays, and so do the secrets, the license key and the addresses of your APIs. API Maker Launchpad does the move for you, and puts everything back as it was if a step fails.

In short

  1. In Launchpad, switch to Cloud and open V3 to V4 Migration.
  2. Pick your server : Launchpad checks it first and changes nothing.
  3. Choose where it goes, read the review, and press Migrate to API Maker v4.
Upgrade from API Maker 3 to 4: What Changes in Your Code, Branch and Database11 chapters and the transcript

Before you start

  • Try it on a copy first when the server is in production : a snapshot of the server, restored on a new one.
  • Read the breaking changes of v4.0.0 : a few queries match differently (null and $like), and a value starting with __: is no longer SQL.
  • One server at a time. Launchpad refuses a secondary server of v3, and a server whose Caddy spreads requests over other servers, and says so.

With API Maker Launchpad

Move an API Maker 3 Server to v4 in Place, with API Maker Launchpad11 chapters and the transcript

V3 to V4 Migration is in the sidebar of the Cloud mode of API Maker Launchpad.

V3 to V4 Migration : the checks of a server of API Maker v3
  1. V3 to V4 Migration, in Cloud mode.
  2. The checks : what runs on the server, and whether it can move.
  3. What API Maker v3 runs with today.
  1. Check Pick the server, or add it with its SSH login. Launchpad reads it without changing anything : the version of v3 and what runs it, MongoDB, Redis, Caddy, the license and the free disk. It says what prevents the move, and what to do.
  2. Destination Choose a project and an environment of Launchpad, new or empty, and the version of API Maker v4.
  3. Review Every step, the lines of .env that change, the Caddyfile before and after, and the checks at the end. Confirm by typing the name of the server.
  4. Watch it run The migration runs on the server itself : closing the app does not stop it, and the log follows live. Stop rolls back.

What the migration does, in order :

  1. Downloads API Maker v4 next to v3, and checks it, while v3 still serves.
  2. Saves what v3 runs with (.env, the Caddyfile, the services) in /root/backups/api_maker_v3_to_v4/.
  3. Stops v3, then saves the data of MongoDB while nothing writes to it.
  4. Keeps v3 in /root/projects/sava_api_maker_v3, and puts v4 in /root/projects/sava_api_maker with the license and the uploaded files of v3.
  5. Starts v4 with systemd, and points Caddy at it : the same addresses and certificates.
  6. Checks v4 the way your apps reach it : an API, the WebSockets and the admin panel.

When a step fails, or you press Stop, everything goes back as it was, the data of MongoDB included, and v3 starts again. The folder of v3 and the backup stay on the server until you delete them. Once it is done, the server is an environment of Launchpad, like any other : health, logs, terminals and upgrades.

What changes for your apps

  • WebSockets move to the port of the APIs : a client which reached :38245 directly connects to :38246. Behind Caddy, the addresses stay the same.
  • The admin panel is served by API Maker on port 4626, or through Caddy as before.
  • Tokens of your API users and of your users keep working : v4 reads the same secrets.
  • x-am-meta is answered to the admin panel only (its API Testing page). See x-am-meta.

What changes for your code

  • Packages. A sandbox of v4 has only the packages its account lists in Sandbox settings. The packages v3 had built in (lodash, moment…) are added to that list by the first start of v4.
  • Removed features. UI Maker, the API Maker store, third party APIs and notes are gone. A Git pull lists what it skipped.
  • Queries. null in find on SQL means IS NULL, $like on MongoDB is the pattern of SQL, and __: values are plain values : see the breaking changes.
  • Languages. Your TypeScript and JavaScript run as before. New code can be written in seven more languages.

After the move

  • Open the admin panel and run the security report : it reads the hooks and groups of v3 and says where rows are open.
  • Run your test cases, or call the APIs your apps use most.
  • Go through Before you go live.
  • Delete the folder of v3 and the backup once you are sure.