GraphQL Schema Design
Design a GraphQL schema the way the current spec actually recommends — typed relationships, payload objects for mutations, the @oneOf directive for polymorphic input, and Relay-style cursor pagination — instead of translating REST endpoints one-for-one into fields.
Prerequisites: Node.js; basic familiarity with a GraphQL server library (examples use Apollo Server, but the schema design applies to any spec-compliant server); comfort with REST API concepts from the first project in this roadmap.
Version note: verified against the GraphQL Specification, September 2025 Edition (spec.graphql.org). That edition is the one to build against — it's where the @oneOf directive for polymorphic input types landed as a stable, built-in part of the spec (it was a community RFC/proposal in earlier editions, so tutorials written before September 2025 may still describe it as experimental or show it behind a plugin). Check your GraphQL server library's own release notes for when it added @oneOf support, since spec support and library support land at different times.
A REST API exposes a fixed set of endpoints, each returning a fixed shape. A GraphQL API exposes one endpoint and a graph of typed relationships, and the client decides — per request — exactly which fields it needs, following relationships as far as it wants in a single round trip.
The most common schema-design mistake for people coming from REST is modeling GraphQL types as one-to-one mirrors of REST resources with resolvers that just proxy the old endpoints. This project builds a small job-board schema (companies, job listings, applicants) designed graph-first instead.
Test what you just learned
Self-testing is one of the best ways to retain new skills. Unlock project quizzes to check your understanding.
Log in to unlock0 / 8 complete