I've been able to build an experimental version of Live, typed queries on real Postgres.
It started from a question I had: can a Java-shop get the "subscribe, and the UI updates when the data changes" experience of Firebase or InstantDB without giving up a real relational database and without using ORM.
Haven't experienced flow state in a while, since CC became my default IDE :)
I built my version of a meta harness that guides claude and codex in a code => review loop. I typically brainstorm a task and dispatch it. The actual coding and review by the LLMs is done in a sandboxed Incus container. A WIP https://github.com/standardapplied/sail
As everyone knows, in a typical Java app, data moves through multiple stations just to get out the door: JDBC, ResultSet, POJO mapping, Hibernate sessions, Jackson serialization, etc. Every station allocates memory. Every station loses type info the next one has to rediscover.
I wanted to see what happens if we strip the pipeline down to its absolute minimum. The result is an experimental library I’m calling Monolith. It uses Java FFM (Foreign Function & Memory API) to talk directly to Postgres.
The core premise: a single Java record is the source of truth. You write a record, and an annotation processor generates the Postgres schema, a binary reader, a builder, and a matching TypeScript reader at compile time. No reflection. While building it, I also added support for live queries. One can subscribe to a query, and Monolith watches the Postgres write-ahead log (WAL) to know when underlying rows change, automatically re-running the query and pushing the new result.
To be clear: this is v0.1. It is highly experimental. Postgres is still a server over a socket. This might be a terrible idea but it was a great excuse to push Java FFM.
We tend to obsess over abstractions, frameworks, and standards, which is a good thing. But we already have BDD and TDD, and now, with english as the new high-level programming language, it is easier than ever to build. Focusing on other critical problem spaces like context/memory is more useful at this point. If the whole purpose of this is token compression, I don't see myself using it.