Showcase · SwarmCoder

What a real application on ZeroZ4J looks like.

A small demo is fine for showing how a framework works, but it does not tell you very much about whether you could build something serious with it. So this page showcases SwarmCoder, which is a multi-agent coding system that was built entirely on ZeroZ4J, and goes through its screens one by one to show which parts of ZeroZ Stack and ZeroZ DB are doing the work behind each of them.

Go through the screens swarmcoder.dev ↗

ApplicationSwarmCoder

Built onZeroZ Stack · ZeroZ DB

Languages usedJava only

Sourcegithub.com/swarmcoder ↗

The application in one table

Which parts of ZeroZ4J are used in SwarmCoder.

In a conventional stack an application like this would usually be written in Java, SQL, JSON and TypeScript, and the same data model (stories, requirements, runs, workers) would be described three times. In SwarmCoder every row below is plain Java, and the same objects go from the database to the screen without being mapped into anything else.

What you see

ZeroZ4J feature behind it

Project

Board, requirements list and graph

Java UI components, compiled to WebAssembly

ZeroZ Stack

Cards and run timeline updating as the workers run

LiveSync, server push over WebSocket

ZeroZ Stack

Accept and send back buttons

@RmiService calls with @BinaryModel objects

ZeroZ Stack

Trace from requirement to commit, and kept runs

Java object graph with transactions and indexes

ZeroZ DB

[01]

The whole UI is written in Java

ZeroZ Stack · UI components → WebAssembly

The board, the requirements list and the dependency graph are all built with the ZeroZ Stack component model, i.e. you create a component in Java (much like you would in Swing or Vaadin) and the client is compiled to WebAssembly and runs in the browser. There is no HTML template and no JavaScript in the project, so the board columns and the story cards are ordinary Java classes that the IDE can refactor and the compiler can check. The graph is the one screen where people would generally reach for a JavaScript library, and it is plain Java as well.

Board · empty projectOpen full size ↗

The five column board, with every column and card created from Java component code.

Requirements · listOpen full size ↗

The requirements list, where each row is rendered straight from the same requirement object that is stored on the server.

Requirements · graphOpen full size ↗

The dependency graph and its legend, drawn in the browser by Java code running as WebAssembly.

[02]

The screen updates without polling

ZeroZ Stack · LiveSync

While a build is running the workers change state many times a second, and in a conventional web application you would usually poll a REST endpoint for this or write a separate WebSocket protocol by hand. In SwarmCoder the run and its workers are LiveSync objects, so when the server changes one of them the updated object is pushed to every client that is watching it, over the same WebSocket that carries the method calls. The card that stops to ask a question, the workers writing code and the timeline all work this way, and there is no polling code anywhere in the client.

Board · build waiting for an answerOpen full size ↗

Board with a story waiting on a question

A build stopped to ask a question, and the card changed on the board as soon as the server changed the story.

Run · workers codingOpen full size ↗

Workers on a local model writing code, with each worker's activity pushed to the screen while it happens.

Run · timelineOpen full size ↗

Every worker attempt on one axis, including the failed ones (in red), which can be replayed afterwards.

[03]

The buttons on the board simply call a normal Java method on the server

ZeroZ Stack · @RmiService · @BinaryModel

When you accept a delivery or send it back with a note, the client simply calls a method on a Java service interface, and the server method receives exactly the object the client sent (in packed binary and not as JSON). So there is no controller, no DTO and no mapping code between the button and the server logic, and if you rename a field on the story class the compiler tells you about every place on both sides that has to change. Access to these methods is checked on the server with the usual @Secured and @RolesAllowed annotations.

Board · delivery waiting for reviewOpen full size ↗

Board with a delivery waiting for judgment

The build has finished and is waiting for your review, and the accept and send back buttons on the card each call one service method.

Board · deliveredOpen full size ↗

After the call the story object is updated on the server and the card moves to delivered.

[04]

The data model is simply a Java object graph

ZeroZ DB

SwarmCoder keeps a lot of data that is connected in many directions, e.g. a requirement points to its checks, a check to the test that proved it, the test to a commit, and the commit to the worker and the run that produced it. In a relational database that would essentially be a large number of join tables and an ORM to keep in step with the classes. In ZeroZ DB these are just Java references between objects, written in atomic transactions and looked up through maintained indexes, which is why you can follow the trace in either direction and why a finished run (failed attempts included) is kept exactly as it was.

Run · integrationOpen full size ↗

Every task with its workers, turns and tokens, read straight from the stored run.

Requirements · deliveredOpen full size ↗

The requirement now reads delivered, with its passing check and the story that delivered it, which is one walk along the object graph.

Run · finishedOpen full size ↗

The finished run, kept with its graph and timeline so that it can still be audited later.

What a real application on ZeroZ4J looks like.

Which parts of ZeroZ4J are used in SwarmCoder.

The whole UI is written in Java

The screen updates without polling

The buttons on the board simply call a normal Java method on the server

The data model is simply a Java object graph

One language.Zero impedance.

One language.
Zero impedance.