GraphQL: Schema-first vs Code-first
Tags: graphql, webdev, beginners, architecture
Published: 2020-08-27 12:54:20

GraphQL started back in 2012 at Facebook HQ. Before being publicly released in 2015 it was used internally as a cure to the underperformance observed in mobile apps on slower networks. GraphQL is a query language for APIs, its main advantage is allowing clients to define exactly what type of data is required. The centerpiece of any GraphQL project is its schema.

**GraphQL schema** is a set of rules describing the functionality available to the client, including specification of operations (queries and mutations) that can be executed to execute against your data graph. 

If you ever decide to build a GraphQL service at some point you would need to chose which approach you want to affiliate with more:

- **Schema-first** - prioritizing process of designing the schema,
- **Code-first (resolver-first)** - approach prioritizing code over schema, where the GraphQL schema is generated programmatically.

In either case, we will end up with a fully functional GraphQL service, but this choice will influence your project in terms of the amount of work you will need to put to achieve certain things like scaling your project etc.

![Schema-first vs code-first](https://dev-to-uploads.s3.amazonaws.com/i/hlwfg64u32n9f16ugdqx.png)


## Schema-first

Schema-first is an approach that puts schema as your source of truth and forces your code to follow the definitions stored in your schema. In general, prioritizing thinking about the schema. If schema design falls short, you might end up with an API that's ignoring your business needs and needs of your end-users.


**Some of the pros:**
- it should most of the times results in a better-designed API,
- it's more abstract and less dependent by following the dependency inversion principle (DIP),
- Schema-first approach reduces development time by allowing frontend and backend teams simultaneously (schema data is easily mockable i.e. with [graphql-editor mock backend feature 🚀](https://app.graphqleditor.com/explore-projects/twitter)),

**Some of the cons/difficulties:**
- the schema definition must be constantly synced with the resolvers, otherwise might cause serious problems,
- might lead to code redundancy as SDL definitions are not so easily reusable,
- difficulty in combining distributed schemas into a single schema (require using 3rd party tools like [graphql-editor](http://graphqleditor.com/) or [graphql-tools](https://github.com/ardatan/graphql-tools))


## Code-first

Code-first (often called resolver-first) is a process where the schema is defined and implemented programmatically. The design process begins with coding the resolvers and the SDL version of the GraphQL schema is a generated artifact (created with a script, not manually). 

**Some of the pros:**
- can work as a single source of truth as it keeps stored both the schema definitions as well as resolvers,
- code-first can  easily overcome difficulties met in schema-first approach, without the usage of a vast amount of tools,
- better manageable if you expect your schema to grow in complexity or size,

**Some of the cons/difficulties:**
- having both the definitions and resolves might be less readable,
- your API design is easier influenced by implementation rather than business needs,
- backward-incompatible changes can slip in more easily compared to schema's first approach.



## The evolution

When GraphQL was publicly released in the 2015 ecosystem we know haven't existed (quite obvious) and the only things that we could lean on were the official GraphQL specification and `graphql-js` (the reference implementation in JavaScript) until 2016 when `graphql-tools` repo was founded which firstly promoted schema-first approach by separating two layers of working with schema:

- **the schema definition** - writing GraphQL schema definition using Schema Definition Language (SDL),
- **the schema implementation** - writing required resolvers. 

After that, the schema-first become default approach but seeing its limitations people started looking for some workarounds which led to first code-first frameworks being released. The Code-first approach is becoming so popular that almost every GraphQL implementation now has its code-first alternative, or even focusing on only the code-first path.

| Language | Schema-first implementation  | Code-first implementation | 
| ------------- |:-------------:|:-----------:|
| JavaScript/TypeScript    | [Apollo server](https://www.apollographql.com/docs/apollo-server/) | [Nexus](https://nexus.js.org/docs/getting-started) |
| PHP (Laravel) | [Lighthouse]() | [laravel-graphql](https://github.com/rebing/graphql-laravel)  |
| PHP (WP) | x |  [WPGraphQL](https://docs.wpgraphql.com/)  |
| Python   | [Ariadne](https://ariadnegraphql.org/docs/intro)     | [Graphene](https://docs.graphene-python.org/en/latest/quickstart/)|
| .NET| [GraphQL for .NET](https://graphql-dotnet.github.io/docs/getting-started/introduction)  | [GraphQL for .NET](https://graphql-dotnet.github.io/docs/getting-started/introduction)  |
| Rust| x   | [Juniper](https://github.com/graphql-rust/juniper) |


What would 2020 bring? Well, I can't wait to find out :)

![GraphQL Evolution](https://dev-to-uploads.s3.amazonaws.com/i/insc2r7js8nszvdkcmwr.png)
##### Source: [prisma.io/blog](https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3)


---

## Want to speed up your GraphQL schema development?

*GraphQL Editor* is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster. **[Try GraphQL Editor for free!](https://graphqleditor.com)**


[![GraphQL Editor](https://dev-to-uploads.s3.amazonaws.com/i/a7qwlawx8v594fs2bq0a.gif)](https://graphqleditor.com/)