Moving On
In this chapter, we’ve looked at a wide range of topics that help make building and using a GraphQL system more flexible and humane.
You’ve learned how to break up your schema into manageable pieces using Absinthe’s import_types and import_fields macros. We’ve dug deep into GraphQL unions and interfaces, and you’ve discovered how abstract types can make your API more approachable and usable. Your knowledge of GraphQL document building has expanded as well, now that you’ve seen fragments and understood how users can define, apply, and reuse fragments, enabling new approaches to GraphQL document authoring.
Before we head on to the next chapter, here are a few thought exercises based on the material in this chapter:
- Take a look at the schema.ex file. We’ve kept it simple for the purposes of the book, but think through how you might break up the query definition using import_fields, or where you might relocate the common types at the bottom of the schema (using import_types) if you wanted to keep the file as concise as possible.
- We settled on using an interface to model search results for PlateSlate. Can you think of any cases you might prefer to use a union?
- Build a query document that defines a series of named fragments that form a cycle. Why do you think it might be a bad idea to try to execute a query like this? Try to run the document through Absinthe to trigger the error response.
Next up, we tackle a very important topic: mutations! It’s been fun building a read-only API, but it’s probably time to let our users make changes to our data. We think you’ll be pleased with the flexibility you’ll have at your fingertips, especially if you have experience building REST APIs.