# ❌ Team split by technical layer — not by domain
# This is the most common Federation anti-pattern

# Frontend team's subgraph:
type Query {
  getUser(id: ID!): UserView    # Read model
  getUserFeed: [FeedItem!]!
}

# Backend team's subgraph:
type Mutation {
  createUser(input: CreateUserInput!): UserMutationResult!
  updateUser(id: ID!, input: UpdateUserInput!): UserMutationResult!
}

# Problem: both teams still need to coordinate on the User type definition,
# @key field selection, and any cross-type references. You have distributed
# system overhead with none of the domain independence.

# ✅ Users subgraph — owned entirely by the Identity team
# They own: users table, auth service, user profile logic
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
  createdAt: DateTime!
}

type Query {
  user(id: ID!): User
  viewer: User
}

type Mutation {
  createUser(input: CreateUserInput!): CreateUserPayload!
  updateProfile(input: UpdateProfileInput!): UpdateProfilePayload!
}

# ✅ Orders subgraph — owned entirely by the Commerce team
# They own: orders table, payment processing, fulfillment logic
type Order @key(fields: "id") {
  id: ID!
  total: Money!
  status: OrderStatus!
  items: [OrderItem!]!
  user: User!   # Reference to User entity — resolved via @key, not a DB join
}

# The Orders subgraph extends the User type to add orders traversal
# WITHOUT the Identity team's involvement
extend type User @key(fields: "id") {
  id: ID! @external
  orders(first: Int, after: String): OrderConnection!
}

# Client sends this query to the Router:
query GetUserOrders {
  user(id: "u1") {
    name        # ← resolved by Users subgraph
    orders {    # ← resolved by Orders subgraph
      total
      status
    }
  }
}

// ✅ The Orders subgraph resolver for the User entity reference
const resolvers = {
  User: {
    // This is the entity reference resolver — called with { id: "u1" }
    // when the Router performs an entity lookup for User.orders
    __resolveReference: async (reference: { id: string }, ctx: GraphQLContext) => {
      // Minimal — the Orders subgraph only needs to resolve orders for this user
      // It does NOT need the full User object from the Users subgraph
      return { id: reference.id };
    },
    orders: async (user: { id: string }, args, ctx) => {
      return ctx.ordersLoader.load(user.id);
    },
  },
};

// ❌ Apollo Gateway — Node.js, maintenance mode, do not use for new projects
import { ApolloGateway } from '@apollo/gateway';
import { ApolloServer } from '@apollo/server';

const gateway = new ApolloGateway({
  supergraphSdl: /* ... */,
});
const server = new ApolloServer({ gateway });

# ✅ Apollo Router — Rust, production-ready, supports all Federation 2.x features
# router.yaml
supergraph:
  path: /graphql
  listen: 0.0.0.0:4000

plugins:
  # Native OpenTelemetry — zero Node.js plugin required
  telemetry:
    tracing:
      otlp:
        endpoint: http://jaeger:4317

# In every subgraph's CI pipeline, before deployment:

# 1. Validate the schema change does not break any registered client operations
rover subgraph check my-graph@production \
  --name orders \
  --schema ./schema.graphql

# 2. Publish the subgraph schema to the registry (runs after deployment)
rover subgraph publish my-graph@production \
  --name orders \
  --schema ./schema.graphql \
  --routing-url https://orders.internal/graphql

# 3. Lint the subgraph schema for Federation best practices
rover subgraph lint ./schema.graphql \
  --profile production

✅ Composition-time catch (caught before Router receives traffic):
  - @key field missing from entity type
  - @external field referenced without @override or @provides
  - Type conflict between subgraphs (field type mismatch)

❌ Runtime error (NOT caught by composition):
  - __resolveReference returning null for a valid entity key
  - DataLoader returning keys in the wrong order
  - Subgraph returning a partial entity that causes null propagation

// Orders subgraph is down — the Router returns:
{
  "data": {
    "user": {
      "name": "Alice",
      "orders": null    ← null, not an empty array — the resolver failed
    }
  },
  "errors": [
    {
      "message": "Failed to fetch from subgraph 'orders'",
      "path": ["user", "orders"],
      "extensions": {
        "code": "DOWNSTREAM_SERVICE_ERROR",
        "serviceName": "orders"
      }
    }
  ]
}

// ✅ Client-side partial data handling (Apollo Client)
const { data, errors } = useQuery(GET_USER_ORDERS);

// data.user.name may be present even when data.user.orders is null
// Check each field independently, not just the top-level data object
const ordersError = errors?.find(e => e.path?.includes('orders'));
if (ordersError) {
  return <OrdersUnavailableState message="Orders service is temporarily unavailable." />;
}