Expand description
§blazingly-http
Adapter-neutral HTTP dispatch for the Blazingly framework: a compiled router, typed request and response values, synchronous middleware hooks, and an in-memory test client over the executable operation graph.
This crate sits between blazingly-executor, which compiles the operation
graph, and the byte-level adapters (blazingly-native today). It defines
Request and Response, the borrowed HttpRequestView that adapters
implement over their receive buffers, the HttpMiddleware interception
points, HttpApp for serving paths, and TestApp for in-memory dispatch. It
is an ordinary library and is usable standalone: given an ExecutableApp, it
routes and dispatches requests entirely in memory with no socket, no async
runtime, and no facade — the example below is a complete program. The
blazingly facade re-exports these types and adds the macro layer that
derives operations from handler signatures; without it, operations are built
explicitly, as shown.
[dependencies]
blazingly-core = "0.2"
blazingly-executor = "0.2"
blazingly-http = "0.2"
futures-lite = "2"use blazingly_core::{HttpMethod, OperationDescriptor, ResponseDescriptor, TypeDescriptor};
use blazingly_executor::{ExecutableApp, ExecutableOperation, ExecutionOutcome, OperationFuture};
use blazingly_http::{Request, TestApp};
fn health() -> ExecutableOperation {
let descriptor = OperationDescriptor::new(
HttpMethod::Get,
"/health",
"app.health",
"Reports liveness",
None,
vec![ResponseDescriptor::success(
200,
Some(TypeDescriptor::new("Health")),
)],
)
.expect("operation id is valid");
ExecutableOperation::typed(descriptor, |_input| {
Ok(Box::pin(async {
ExecutionOutcome::Success {
status: 200,
headers: Vec::new(),
body: Some(b"\"ok\"".to_vec()),
background: Vec::new(),
}
}) as OperationFuture)
})
}
fn main() {
let app = ExecutableApp::new([health()]).expect("operation graph compiles");
let test = TestApp::new(&app);
let response = futures_lite::future::block_on(test.call(Request::get("/health")));
assert_eq!(response.status(), 200);
assert_eq!(response.body(), b"\"ok\"");
}futures-lite only blocks on the returned future; dispatch is a plain
Future, so any executor works.
§Links
- API documentation
- Getting started — the framework picture
- Repository
Structs§
- Background
Tasks - A request-scoped handle for scheduling work that runs after the response.
- Connection
Info - Normalized transport values readable by a handler extractor.
- HttpApp
- An owned, runtime-neutral HTTP application compiled from the operation graph.
- Http
Error - The failure an application error handler is asked to rewrite.
- Http
Request Context - Mutable, request-local context shared by runtime-neutral HTTP middleware.
- Middleware
Scope - Selects the requests one registered middleware layer observes.
- Request
- A runtime-neutral HTTP request.
- Response
- A runtime-neutral HTTP response.
- Route
Match - A compiled route match with its direct operation slot and path captures.
- Router
- A runtime-neutral router compiled once from the operation graph.
- TestApp
- An in-memory borrowed HTTP adapter over the shared executable operation graph.
Enums§
- Collect
Body Error - Failure while deliberately buffering an HTTP response stream.
- Http
Error Source - Where a failure response produced by dispatch came from.
- Route
Error - A router miss that distinguishes an unknown path from a wrong method.
Constants§
- DEFAULT_
MAX_ BODY_ BYTES - EMIT_
VARIABLE - Environment variable that turns server construction into a print-and-exit
introspection run. See
HttpApp::newfor the contract.
Traits§
- Http
Error Handler - Application-level rewriting of failure responses.
- Http
Middleware - Synchronous middleware interception points shared by every HTTP adapter.
- Http
Request View - Borrowed request access used by in-memory and native HTTP adapters.