Nexus: Document the advantages of code first vs SDL first

Created on 28 Oct 2020 · 3Comments · Source: graphql-nexus/nexus

This might be a guide? It might be too long to go on the homepage? It might have a shorter version on the home page?

If a guide it could be called "Why Code First"?

If a guide it would go under the guides section.

typdocs

Source

jasonkuhrt

Most helpful comment

Actually planning touch on this topic within the company I work for where teams are sort of more leaning to jump into SDL First approaches, mainly because it the de-facto in Apollo documentation.

Things I noticed and highlighted in my conversations:

A lot of people jump into GraphQL today and actually don't realise that graphql-js is powering all of it. People see Apollo's SDL first approach and don't expect that it is actually a layer on top of the reference implementation.
The short comings of SDL First that I highlight are:
- Inconsistencies between Schema and actual domain model, can be solved by adopting TypeScript and adding tools like graphql-code-generator
- Modularization becomes harder, when a schema grows you require module boundaries, splitting up schema definitions is harder when everything is just string based.
- Code repetition, the schema is a reflection of your final domain towards the public. A lot of your internal domain objects share the exact same code as the schema. If you employ SDL First you end up copy'ing a lot of definitions like enums, interfaces, pagination objects, ...
- While there is probably a tool for all of the above, combining them all just becomes an explosion in your toolchain
More related to @nexus/schema:
- The development work philosophy (also mentioned by Tim in his conf talks) is great and definitely worth a highlight
- TypeScript support and type safety is built in, yet not enforced. If you like regular JS nexus will still work for you and still have a benefit
- Code re-use is kept to a minimum, interfaces, enums, pagination, all go away and become what they should be which is utility
- The plugin systems makes for an even better workflow that is tailored to you or your team
- And the best one yet, it's a single dependency, not an entire toolchain

Nayni on 30 Oct 2020

👍3

All 3 comments

Actually planning touch on this topic within the company I work for where teams are sort of more leaning to jump into SDL First approaches, mainly because it the de-facto in Apollo documentation.

Things I noticed and highlighted in my conversations:

A lot of people jump into GraphQL today and actually don't realise that graphql-js is powering all of it. People see Apollo's SDL first approach and don't expect that it is actually a layer on top of the reference implementation.
The short comings of SDL First that I highlight are:
- Inconsistencies between Schema and actual domain model, can be solved by adopting TypeScript and adding tools like graphql-code-generator
- Modularization becomes harder, when a schema grows you require module boundaries, splitting up schema definitions is harder when everything is just string based.
- Code repetition, the schema is a reflection of your final domain towards the public. A lot of your internal domain objects share the exact same code as the schema. If you employ SDL First you end up copy'ing a lot of definitions like enums, interfaces, pagination objects, ...
- While there is probably a tool for all of the above, combining them all just becomes an explosion in your toolchain
More related to @nexus/schema:
- The development work philosophy (also mentioned by Tim in his conf talks) is great and definitely worth a highlight
- TypeScript support and type safety is built in, yet not enforced. If you like regular JS nexus will still work for you and still have a benefit
- Code re-use is kept to a minimum, interfaces, enums, pagination, all go away and become what they should be which is utility
- The plugin systems makes for an even better workflow that is tailored to you or your team
- And the best one yet, it's a single dependency, not an entire toolchain