Services / Real-time backend

Real-time backend development with Node.js and WebSocket

I build the part of a product that users never see but feel at once: the server. Node.js and WebSocket when things must update live. Vanilla PHP when the lightest server is the right answer. Python for tools that collect and process data.

Book the free consult All services

Real-time rooms and arenas

Some products need many people sharing one live state. Convoy is my example: a group travel app with a live map, group chat, SOS alert and QR invites. Each crew is a real-time room. Positions are kept in server memory only, and the crew needs no sign-up.

The same ideas sit under the Plaazaa games: a real-time Arena server that runs rooms and keeps seats across dropped connections, plus browser SDK modules on top. The demo describes this layer in detail on the demo page. For the platform view, see community platforms and SDKs.

The demo uses made-up crews and test stacks, with scripted fake GPS. It shows the engineering, not real users.

APIs documented the way I document real ones

An API is a product too. I write clear contracts, one consistent error format, safe retries and signed webhooks, and I describe it all in an OpenAPI file so other developers can read it.

To see the style, open the Sample Orders API. It is a fictional bakery orders API with an OpenAPI 3.1 file you can download, 16 endpoints, parameter tables and examples. It is a sample only: no running service, no real data.

Vanilla PHP when it is the lightest

Vanilla PHP means no framework overhead and a light server. For an API or a page that must answer quickly, that is often the best tool. Plaazaa is tuned for fast responses, and I run a directory of 7,800+ Thai local-government offices on PHP 8.2 with a database and scheduled jobs. I do not claim speed figures here, because they depend on your server and your data.

Python where it fits

For collectors, automation and terminal tools I use Python. One example is a real-time terminal app built with Textual. It processes live market data every 5 seconds and writes price bars and option chains to Parquet and DuckDB. It is my own daily-use tool, not investment advice. The same pattern suits data collectors, scheduled jobs and internal tools.

Operations basics

Good backends are boring to run. These are the habits I apply in every project:

A written rollback plan before a risky release, and a backup before the change.
Tests for the parts that must not break.
Secrets kept out of code and out of repositories.
Sign-in and SSO set up once, then reused.
Docs for the next developer, so you are not locked to me.

Your accounts, hosting and domain stay with you. I can also help set up cloud from zero.

Questions

When should I use WebSocket instead of a normal API?

When the server needs to push updates to people as they happen, such as a live map, chat or a shared game room. For plain pages and forms, a normal request-and-response API is simpler.

Why vanilla PHP in this decade?

When the job is a small API or a page that must respond fast, plain PHP means no framework overhead and a light server. If the job needs live rooms, I use Node.js.

Do you document the APIs you build?

Yes. Clear contracts, predictable errors and an OpenAPI file. The Sample Orders API on this site shows the style.

Can you take over a backend someone else wrote?

Yes. I start by reading it and writing down what I find, then we agree a scope before I change anything.

Start with the free consult

Describe the system. I reply with a one-page recommendation: the stack, the approach, the risks and what to build first.

Book the free consult