Felix Alm took the stage to share his experience with Electric Clojure and Rama, two technologies shaping the way his team at Multiply builds highly interactive, data-driven systems. His talk wasn’t about diving deep into implementation details but rather offering a look at how these tools change the developer experience and architectural approach.
Electric + Rama – a Clojure stack from the future?: A comprehensive overview
The old world vs. the new stack
Traditionally, web development follows a familiar pattern:
- A front-end client talks to
- An API layer (REST, GraphQL, etc.)
- Which interacts with a backend service and database.
But Felix realized something striking after joining Multiply:
I haven’t really thought about APIs in four months.
With Electric Clojure, frontend and backend code live together in the same file. The framework automatically syncs data between client and server over WebSockets. Developers write UI code and backend functions side by side — no separate API layer needed, no boilerplate REST endpoints.
For instance, a button click on the frontend can trigger a backend function seamlessly. Data flows between them as if it were all one system because, in a sense, it is.
Rama: The backend + database platform
After exploring Electric, Felix turned to Rama, a platform developed by Red Planet Labs. Rama isn’t just a database or a framework—it’s a full platform for event sourcing, stream processing, and state management at scale.
Key concepts in Rama include:
- Depot: Where events (like “customer created” or “order placed”) are logged.
- Topology: The dataflow logic that processes those events.
- PState (Partitioned State): Customizable, scalable data storage for the results.
Instead of one giant event log, Rama encourages splitting data into multiple depots per business domain. A clean separation of concerns makes reasoning about data flows easier while enabling massive scale and fault tolerance.
A dataflow approach to backend logic
Rama introduces a dataflow paradigm using a powerful DSL. Events flow through fragments — pieces of logic that can emit zero, one, or many outputs — into PStates.
PStates themselves can look like:
- Key-value stores (maps)
- Document databases (maps of maps)
- Or even graph-like structures
This flexibility lets teams model their domain precisely while benefiting from Rama’s built-in scalability, partitioning, and fault tolerance.
Putting it all together
At Multiply, Electric powers the real-time UI, while Rama handles the asynchronous backend workflows involving AI agents and distributed systems.
Some takeaways Felix emphasized:
- Velocity: No API boilerplate means faster iteration.
- Scalability: Rama handles partitioning, event replay, and distributed execution out of the box.
- Simplicity: Complex event sourcing pipelines become just a few lines of DSL code.
As Felix put it, you end up with “data streaming from browser to server to database and back — without custom glue code”.
Q&A highlights
- Is Rama open source?
Not yet. It’s in private beta, but there’s a free tier for small projects. - Why Electric over alternatives like HTMX?
Electric’s real-time syncing and tight frontend-backend integration make it well-suited for highly interactive apps, though other tools could work for simpler use cases. - Can you replay old events in Rama?
Yes — events can be reprocessed by attaching new topologies as needed.
Final thoughts
Felix described both Electric and Rama as tools that “get out of your way” while enabling things that used to require massive amounts of boilerplate. Together, they offer a glimpse into a future where real-time UIs, distributed event processing, and scalable dataflows feel natural — even simple — to build.
As the session wrapped up, one thing was clear: this stack might not just be from the future — it might be building it.