Bosca / BML Read the docs

Data & auth

Every query runs as the viewer

All data access goes through the Bosca GraphQL API — a BML site never touches Bosca services directly. The server holds no auth library at all: the browser owns the token, and the server passes it through.

Typed operations

GraphQL files become Kotlin symbols

Operations live as .graphql files in the project and compile to typed Kotlin — a server script calls gql.execute(GetMyGroups, Unit) and gets a typed result. The client on ctx.gql is minted per request and bound to the caller's token, so every query runs with the viewer's own permissions.

  • Browser code calls the same API through a same-origin /graphql proxy — no CORS, no tokens configured in client code.
  • The proxy forwards the request body untouched and attaches the caller's resolved token; upstream status and JSON pass through as-is.
Home.kt — a page's data function
suspend fun home(ctx: RenderContext): HomePage {
    val gql = ctx.gql ?: return HomePage(emptyList(), signedIn = false)
    val groups = gql.execute(GetMyGroups, Unit)
        .profiles.current?.firstOrNull()
        ?.community?.groups.orEmpty()
    return HomePage(groups, signedIn = true)
}

Auth

The browser owns the token. The server forwards it.

The browser auth library owns the Bosca JWT; the server never mints, refreshes, or inspects tokens. For each request it resolves the token from the Authorization header when present, else from the auth SDK's cookie — page navigations send no header, so the cookie covers them.

  • <page … requireAuth> — a token-less caller never renders the page and is redirected to the configured sign-in route.
  • ctx.redirectTo — a server script can short-circuit any render into a redirect for finer-grained guards.
  • Invalid tokens are rejected by the data plane itself — the site doesn't re-implement validation.
reading the context
val id = ctx.params["id"].orEmpty()          // /group/{id}
val status = ctx.query["status"] ?: "all"    // ?status=answered
val theme = ctx.cookies["appearance"]        // read during SSR

The render context

One ctx for the whole request

Every render receives a RenderContext — in scope in server scripts and expressions.

ctx.gql

The token-bound GraphQL client for this request.

ctx.params

Matched route parameters — {id} from /group/{id}.

ctx.query

Query-string parameters, first value per name.

ctx.cookies

The request's cookies, readable during SSR.

ctx.token

The caller's resolved passthrough token, when any.

ctx.redirectTo

Short-circuit the render into a 302 redirect.

Keep exploring

More on BML

BML overview

What BML is, what makes it powerful, and how to use it.

The language

Pages, components, control flow, and scoped styles.

Live state & actions

Islands and interactivity without hand-written client code.

Tooling & deployment

The compiler, the IDE plugin, the dev loop, and one-process deploys.

Ready for the reference? Read the BML documentation