WebSockets Without a Realtime Server: Push Live Data from Your APIs

Intro

0:00 Live data for your apps : a save, a status, pushed the moment it happens, by the same server as your APIs. In this video, the app of Kabir, a customer of Calm Home : one WebSocket, his orders live, a status pushed from code, and a subscription refused.

Live data, the usual way

0:19 Live data usually means a separate realtime server, publish and subscribe plumbing between it and your APIs, and its own way to authenticate a socket. With API Maker, the API port takes WebSockets too, a save, a call or an event from your code can be pushed, with the same tokens and groups as the APIs. In this video : what clients may subscribe to, a rule for each subscription, a save pushed live, a status pushed from code, and how far it scales.

What clients may subscribe to

0:51 APIs and Logic, WebSockets : nothing is pushed unless it is declared here. The saves of the orders of MySQL are there, with the provider customer_login : a client needs a token of it. Add New, a custom event, orders/status. Auth Providers : customer_login. And the code which decides whether a client may subscribe : the customer behind the person token must be the customer asked for. Save.

A save pushed live

1:21 Now the app of Kabir : a page with one WebSocket. It connects to the API port with the token of the shop app and the person token of Kabir : connected. It subscribes to the saves of his orders, customer five, and to orders/status for him : both accepted. The shop saves an order for Kabir, here from a terminal. Two hundred and one : saved. And on the screen of Kabir, at once : the new order, with only the three fields his app asked for : the order number, the status and the total.

A status pushed from code

1:56 Now a status, pushed from code. The custom API Announce Status finds the order, and tells its customer with g.sys.system.emitEventWS. The shop calls it : one client told. The app of Kabir : shipped, pushed from code. And when the app asks for the status of another customer, the code says no : a customer follows their own orders only.

How far it scales

2:22 How far does it go? The docs measured API Maker on Linode servers : tens of thousands of clients on one vCPU and one gigabyte, hundreds of thousands on two vCPUs, close to a million on four, and millions on eight vCPUs and thirty two gigabytes. A few kilobytes per client : memory ends first, never the CPU. And a notification reaches its client in about a millisecond, at the median.

Good to know

2:52 The saves of any table, the calls of a custom or a system API, and your own events can all be pushed. A subscription selects its fields and filters on the values of the answer. A client whose token expires is told and closed, and groups decide what it may subscribe to. And many servers share one Redis : a save on one server reaches a client held by another.

Built on standards

3:17 Nothing is pushed unless it is declared. The same tokens and groups as every API, and code which decides for each subscription. So a live feature written by an AI assistant can not send one customer the data of another.

Recap

3:32 To sum up. WebSockets on the API port. Saves and events from code, pushed live. A rule for each subscription. Millions of clients, measured. Next : schedulers, jobs without a cron server. API Maker. Build faster, spend smarter, deliver better.