GraphQL

# GraphQL query: client specifies exactly the fields it wants
query {
  user(id: "123") {
    name
    email
    orders { id total }
  }
}

# A single request returns exactly this nested shape, no more, no less

Common follow-ups: What's the specific problem of 'over-fetching' and 'under-fetching' in REST that GraphQL is designed to solve?;Does GraphQL replace REST entirely, or are there scenarios where REST is still the better choice?

const { ApolloServer, gql } = require('apollo-server-express');

const typeDefs = gql`
  type User { id: ID!, name: String!, email: String! }
  type Query { user(id: ID!): User }
`;

const resolvers = {
  Query: { user: async (_, { id }) => db.users.findById(id) },
};

const server = new ApolloServer({ typeDefs, resolvers });
await server.start();
server.applyMiddleware({ app });

Common follow-ups: How does a resolver for a nested field (like a User's list of orders) differ from a top-level Query resolver?;What happens if a resolver's return value doesn't match the type declared in the schema?

const DataLoader = require('dataloader');

const userLoader = new DataLoader(async (userIds) => {
  const users = await db.users.find({ id: { $in: userIds } }); // single batched query
  return userIds.map(id => users.find(u => u.id === id));
});

// Each individual resolver call transparently benefits from batching
const resolvers = {
  Post: { author: (post) => userLoader.load(post.authorId) },
};

Common follow-ups: How does DataLoader's batching mechanism actually work using microtask timing to collect requests within a single tick?;What's the difference between DataLoader's batching and caching behaviors, and why does DataLoader typically need to be instantiated fresh per request?

type Query { posts: [Post!]! }
type Mutation { createPost(title: String!, body: String!): Post! }
type Subscription { postCreated: Post! }

# Client subscribing to real-time updates
subscription { postCreated { id title } }

Common follow-ups: What transport mechanism does a GraphQL Subscription typically use under the hood to push real-time data to clients?;How would you handle authorization differently for a Mutation compared to a read-only Query?

const server = new ApolloServer({
  typeDefs, resolvers,
  context: async ({ req }) => {
    const user = await verifyToken(req.headers.authorization);
    return { user };
  },
});

const resolvers = {
  Mutation: {
    deletePost: (_, { id }, context) => {
      if (!context.user || context.user.role !== 'admin') throw new GraphQLError('Forbidden');
      return db.posts.delete(id);
    },
  },
};

Common follow-ups: How would you implement a reusable authorization check that applies consistently across many resolvers without duplicating the check logic everywhere?;What's the tradeoff of field-level authorization (checking inside individual resolvers) versus a schema-level directive-based approach?

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production', // disabled in production
});

Common follow-ups: What's the tradeoff of disabling introspection in production if your own frontend team still needs schema information for their own tooling?;Are there ways to expose introspection securely, like only to authenticated internal users?

const depthLimit = require('graphql-depth-limit');
const { createComplexityLimitRule } = require('graphql-validation-complexity');

const server = new ApolloServer({
  typeDefs, resolvers,
  validationRules: [depthLimit(5), createComplexityLimitRule(1000)],
});

Common follow-ups: How do you determine an appropriate complexity budget without being so restrictive it blocks legitimate, genuinely complex client queries?;What's the relationship between this protection and the N+1 problem DataLoader addresses -- are they solving the same or different issues?

fragment UserSummary on User {
  id
  name
  avatarUrl
}

query GetPost {
  post(id: "1") { title, author { ...UserSummary } }
}

query GetComment {
  comment(id: "1") { text, author { ...UserSummary } }
}

Common follow-ups: How do GraphQL fragments relate to and support component-based frontend architectures, like colocating a fragment with a specific React component?;What's the difference between a named fragment and an inline fragment (used for querying fields specific to one type in a union or interface)?

# Products subgraph
type Product @key(fields: "id") { id: ID!, name: String! }

# Reviews subgraph, extending the Product type defined elsewhere
type Product @key(fields: "id") @extends {
  id: ID! @external
  reviews: [Review!]!
}

Common follow-ups: How does the federation gateway efficiently plan and execute a query that spans fields owned by multiple different subgraphs?;What's the operational complexity tradeoff of federation compared to a single monolithic GraphQL server for a smaller team?

const { GraphQLUpload } = require('graphql-upload');

const resolvers = {
  Upload: GraphQLUpload,
  Mutation: {
    uploadAvatar: async (_, { file }) => {
      const { createReadStream, filename } = await file;
      const stream = createReadStream();
      await pipeline(stream, fs.createWriteStream(`./uploads/${filename}`));
      return { filename };
    },
  },
};

Common follow-ups: Why can't a plain GraphQL query or mutation, sent as standard JSON, include binary file data directly?;What are the security considerations of accepting file uploads through this GraphQL mechanism, similar to the concerns discussed in File Uploads & Media Processing?