Liking cljdoc? Tell your friends :D

Roadmap

Wagoe is at 1.0.0-rc-1. This page is the public view of what is built, what is left before a stable 1.0.0, and what we intend to build after it.

It is a statement of intent, not a delivery commitment. Dates are deliberately absent — the ordering is the useful part.

Where we are

Thirty-one libraries are published on Clojars under com.wagoe, versioned in lockstep. The framework is feature-complete for the applications it targets; the remaining work before 1.0.0 is about trust rather than capability.

Table 1. Built and shipping
AreaWhat exists

Architecture

Functional Core / Imperative Shell throughout, with ports.clj protocols per module, enforced in CI by dedicated boundary, dependency-direction and hexagonal-layering gates

Code generation

Scaffolder for modules, fields and endpoints — interactive, flag-driven, or from a natural-language description

Web + admin

Reitit routing, HTMX + Hiccup UI, and an auto-CRUD admin interface generated from entity configuration

Identity

Authentication, JWT, MFA, sessions, and role-based authorization

Data

next.jdbc with PostgreSQL, H2 and SQLite; migrations; multi-tenancy by schema-per-tenant; full-text search

Async

Background jobs over Redis or a durable database-backed queue, with transactional enqueue; an event bus; WebSocket real-time messaging

Integrations

Payments (Mollie, Stripe, Mock), file storage (local, S3, GCS), email over SMTP, SMS/WhatsApp, IMAP, geocoding, push notifications (FCM, APNs)

Domain libraries

Workflow state machines, reports with PDF/Excel/DOCX export, calendar with RRULE recurrence and iCal, audience segmentation

Observability

Interceptor-based metrics, logging and error reporting, with Prometheus, OTLP and Datadog providers, plus distributed tracing spans

Internationalisation

Marker-based i18n with translation catalogues and locale chains; the admin UI is fully translatable

Tooling

wagoe CLI, a Babashka task suite (config doctor, setup wizard, migrations, i18n scanning, deploy), framework-aware AI helpers, and an MCP server for editor agents

Shipped in 1.0

Work that earlier drafts of this page listed as future. It is done, in main, and covered by tests.

Scaling out

Wagoe scales vertically through configuration, and the ports.clj seam is what makes scaling out tractable: swap an in-process adapter for a distributed one without touching business logic.

  • Generic remote-port adapter + RPC envelope — any module protocol can be implemented by a call to another process, built from the protocol’s own signatures, with correlation-id, tenant and auth riding the headers the interceptor pipeline already uses.

  • Service launch modejava -jar wagoe.jar service <module>… boots a named subset of modules as its own service, with its RPC endpoint on its own port.

  • Event-bus port + adapterwagoe-events, with a Redis Streams adapter (at-least-once, consumer groups) and an in-process one.

  • Break allowlisted dependency cycles — no module pair is blocked from separation by a cycle any more; bb check:deps now fails on any cycle at all.

  • Realtime Redis pub/sub adapter, graceful connection draining, default rate-limit wiring, jobs hardening and a deploy topology reference — the replica-safety work.

What is still missing for full functional decomposition — service discovery and the data-ownership decision — and the readiness matrix behind all of the above, are in Sizing & Scaling. That page is the source of truth for what scales; this one does not restate it.

Stability surface

The stability policy defines what is public, what is internal, how deprecations work, and which libraries are incubating rather than covered by the 1.0 promise.

The road to 1.0.0

1.0.0 means the API is one we are willing to be held to. What is left is about earning that, not adding surface.

1. The release gate — done

One JDK baseline, one provider vocabulary, jars that cannot ship stale classes, a version scheme in which a pre-release can never outrank a release, library tiers, and a frozen changelog carrying an explicit decision on every open breaking change. 1.0.0 ships no surprise.

2. A release candidate that is actually exercised

1.0.0-rc-1 is published first and smoke-tested from Clojars on a clean machine, rather than tagged on the strength of a green build. Only then 1.0.0.

3. First-run experience

The bulk of this has landed: install.sh with prerequisite detection, a wagoe new scaffold that produces a project which boots, a setup wizard needing no external services, automatic migrations, seed data, a production build path, and a CI smoke test that walks install → new project → serving app inside a bare container and asserts on HTTP rather than exit codes.

What remains is deliberate QA: the same path exercised across an environment matrix and by people who did not write it. This gates the public launch rather than the tag — a framework gets one first impression.

After 1.0.0

Grouped by the release they would ship in. 1.x work keeps the stability promise; 2.0 is where the things that cannot are collected.

1.1 — Enterprise login and correctness

  • OIDC / OAuth2 login (authorization code + PKCE)

  • A transactional outbox, so publishing an event is decoupled from the database transaction that produced it

  • A decision on multi-tenancy: PostgreSQL-only, or row-level tenancy as an adapter capability

  • Dependency vulnerability scanning and coverage actually running in CI

1.2 — Contracts

  • A database-adapter port with a conformance suite across all four adapters

  • A PSP conformance sweep, finishing the Mollie adapter

  • wagoe-external sharing the retry and circuit breaker of the RPC client

  • Finishing the metrics and error-reporting stubs, or removing them and correcting the documentation

1.3 — Batteries

  • Recurring and cron-scheduled jobs, with an idempotency-key store

  • Server-driven per-field form validation from Malli schemas

  • A #secret config reader with pluggable backends (env, file, vault, SOPS)

  • OpenAPI 3.1 instead of Swagger 2.0

  • A realtime-to-UI bridge: SSE plus out-of-band fragment responses

  • A test kit for consumer applications — test system, test tenant, Ring client, job draining

  • Outbound webhooks: signed, retried, per-tenant

  • GDPR data export per user and per tenant, and retention policies

Ongoing through 1.x

  • Component gaps in the shared UI library — dialog, combobox, toast region, sortable tables

  • wagoe upgrade: a codemod for deprecated config keys, requires and functions. This ships before the first 2.0 pre-release, not after it

  • A showcase application and a migration guide for people arriving from Kit or Luminus

2.0

  • Removing the deprecated provider aliases and the duplicate choices that 1.x deprecates — one HTTP client, one config layer, one CSS system, one mail library

  • Virtual threads for request handling and the jobs worker pool

  • A decision on the front-end stack

How this page is maintained

This roadmap is the only one. It is reviewed alongside each release; work is tracked on GitHub, and the shipped detail of every release is in CHANGELOG.md.

A CI gate (bb check:roadmap) fails the build if this page plans something Sizing & Scaling already marks as shipped, which is how the three-way contradiction it replaced went unnoticed for months.

If something here matters to you, saying so is the most effective way to move it up the list.

See also

  • Stability & Versioning — what 1.0.0 will actually promise

  • Getting Started — try the release candidate

  • Sizing & Scaling — what scales today

Can you improve this documentation? These fine people already did:
Thijs Creemers & thijscreemers
Edit on GitHub

cljdoc builds & hosts documentation for Clojure/Script libraries

Keyboard shortcuts
Ctrl+kJump to recent docs
Move to previous article
Move to next article
Ctrl+/Jump to the search field
× close