Kicking off a GraphQL Schema Design Process
When it comes to designing GraphQL schemas it's important to first understand what good design means.
For once it's definitely to have queries, mutations and types driven by the business domain in order to let developers build the desired use-cases with ease. Nevertheless a well designed schema also allows you extend or change it based on new requirements without making breaking changes.
In this lesson we will walk through a simple process on how to kick off a schema design process based on wireframes or UI designs. In combination with a set of solid conventions this will help you to get started, but still be able to iteratively improve your schema.
Instructor: [0:00] For this course, we're going to design the schema of a web shop selling laptops and related accessories. Where do we start? I recommend starting with one use case. In our case, we're going to pick the detail page of one product.
[0:16] In an ideal scenario, we would have deep knowledge about the domain, and a fixed list of use cases and requirements. Reality is often very different, though. That's why I recommend using the approach of starting with the user interface.
[0:32] While naturally you might want to start out with defined types, I urge you to start with writing down the queries, and possibly their example results, because this is what the developers building your clients will do. This way, you can see how you're going to use the schema. Let's do this by retrieving this one laptop with only its name. The expected result would look like this. Great.
[1:05] Next up, we add the description. We add it to the query and then to the result. Let's implement it in our schema and verify it works as expected. We add the type product, and with it the name and description.
[1:24] Then we add a query product, returning a product based on the ID. Once implemented, we can copy our previously defined example query, switch to the browser, and verify that it works as expected. Looks good to me.
[1:43] As said, while this process doesn't automatically lead us to a good design, it's a good way to start. To me personally, a well-designed GraphQL schema allows you to cover all known use cases and behaviors in a domain-driven fashion while still being optimized for change.
[2:02] Regarding the domain knowledge, there's not much more that we can do than just learn about it, but is there something that we can do to optimize for changing requirements? There is, and we will explore them in this course.