Files
Phoebe Goldman 5c04860649 Implement HTTP handlers / webhooks in Rust modules (#4636)
# Description of Changes

Adds support to Rust modules and the SpacetimeDB host for defining HTTP
handlers and registering them to routes.

## User-facing API

In a Rust module, users can annotate functions with the new macro
`#[spacetimedb::http::handler]`. A function annotated this way must
accept exactly two arguments, of types `&mut
spacetimedb::http::HandlerContext` and `spacetimedb::http::Request`
(which is a type alias for `http::Request<spacetimedb::http::Body>`. It
must also return `spacetimedb::http::Response` (which is a type alias
for `http::Response<spacetimedb::http::Body>`).

Once the user has defined an HTTP handler, they can register it to a
route by annotating a function with `#[spacetimedb::http::router]`. Such
a function must take no arguments and return a
`spacetimedb::http::Router`. (The original design put this annotation on
a `static` variable rather than a function, but that turned out to be
undesirable because it required that constructing a `Router` be
`const`.) `Router` exposes various methods for registering handlers to
routes.

All of a database's user-defined routes are exposed under
`/v1/database/:name_or_identity/route/{*path}`.

## Example

See [the new
smoketest](https://github.com/clockworklabs/SpacetimeDB/blob/phoebe/http-handlers-webhooks/crates/smoketests/tests/smoketests/http_routes.rs)
for a more exhaustive example.

A simpler example, which stores arbitrary byte data in a table via a
`POST` request, returns an ID, and then retrieves that same data via a
`GET` request with a query parameter:

```rust
#[spacetimedb::table(accessor = data)]
struct Data {
    #[primary_key]
    #[auto_inc]
    id: u64,
    body: Vec<u8>,
}

#[spacetimedb::http::handler]
fn insert(ctx: &mut HandlerContext, request: Request) -> Response {
    let body: Vec<u8> = request.into_body().into_bytes().into();
    let id = ctx.with_tx(|tx| tx.db.data().insert(Data { id: 0, body: body.clone() }).id);
    Response::new(Body::from_bytes(format!("{id}")))
}

#[spacetimedb::http::handler]
fn retrieve(ctx: &mut HandlerContext, request: Request) -> Response {
    let id = request
        .uri()
        .query()
        .and_then(|query| query.strip_prefix("id="))
        .and_then(|id| u64::from_str(id).ok())
        .unwrap();
    let body = ctx.with_tx(|tx| tx.db.data().id().find(id).map(|data| data.body));
    if let Some(body) = body {
        Response::new(Body::from_bytes(body))
    } else {
        Response::builder().status(404).body(Body::empty()).unwrap()
    }
}

#[spacetimedb::http::router]
fn router() -> Router {
    Router::new().post("/insert", insert).get("/retrieve", retrieve)
}
```

## Design and implementation notes

- As mentioned above, the router is registered via a function, not a
`static` or `const` item. This is because `static` or `const`
initializers must be `const`, and it turns out to be a pain to make all
of the `Router` constructors be `const fn`s.
- The `#[handler]` macro clobbers the original function name with a
`const` variable of type `HttpHandler`. This is unfortunate, but AFAICT
necessary, 'cause we need to pass the string identifier for the handler
to the `Router`, not the function pointer, and Rust allows no (stable
and reliable) way to get a unique string identifier out of a function
item/value, nor to attach data or implement traits for function
items/values. The alternative(s) would involve changing the signature of
the `Router` methods to have uglier and more complex callsites, e.g.
like `.get("/retrieve", retrieve::handler())`, `.get("/retrieve",
handler!(retrieve))` or `.get::<retrieve>("/retrieve")`. I believe that
registering handlers will be much more common than calling their
functions, so I've chosen to make it so that registering them gets the
convenient syntax, even though the inability to call them directly will
be somewhat surprising.
- I haven't wired up energy handling or timing metrics for handler
execution to anywhere. Procedures are still in the same boat.
- HTTP requests to user-defined routes bypass the usual SpacetimeDB auth
middleware, meaning that the host does not validate (or inspect in any
way) `Authorization` headers in requests before invoking the
user-defined handler. This is required to allow arbitrary
user-programmable handling of `Authorization` headers, including those
in formations which SpacetimeDB would reject. As a result of this,
`HandlerContext` doesn't expose a `sender` or `sender_connection_id`.
- HTTP route paths may consist only of a very restrictive set of
characters. I've chosen this set to keep our options open in the future
to add additional syntax to routes, like for registering wildcard
segments and path parameters:
  - ASCII digits.
  - ASCII letters.
  - `-_~/`.
- The internal data structure that represents a `Router` is currently a
`Vec<Route>`, meaning that resolving a request to a route is
`O(num_routes)`. Registering a route checks against each previous route
for uniqueness, meaning that constructing a router is `O(num_routes ^
2)`. There are TODO comments to use a trie, but I think this can wait,
as I expect most databases to register few routes.
- Commit 999a7c317 contains a fix to a mostly-unrelated bug where a few
bindings introduced by the SATS derive macros were unhygienic and not in
a reserved namespace, leading to name conflicts. I discovered this
'cause I tried writing an HTTP handler named `index` to serve the
index/root of a website and it broke.

## Still TODO

- [x] Resolve various TODO comments in the diff.
- [x] Documentation.
- [x] C# bindings support.
- [x] C++ bindings support.
- [x] V8 host support.
- [x] TypeScript bindings support.

# API and ABI breaking changes

New APIs, currently flagged as `unstable`, which will eventually need
stability guarantees. No (intentional) breaking changes, or changes to
existing APIs at all.

# Expected complexity level and risk

3? Changes to our HTTP routing to support the user-defined routes.

# Testing

<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->

- [x] New smoketest of the behavior!
- [x] I dunno, maybe try hosting a simple webpage and see how it works?
- [x] Build a test app with Stripe integration.
  - @aasoni did this.

---------

Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
2026-05-29 16:06:15 +00:00

135 lines
4.0 KiB
C++

#ifndef REDUCER_CONTEXT_H
#define REDUCER_CONTEXT_H
#include <spacetimedb/bsatn/types.h> // For Identity, ConnectionId
#include <spacetimedb/bsatn/timestamp.h> // For Timestamp
#include <spacetimedb/bsatn/uuid.h> // For Uuid
#include <spacetimedb/random.h> // For StdbRng
#include <spacetimedb/auth_ctx.h> // For AuthCtx
#include <optional>
#include <array>
#include <memory>
// Include database for DatabaseContext
#include <spacetimedb/database.h>
namespace SpacetimeDB {
// Enhanced ReducerContext with database access - matches Rust pattern
struct ReducerContext {
private:
Identity sender_;
public:
// Core fields - sender is exposed via sender() like Rust, other fields remain directly accessible
std::optional<ConnectionId> connection_id;
Timestamp timestamp;
// Database context with name-based access
DatabaseContext db;
private:
// Authentication context with lazy JWT loading (private like in Rust)
AuthCtx sender_auth_;
// Lazily initialized RNG (similar to Rust's OnceCell pattern)
// Using shared_ptr to make ReducerContext copyable
mutable std::shared_ptr<StdbRng> rng_instance;
// Monotonic counter for UUID v7 generation (31 bits, wraps around)
mutable uint32_t counter_uuid_ = 0;
public:
Identity sender() const {
return sender_;
}
// Returns the authorization information for the caller of this reducer
const AuthCtx& sender_auth() const {
return sender_auth_;
}
// Get the random number generator for this reducer call
// Lazily initialized and seeded with the timestamp
StdbRng& rng() const {
if (!rng_instance) {
rng_instance = std::make_unique<StdbRng>(timestamp);
}
return *rng_instance;
}
Identity database_identity() const {
std::array<uint8_t, 32> buffer;
::identity(buffer.data());
return Identity(buffer);
}
[[deprecated("Use database_identity() instead.")]]
Identity identity() const {
return database_identity();
}
/**
* Generate a new random UUID v4.
*
* Creates a random UUID using the reducer's deterministic RNG.
*
* Example:
* @code
* SPACETIMEDB_REDUCER(void, create_session, ReducerContext ctx) {
* Uuid session_id = ctx.new_uuid_v4();
* ctx.db[sessions].insert(Session{session_id});
* }
* @endcode
*
* @return A new UUID v4
*/
Uuid new_uuid_v4() const {
// Get 16 random bytes from the context RNG
std::array<uint8_t, 16> random_bytes;
rng().fill_bytes(random_bytes.data(), 16);
// Generate UUID v4
return Uuid::from_random_bytes_v4(random_bytes);
}
/**
* Generate a new UUID v7.
*
* Creates a time-ordered UUID with the reducer's timestamp, a monotonic counter,
* and random bytes from the reducer's deterministic RNG.
*
* Example:
* @code
* SPACETIMEDB_REDUCER(void, create_user, ReducerContext ctx, std::string name) {
* Uuid user_id = ctx.new_uuid_v7();
* ctx.db[users].insert(User{user_id, name});
* }
* @endcode
*
* @return A new UUID v7
*/
Uuid new_uuid_v7() const {
// Get 4 random bytes from the context RNG
std::array<uint8_t, 4> random_bytes;
rng().fill_bytes(random_bytes.data(), 4);
// Generate UUID v7 with timestamp and counter
return Uuid::from_counter_v7(counter_uuid_, timestamp, random_bytes);
}
// Constructors
ReducerContext() : sender_auth_(AuthCtx::internal()) {}
ReducerContext(Identity s, std::optional<ConnectionId> cid, Timestamp ts)
: sender_(s), connection_id(cid), timestamp(ts),
sender_auth_(AuthCtx::from_connection_id_opt(cid, s)) {}
ReducerContext(Identity s, std::optional<ConnectionId> cid, Timestamp ts, AuthCtx auth)
: sender_(s), connection_id(cid), timestamp(ts), sender_auth_(std::move(auth)) {}
};
} // namespace SpacetimeDB
#endif // REDUCER_CONTEXT_H