JSON works for structured data, but it falls short with large language models. TOON offers a cleaner approach that models parse more reliably and developers find easier to work with.

The Problem with JSON

When you ask an LLM to return structured data in JSON, you face parsing issues. Models sometimes add extra text, forget closing braces, or generate invalid syntax. These errors break your application flow and require extra validation layers.

What TOON Does Differently

TOON uses a format that aligns with how language models generate text. It's more forgiving of minor formatting issues and easier for models to produce correctly. The syntax is simpler than JSON, which means fewer parsing errors and less code to handle edge cases.

Real-World Benefits

Developers report fewer parsing failures when using TOON. Models generate valid TOON more consistently than JSON. The format also reads better in prompts, making it easier to explain what you want from the model.

When to Use TOON

Use TOON when you need structured output from LLMs but want to avoid JSON parsing headaches. It works well for configuration generation, data extraction, and any scenario where you need reliable structured responses from language models.

TOON represents a practical shift toward formats that match how language models actually work, rather than forcing them into formats designed for machines.

DBOS Transact helps Java developers build long-running workflows that stay reliable, even when servers restart or fail. It uses Postgres to track progress so your code continues from where it stopped.

Why Durable Workflows Matter

Many backend tasks run for hours or wait for external signals. Without durability, you risk losing work when the process dies. You then add your own retry logic, state tracking, and cleanup code, which can grow complex fast. DBOS simplifies this by handling durability for you.

What DBOS Transact Does

DBOS stores workflow steps in Postgres as checkpoints. When your program restarts, DBOS resumes the workflow from the last saved step. You write normal Java code, and DBOS makes it reliable without extra infrastructure.

How It Works in Code

You mark a workflow method and split the logic into steps:

public class ExampleWorkflow {
    
    @Workflow
    public void runWorkflow() {
        DBOS.runStep(() -> stepOne(), "stepOne");
        DBOS.runStep(() -> stepTwo(), "stepTwo");
    }
    
    private void stepOne() {
        System.out.println("Step one done");
    }
    
    private void stepTwo() {
        System.out.println("Step two done");
    }
}

Each step is saved after completion. If the app dies after running step one, DBOS resumes at step two when the app comes back.

Strengths and Tradeoffs

DBOS works well when you want reliability without adding a full workflow engine. It depends on Postgres, so you need good database operations. It also gives you more control, which means you manage how workflows evolve over time.

When to Use DBOS Transact

DBOS fits tasks like payment pipelines, long-running AI agents, scheduled jobs, and any work that must survive system failures. It keeps the code clean and avoids extra infrastructure.

DBOS Transact offers a direct way to make Java workflows durable, without the weight of a full orchestrator.