3 posts tagged with "beam"

Curling IO's admin panel should feel instant when a club manager is working through a season setup. Toggle a setting, save a discount, move between product sections: the page should respond without a full reload.

Version 2 works, but every form submission reloads the page. Version 3's admin is a single Lustre server component running on the BEAM. One WebSocket connection, one long-lived Erlang process per session. Every interaction goes over that WebSocket and comes back as a DOM patch. The page never reloads, and there's no client-side JavaScript framework.

While writing the previous post about our per-test SQLite databases, I was describing how each test gets its own in-memory database, no shared connections, no shared state. And I thought: wait, if nothing is shared, can we just run them all at the same time?

Turns out we could, and our server test suite went from ~4 seconds to ~0.85 seconds for around 800 tests. Zero code changes to the tests themselves. One 25-line Erlang module.

When a curler asks for a login email, the page should respond immediately. They shouldn't wait on Postmark, and we shouldn't run a separate worker fleet just to send a message in the background.

Curling IO Version 3 runs background jobs inside the same BEAM runtime as the web app. No Redis. No separate worker. No additional deployment. The queue is durable because pending jobs live in SQLite, not memory.