GraphQL Federation as a Thin Semantic Layer

The semantic layer you might already be running

If your application stack is already GraphQL-shaped, you have a thin semantic layer in plain sight: the federated supergraph. Each domain team owns a subgraph (users, orders, inventory); a router (Apollo Router, GraphQL Mesh, Hasura DDN) composes them into a single typed supergraph that consumers query.

Why this counts as a semantic layer

• One unified vocabulary — Customer.lifetimeValue is defined once, in the subgraph that owns it, and surfaces across every product.
• Typed contracts — the schema is the contract. Schema checks (Apollo's rover schema check, Hasura's schema-changes) catch breaking changes in CI.
• Domain ownership — subgraphs map cleanly to bounded contexts (cross-link to the software-architecture-ddd track), so the team that owns the entity owns the schema.

Where it stops short

GraphQL federation is transactional / OLTP-shaped, not analytical. It is great at 'fetch these typed objects and their relations'; it is not an OLAP engine — it cannot compute revenue BY country, week over a TB-scale fact table efficiently.

The pragmatic stack

• Use GraphQL federation as the application-side semantic layer for typed product data and cross-domain fetches.
• Use dbt SL / Cube / LookML for the analytical semantic layer over the warehouse.
• Glue them together at the BFF (Backend-for-Frontend) so consumers see one logical API.

A federated GraphQL supergraph is the shopping-mall directory: each store keeps its own inventory and staff, but a single map at the entrance presents one searchable index of every shop. Visitors don't learn each store's internal layout. The mall directory is wonderful for 'where do I find a lampshade?', and useless for 'compute the rolling 28-day revenue per square metre across all stores' — that's the warehouse and BI layer's job.