Feature flags

zapline follows "pay only for what you use": anything that pulls in a dependency sits behind a Cargo feature, and a feature you don't use adds no code to your binary and no work to a request.

[dependencies]
zapline = "0.1"                                             # the default features
zapline = { version = "0.1", features = ["ws", "fs"] }      # default features plus WebSockets and static files
zapline = { version = "0.1", features = ["full"] }          # everything
zapline = { version = "0.1", default-features = false, features = ["json", "macros"] }   # a minimal build

Or let the CLI edit Cargo.toml:

zapline add ws fs          # Added features: ws, fs
zapline add --list         # every feature, one line each; * marks the ones you have

When code uses something behind a feature that is off, zapline check and zapline test say which one to add: hint: enable the `ws` feature: zapline add ws (details).

Every feature

The default features are macros, json, query, form, openapi, validate, config and tracing. The full feature enables the defaults plus everything else.

With postgres or sqlite (and json), zapline::jobs adds durable jobs stored in the same database. With postgres or sqlite, App::admin adds an admin panel for every table. | full | | Every feature above except the database backends (pick postgres and/or sqlite) | all | |

openapi, validate, jwt and cookies turn on json as well, because their error bodies, schemas and session data are JSON.

Always included

Some modules have no feature flag because they add no dependencies:

Choosing features

• A typical JSON API: the defaults. Add jwt and compression when you need them.
• A web app with server-rendered pages: cookies (sessions, CSRF) and fs (assets), plus multipart for uploads.
• Realtime features: ws. Server-Sent Events need no feature.
• A slim microservice: default-features = false, features = ["json", "macros"] and add config or tracing if you use them. Types and macros behind a missing feature are not compiled, so the compiler tells you when you reach for one, and zapline check names the feature to add.
• Everything while exploring: full. The examples in the repository (cargo run -p zapline-examples --example openapi) are built with it.

Features are additive and unify across your dependency tree, so one crate enabling full enables it for all. The same applies to the macros: #[get(..)] works without openapi, it just doesn't document anything.

Put #[model] on request and response types and zapline is the only dependency you need: it derives Serialize, Deserialize, JsonSchema (with openapi) and Validate (with validate) through zapline's own re-exports. Writing the derives yourself still works; then add the crates they expand to:

serde = { version = "1", features = ["derive"] }                    # #[derive(Serialize, Deserialize)]
schemars = "1"                                                     # #[derive(JsonSchema)]
validator = { version = "0.21", features = ["derive"] }            # #[derive(Validate)]
tokio = { version = "1", features = ["macros", "rt"] }             # #[tokio::test], in [dev-dependencies]

cargo doc -p zapline --all-features --open builds the API reference with every module visible. The reference on docs.rs is built the same way.