summer-rs: a Spring Boot style application framework for Rust

An application framework, not a web framework

summer-rs is described as an application framework written in Rust, inspired by Java's Spring Boot, and the README calls it an ecosystem of reusable components with a plug-in system for integrating projects from the Rust community such as axum, sqlx and sea-orm. The distinction matters, because the words web framework and application framework imply different amounts of code. A web framework is the thing that routes requests, and a Spring style application framework is the thing that decides how the pieces of your service fit together, including the database access, the scheduled work and the configuration. The framework's stated ambition is to emphasise convention over configuration, and the comparison it draws with Spring Boot is that performance and memory usage are higher and lower respectively, letting you get rid of the JVM. That claim is the project's own and there are no numbers attached, so treat it as a design intent rather than a measurement. The crates are published on crates.io under the name `summer`, with a separate `summer` crate for the core, and the project publishes a Chinese translation of its README alongside the English one.

The plugin model, in a few lines of Rust

The core idea is visible in the smallest example. You build an `App`, add plugins to it, and run it.

```rust,no_run use summer::{auto_config, App}; use summer_sqlx::{ sqlx::{self, Row}, ConnectPool, SqlxPlugin }; use summer_web::{get, route}; use summer_web::{ error::Result, extractor::{Path, Component}, handler::TypeRouter, axum::response::IntoResponse, Router, WebConfigurator, WebPlugin, }; use anyhow::Context;

#[auto_config(WebConfigurator)] #[tokio::main] async fn main() { App::new() .add_plugin(SqlxPlugin) .add_plugin(WebPlugin) .run() .await } ```

Three things to notice. The plugins are unit structs, so adding one is a value rather than a configuration object. The `#[auto_config]` attribute is what ties the plugin to its configuration section, so the web plugin knows to look for the web settings in your toml file without you wiring it. And the `run` method is where the assembled application starts, which means the composition is the program. The workspace layout mirrors that design, with a `summer/` core crate, a `summer-macros/` crate for the attribute macros, and a directory per plugin.

Configuration from toml, and the macro that removes the trait boilerplate

The configuration story is the Spring part of the analogy. Applications and plugins are configured with toml, and each plugin declares a configuration struct that derives `Configurable`, with a `#[config_prefix]` attribute naming the section it reads, so a plugin named for the application prefix reads its values from the matching toml block. The component macro section shows the second half of the story, a `#[component]` attribute that registers a function as a component so that you do not have to implement the Plugin trait by hand, and the example shows a component function that takes its configuration through a `Config` extractor and returns a service that the app can then look up with `get_component`. The README's point is that the macro eliminates boilerplate, with no need to manually implement the Plugin trait. For a Rust audience this is the interesting part of the framework, because Rust's ownership model makes the Spring style of wiring awkward, and a derive macro that generates the registration is a reasonable answer to that.

The web plugin is axum with route attributes

The web layer is built on axum, and the README's plugin table says so plainly, listing `summer-web` as integrated with axum. What the framework adds is the attribute style for routes and the extractors. A handler is declared with `#[get("/")]` or with `#[route("/hello/{name}", method = "GET", method = "POST")]`, and the `route` form lets one function answer several methods. The extractors are where the framework earns its keep, with `Path` for a path parameter and `Component` for pulling a registered component out of the application state, which in the example is how the sqlx connection pool reaches a handler. The handler signature is otherwise ordinary Rust, returning something that implements `IntoResponse` or a `Result`, with `anyhow` for error context. A `TypeRouter` and `Router` are imported from the web crate, so the underlying axum types are visible to the application rather than hidden, which is the compromise most Rust web frameworks make and it keeps the door open to dropping down to axum when you need to.

Jobs, and the backends underneath them

The job plugin follows the same shape. A scheduled function is declared with an attribute, with `#[cron("1/10 * * * * *")]` for a cron expression, `#[fix_delay(5)]` for a fixed delay and `#[fix_rate(5)]` for a fixed rate, and the function receives its dependencies through the same `Component` extractor, so a cron job can query the database with the pool the SQL plugin registered. Underneath, the workspace depends on the apalis family of job crates, with the redis, AMQP, postgres, MySQL and SQLite backends, a workflow crate, a cron crate and a board crate, and there is a `summer-xxl-job` crate for the XXL-Job style scheduler. The `summer-apalis` crate appears as its own workspace member as well, which suggests the job engine is treated as a component of its own rather than a detail of the job plugin. If your scheduling needs are simple, the attributes are enough; if you need distributed job coordination across several services, the apalis backends are the part to look at.

The rest of the plug-in set, and what the workspace contains

The repository root is the catalogue. Alongside the core and the macros there are `summer-web` on axum, `summer-sqlx` and `summer-postgres` and `summer-sea-orm` for data access, `summer-job` for scheduling, `summer-redis`, `summer-stream`, `summer-mail` built on the lettre crate, `summer-opentelemetry` with a full OpenTelemetry 0.31 stack including the Jaeger propagator and the OTLP exporter, `summer-resilience` with the backoff crate, `summer-apalis`, `summer-nacos` for service discovery, `summer-xxl-job`, `summer-grpc` and `summer-test`. The workspace manifest is worth a look because it is the real dependency map, listing the apalis family, axum 0.8, the OpenTelemetry crates, lettre for mail and opendal for storage access, plus inventory and dashmap. The examples directory mirrors that, with getting-started, web, grpc, stream, data, job, integrations and di directories, which is the fastest way to see what the framework looks like in practice.

Where the project stands, and what the version number means

The workspace version is 0.7.1, and the release history is short and recent, with 0.3.0 in December 2024, 0.4.0 in May 2025 and 0.7.1 in May 2026, and the last push on 2026-09-28. The README's own weight claim is that the core code does not exceed 5,000 lines and that the release binary is small too, which is a defensible target for a framework whose whole pitch is that you add plugins rather than write plumbing. But the 0.x line is the honest signal, since the crate versions follow Cargo's convention where 0.7 to 0.8 is a breaking change, and a framework that rewrites its API between minor versions is a research project with a following rather than a foundation. The repository also carries a `Justfile` for task running, an `AGENTS.md` for assistants, a Chinese README, a changelog and a code of conduct, and the CI configuration is in `.cnb.yml`. For an evaluation, the useful next step is to run one of the examples rather than to read the framework source.

Editorial conclusion

Adopt summer-rs if you are writing a Rust service with several integrations and you want the Spring style of assembly, where the web layer, the database layer and the job scheduler are plugins added to an app and wired from configuration, rather than code you write by hand each time. Do not adopt it as a stable foundation yet, because the crates are on a 0.x line with the newest release 0.7.1 from 2026-05-25, and the public API of a 0.x framework is expected to move. Before you start, check which plugin crates you need exist and are published, since the workspace contains many plugin directories and the README's table is the list of what is actually supported, and read the `#[component]` macro section if you want the dependency injection style without writing the trait implementations. The licence is MIT, the crates publish under the name `summer`, and the last push was on 2026-09-28.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. summer-rs/summer-rs on GitHub