GraphQL Schema is registered as a plugin of type
graphql. Let's take
a look at a code example:
This schema will add a new field called
myApp to the root Query and Mutation fields.
Types and resolvers
26 you will notice we define
using functions that return an array of types/resolvers.
This is necessary for smooth instantiation and schema merging, to avoid
security on lines
47-56 defines rules for graphql-shield.
It is a very convenient way of performing authorization for your schema without
hardcoding the security logic in your resolvers.
webiny-api-security package provides 2 helper functions,
to easily add checks for scopes and roles to your schema. Scopes defined
hasScope function will be picked up by the system and will be available in the admin app
while creating roles.
To create your own rule use the
graphql-shield package directly.
Let's create an
isAuthenticated rule to simply check if user is logged in:
For more examples and advanced usage, visit the official graphql-shield API docs.
While developing the CMS we tried multiple approaches to structure the response from the resolvers and in the end we settled for the following one:
The main problem was to somehow handle errors. You can't just throw an error and kill the entire response, since GraphQL allows you to query multiple fields at once.
So the idea is to always have an envelope for your resolver response, be it a single record
or a list of records. An envelope (
data key which will contain the actual resolver data,
and there is also an
error key which will contain error data.
types should also contain
meta key with data for pagination.
Generic data types
Webiny API comes with the following built-in data types you can use anywhere in your SDL without importing them (it is handled automatically):
Schema definition can be split into multiple files, to organize typeDefs and resolvers by feature and reduce the size of the main schema.