Overview of Web Frameworks in Clojure

Learn how Ring, Reitit, Compojure, Luminus, and Pedestal fit together so you can choose a Clojure web stack by role and constraints instead of by brand names alone.

Clojure web stack: The layered ecosystem built around Ring handlers, routing libraries, middleware, starter stacks, and alternative request pipelines such as Pedestal interceptors.

Choosing a Clojure web framework gets easier once you stop treating every name as a full replacement for every other name. Most of the ecosystem is compositional. Ring is the foundation. Routers such as Reitit and Compojure sit on top. Starter stacks such as Luminus package a set of choices together. Pedestal is the main alternative execution model when interceptors and its service pipeline are a better fit than plain Ring middleware.

Start with Roles, Not Brand Names

The strongest first question is not “Which framework wins?” It is “Which layer am I actually choosing?”

  • Ring gives you the request-response contract.
  • Reitit and Compojure mainly solve routing.
  • Luminus gives you a preassembled project stack.
  • Pedestal gives you an interceptor-oriented service model.

Once you separate those roles, the landscape feels much less confusing.

It also becomes easier to review existing systems honestly. Many teams are not really choosing “a framework.” They are choosing:

  • an HTTP contract
  • a routing model
  • a server runtime
  • a starter stack or assembly story
  • an operational model the team can actually support

Ring Is the Common Foundation

Ring remains the most important mental model in Clojure web work because it keeps HTTP close to ordinary data transformation. A handler consumes a request map and returns a response map. Middleware wraps handlers. That model is small, stable, and easy to compose.

Even teams that later adopt richer routing or alternative service layers still benefit from understanding Ring well, because so many libraries either implement Ring directly or feel similar to it.

1(defn health-handler [_]
2  {:status 200
3   :headers {"content-type" "text/plain; charset=utf-8"}
4   :body "ok"})

If your service is relatively conventional and your team values transparency over framework ceremony, Ring is the right starting point.

Reitit and Compojure Solve Different Routing Problems

Compojure is the classic concise routing DSL. It still works well when you want small, readable route declarations and do not need heavy data-driven routing features.

Reitit is usually the stronger choice when you want richer routing metadata, parameter coercion, swagger or OpenAPI integration, or a routing layer that behaves more like structured data than macro-driven declarations.

That difference matters in larger APIs.

  • choose Compojure when a light route DSL is enough
  • choose Reitit when the route tree needs metadata, coercion, or tooling integration

For many greenfield APIs, Ring plus Reitit is a practical default.

That does not make Compojure obsolete. It makes the trade-off clearer: concise routing syntax versus richer route metadata and tooling.

Luminus Is a Starter Stack, Not a Mandatory Framework

Luminus is best understood as a productivity stack rather than as a fundamentally different execution model. It brings together common choices such as routing, templating, persistence, and authentication so a team can move faster without assembling everything by hand.

That is useful when:

  • the team wants a full application starter
  • the application needs conventional CRUD and auth quickly
  • consistency matters more than fine-grained stack selection

It is less useful when you want a very small service, highly customized architecture, or a carefully trimmed dependency surface.

Pedestal Changes the Pipeline Shape

Pedestal is the main ecosystem choice that genuinely changes the request-processing model. Instead of Ring middleware, it emphasizes interceptors, which can participate in both the inbound and outbound parts of the request lifecycle with more explicit control over flow.

That makes Pedestal attractive when:

  • you want richer lifecycle control
  • the team likes interceptor-style processing
  • you need a service layer that can carry more structured context through the pipeline

It also means the mental model is different enough that teams should choose it intentionally rather than casually.

Pedestal is strongest when the team wants request processing to be expressed as a pipeline of explicit steps with richer context flow than plain Ring middleware usually provides. It is weaker if the team mostly wants a simple handler-and-router stack and has no need for interceptor-style composition.

Framework Choice Does Not Replace Architecture

A useful reminder for new teams is that no stack choice decides:

  • service boundaries
  • persistence boundaries
  • caching strategy
  • state ownership
  • deployment shape
  • observability discipline

Framework selection matters, but it does not rescue unclear architecture. A clean Ring application with modest libraries often beats a theoretically richer stack wrapped around fuzzy boundaries.

Think About How the Stack Will Evolve

Most real Clojure web systems do not pick every layer at once forever. They evolve.

A common path looks like:

  1. start with Ring and a straightforward router
  2. add middleware and validation discipline
  3. improve API tooling or route metadata as the surface grows
  4. split operational concerns such as async work, workers, and deployment later

That is one reason minimal clear foundations age well. They let the application grow by adding explicit layers instead of rewriting from framework fashion to framework fashion.

A Useful Rule of Thumb

If you are building:

  • a straightforward API or service: start with Ring + Reitit
  • a smaller or older route-centric service: Ring + Compojure is still reasonable
  • a full application where you want an assembled stack: consider Luminus
  • an interceptor-oriented service platform: consider Pedestal

There is no prize for choosing the most flexible stack if your team mostly needs clear routes and simple handlers.

Common Selection Mistakes

Treating Routing as Architecture

Picking Reitit or Compojure does not decide your domain design, persistence boundaries, or deployment strategy. It only decides part of the HTTP layer.

Choosing a Starter Stack for a Tiny Service

A full application stack can be helpful, but it can also add more moving parts than a small service actually needs.

Avoiding Pedestal Just Because It Feels Different

Pedestal is not automatically overkill. It is simply a different model. If interceptors match how the team wants to express request processing, it may be the right choice.

Optimizing for Fashion Instead of Team Fit

The wrong familiar stack is usually better than the theoretically best stack nobody on the team can operate confidently.

Practical Selection Questions

Before choosing, ask:

  • do we want a minimal handler-and-router stack or a full assembled application stack?
  • do we need routing metadata, coercion, and tooling integration?
  • will the team be more productive with middleware or interceptors?
  • are we optimizing for fast delivery, long-term flexibility, or operational clarity?
  • how much framework surface can the team realistically learn and maintain?
  • does the runtime model match the kind of service we are actually building?

Those questions are usually more useful than reading feature checklists in isolation.

Ready to Test Your Knowledge?

Loading quiz…
Revised on Thursday, April 23, 2026