Shipping a Triplestore App With No Server
On paper Emic is a database application with four moving parts. In production it's a folder of static files. Here's how the backend got compiled away.
The Stack I Thought I Needed
On paper, Emic is a database application. There’s a triplestore (Apache Jena Fuseki) holding the ontologies as RDF, a Python layer computing graph analytics, a FastAPI server exposing it all, and a React front end on top. Four moving parts, at least one of them a running server with a database behind it. That’s a thing you host, monitor, and pay for.
Then I noticed what the application actually does for a visitor.
Nobody using Emic writes anything. Every page is a read.
Read-Only Changes Everything
A visitor opens a concept, looks at its neighbors, reads a field note, walks the map. None of that modifies state. The ontologies don’t change between deploys. The analytics don’t change between deploys. The field notes are written once, ahead of time. If every answer the server could give is fixed at build time, then the server doesn’t need to exist at request time. It can be a folder of files.
If the inputs are frozen and every response is a read, your backend is a build step wearing a server costume.
Precompute Everything
So that’s what Emic does. A build step walks every ontology and writes the answers out as static JSON: one bundle per concept, the precomputed analytics, a search index, the territory layout for the map. The front end never calls a live API. A small adapter intercepts what would have been /api/... requests and resolves them against those files instead. The components don’t know the difference. They think they’re talking to a server.
The triplestore and the Python and the FastAPI server don’t disappear. They move. They become an offline content pipeline that runs on my machine when I add or reseed an ontology, not infrastructure that has to be up when someone visits.
Fuseki and FastAPI didn’t get deleted. They got demoted from runtime to build tool.
What That Buys
The output is a pile of static files, which is the easiest thing in the world to host. It goes to Cloudflare the same way this blog does: push to a repo, a build runs, the files go live. No server to keep alive, no database to back up, no API keys sitting in production, nothing to rotate or patch. Hosting cost is zero, and it stays zero whether ten people visit or ten thousand.
There’s a real constraint hiding in here, and it’s a feature: the public site is read-only by design. No ratings written, no live model calls. The things that genuinely need a server, like collecting feedback or generating a note on demand, live behind a separate mode I run locally and never ship to the public site.
The cheapest, most reliable backend is the one you compiled away.
The Takeaway
The Takeaway: Emic looks like a database app, but for a visitor it’s all reads over data that’s fixed at build time. Precompute the answers, ship them as static files, and the triplestore becomes a build tool instead of a server. The whole thing hosts for $0 and deploys like a blog post.