- First you write a schema:
- You write your types. I think of these as the nouns.
- Next you write queries on those types. I think of these as the reads, or your GET API endpoints, or your SELECT queries in SQL.
- You write mutations. These are your writes. Maybe your inserts, updates, and deletes.
- I'm skipping how to write subscriptions. They sure look cool!
- Outside your schema, you write resolvers for your queries and for your mutations.
Use it like this:
curl -H "Content-Type: application/json" \
-X POST \
-d '{"query": "query {demo {current_timestamp bogus_field_a bogus_field_b} }"}' \
http://127.0.0.1:8000
There's a war going on over how much should we write these schemas by hand, versus use code to build them up, versus use code to infer them by studying the underlying datasources, like databases, or REST APIs.
When you write resolvers, you need to make sure that you think through who is asking for what data.
In other words, GraphQL doesn't solve thorny authorization issues.
For example, imagine that you make a GraphQL interface for a bank. You limit access to logged-in users. But in your resolvers, you need to make sure that Matt is only accessing data that Matt is blessed to access.