crates · rust · bevy

Supabase client forbevy_supa

A transport-agnostic Supabase / PostgREST client crate — native reqwest + rustls HTTP by default, a WASM fetch stub, and opt-in Bevy ECS integration, so JNI plugins, CLIs, and games share one client.

View source Usage Features

One client, extracted to share

Originally entity::client::supabase inside the kbve crate, extracted so JNI plugins, CLIs, and Bevy games can share one client without dragging diesel, axum, or tower along.

native (default) — reqwest + rustls HTTP transport.
wasm — browser fetch transport (stub, not yet implemented).
bevy — BevySupaPlugin + SupaClient Bevy Resource.

RustBevy crate

nativeDefault transport

http-clientCategories

MITLicense

Lean by default

No diesel, no tower, no Bevy in the default feature set; disable default features when only the type surface is needed (build scripts, codegen).

One client, two callers

The same SupaClient serves JNI MC plugins (no Bevy) and Bevy games (Resource) with no newtype wrapper.

Schema-aware RPC

rpc_schema sets Content-Profile / Accept-Profile headers to reach non-default PostgREST schemas.

JWT layering

with_jwt swaps just the Authorization header so service-role and per-user JWTs coexist.

main.rs

use bevy_supa::SupaClient;

let client = SupaClient::from_env()
    .ok_or("SUPABASE_URL + SUPABASE_SERVICE_ROLE_KEY missing")?;

let resp = client
    .rpc_schema(
        "service_verify_link",
        serde_json::json!({ "p_mc_uuid": "0123", "p_code": 123456 }),
        "mc",
    )
    .await?;

What is the bevy_supa crate?

bevy_supa is a transport-agnostic Supabase / PostgREST client. The default feature set ships the native HTTP transport (reqwest + rustls), Bevy integration is opt-in, and a WASM browser fetch transport is stubbed for later.

Can bevy_supa be used without Bevy?

Yes. The same SupaClient is used from JNI MC plugins with no Bevy and from Bevy games as a Resource when the bevy feature is enabled, so lean consumers like JNI cdylibs and CLIs stay slim.

How does bevy_supa target non-default PostgREST schemas?

SupaClient::rpc_schema sets the Content-Profile and Accept-Profile headers so PostgREST routes RPC calls to non-default schemas such as mc or tracker, and with_jwt swaps just the Authorization header so service-role and per-user JWTs coexist on one client.