Apollo Federation Expose GraphJin as a database-backed Apollo Federation v2 subgraph. integrations guide integrations/federation integrations/federation.md

Apollo Federation

Expose GraphJin as a database-backed Apollo Federation v2 subgraph.

Enable federation

YAML
federation:
  enabled: true
  version: v2.5
  keys:
    users: ["email"]
  shareable:
    - Users.email
  inaccessible:
    - Users.encrypted_password
  tags:
    Users.full_name: ["pii"]

GraphJin can emit federation SDL, answer _service { sdl }, derive keys from primary keys, and apply configured @shareable, @inaccessible, and @tag annotations.

Database schemaPKs · relationsGraphJin SDL@key · @shareable_service { sdl }RoutersupergraphAppsUse GraphJin as the database-backed subgraph without hand-writing resolver glue.

Verified by TestBuildFederationSDL_Smoke core/federation_test.go:13
Verified by TestBuildFederationSDL_FieldDirectives core/federation_test.go:84

Federation queries

GraphQL
query {
  _service {
    sdl
  }
}

GraphJin dispatches _service and _entities internally, while regular database queries continue through the normal compiler path.

Verified by TestHandleFederationQuery_Service core/federation_dispatch_test.go:42
Verified by TestHandleFederationQuery_PassthroughForRegularQuery core/federation_dispatch_test.go:102

Why use it

Use federation when GraphJin should be the database-backed subgraph in a larger supergraph. You still get schema discovery, compiled database access, and GraphJin policy without writing resolver glue.

Remote tables and blocked tables are not exported as federated entities. Entity keys come from primary keys unless overridden, so tables without a stable key need explicit config before they belong in a supergraph.

Docs