2020-02-26
2864
#graphql
Leonardo Losoviz
14569
Feb 26, 2020 ⋅ 10 min read

Code-first vs. schema-first development in GraphQL

Leonardo Losoviz Freelance developer and writer, with an ongoing quest to integrate innovative paradigms into existing PHP frameworks, and unify all of them into a single mental model.

Recent posts:

RAG vs. Fine Tuning, A LogRocket Article

Fine-tuning vs. RAG: Which AI strategy fits your frontend project?

Compare fine-tuning vs. RAG to design faster, smarter, and more responsive AI-powered frontend experiences.

Ikeh Akinyemi
Jun 16, 2025 ⋅ 8 min read
7 Common CSS Navigation Menu Mistakes And How To Fix Them

7 common CSS navigation menu mistakes and how to fix them

Navigation menu errors are common, even for seasoned developers. Learn seven common navigation menu errors and how to solve them using CSS.

Temitope Oyedele
Jun 13, 2025 ⋅ 6 min read
Comparing the top 5 React toast libraries

Comparing the top React toast libraries [2025 update]

Compare the top React toast libraries for when it’s more trouble than it’s worth to create your own custom toast components.

Nefe Emadamerho-Atori
Jun 13, 2025 ⋅ 16 min read
Comparison between TanStack Start and Next.js — two modern full-stack React frameworks with different architectural approaches.

TanStack Start vs. Next.js: Choosing the right full-stack React framework

TanStack Start vs. Next.js: both are powerful full-stack React frameworks, but they take fundamentally different approaches to architecture, routing, and developer experience. This guide breaks down their core features from SSR and data fetching to TypeScript support and deployment, to help you choose the right tool for your next React project.

Abiola Farounbi
Jun 12, 2025 ⋅ 8 min read
View all posts

4 Replies to "Code-first vs. schema-first development in GraphQL"

  1. Great read. I’ve worked on a Typescript/Rails schema first approach application. Now working on a restful Typescript/Laravel service and I’m missing the graphql schema. Im interested in trying a schema first approach. I hope it’ll be a tool allowing backend & frontend dev to collaborate more. The risk I see in a code first approach for speedy changes is the impact on all the integrated systems. Working in a code first approach is enabling the backend dev team to make all design decisions. Depending on your team this may be great. I think this ties into your first point about schemas being a communication tool. Theres one way I’ll find out 🙂

  2. “Im interested in trying a schema first approach. I hope it’ll be a tool allowing backend & frontend dev to collaborate more.”

    Have your tried playing with https://graphqleditor.com/ ? Looks like we might have what you are looking – live collabroation, schema libraries, visual representation as well as mock backend an some more features 🙂

  3. I did both, schema and code first approach (using NestJS). While it is easier to write the contract using the schema, it is much more convenient to then implement the resolvers using the code first approach. So to summarize, I first wrote the gql schema and then wrote the corresponding classes with decorators (code first), once done I dropped the schema.

  4. SDL First or Code First, you can still API First and Schema First. Using “Schema First” to name the act of using SDL to define your API/Schema First is poor naming. The real issue is, you can use SDL or Code to define your API/Schema First, choose the one that makes the most sense for you. The value of API/Schema First design principle is still valid and great practice regardless of it you choose SDL or Code First to is define the API.

Leave a Reply