GraphQL vs REST
Talk Goals
- A recap on server to server networking
- Compare SOAP, REST and GraphQL
- Consider why REST is NOT the best networking standard
- Discuss the fundamentals of GraphQL
- Write some fun GraphQL examples
Us vs GraphQL
(Before)
Us vs GraphQL
(After)
Speaker Bio
Christian (codebeast) Nwamba
- Developer Advocate at Cloudinary
- Program Manager at Scotch.io
- forLoop Africa co-organizer
- Frontstack co-organizer
- Author
@codebeast on Twitter
Server to Server Networking
Network
Response
Request
That is a blueprint.
How is the actual process completed?
Remember SOAP?
- Stands for "Simple Object Access Protocol"
- The "Simple" in the definition is a big lie
- SOAP os based on XML and too wordy for data transmission
- SOAP is heavy
Remember REST? Bet you do!
- Gentle with the brain
- Lightweight (JSON is lighter than XML
- Descriptive. You can easily tell that we have a table-like data structure
- Verbs are used to describe HTTP actions
So...why not just REST?
Under/Over Fetching Content
GET /users/<id>
{
name: John,
age: 25
}
Under/Over Fetching Content
GET /users/<id>/posts
[{
title: Hello,
date: 5s
},
...]
Observations
The `/<id>` route could have fetched each user's posts but we are not sure when the client actually needs it.
Observations: Over Fetching
- If we included the posts as part of the response
- And the client does not need it,
- Over fetching occurs
- And causes a negative impact on performance
Observations: Under Fetching
- If we decide NOT to include it as we are doing in the previous illustrations
- And the client ends up needing it,
- Under fetching occurs
- The client has to make a second trip to the network for it
"It should be about what the client needs, NOT what the architect thinks that the client would need." - codebeast
- Don't give me his or her email
- Don't give me his or her name
- And don't make me fetch twice (user and posts)
So if I want just the user id and a list of the user's posts:
Schemaless-ness
- REST as a means is too flexible. Validation is hard.
- There are no sure means of knowing what an API schema looks like.
- We rely mostly on API docs which is hardly reliable
Prototyping Friction
- REST as a protocol is too inflexible
- There's a stiff structure that makes it hard to change based on client demand
- Most times when the user demands an awesome feature on the client, we might always need to adjust the endpoints to suit that
Even more problems...
- Had a type system that serves as a data contract for both the client and the server?
- Had just one URL endpoint...
- ...And we can send all queries/writes from the client directly and not rely on URLs to define our capabilities
- Had a way to self-document APIs based on defined types and structure?
What if we...
Say hello to... GraphQL
GraphQL Fundamentals
Schema Definition Language
-
SDL is the type language that GraphQL understands
- A type is a contract that both the server and the client must adhere to. Any violation throws an early error.
Since SDL is the type language, what then does a type look like?
Identifier
Type Name
Field(s)
Field Type
Non-Nullable
Directive
Type Anatomy
| Scalar Types | Custom Types | Other Base Types |
|---|---|---|
| Int | Todo | Query |
| String | User | Mutation |
| Float | Post | enum |
| DateTime | Cart | interface |
| Boolean | Animals |
Type of Types
Custom Types
Query and Mutation Base Types
Play Time
- https://www.howtographql.com
- https://dev-blog.apollodata.com/the-anatomy-of-a-graphql-query-6dffa9e9e747
- https://graphql.org/learn/schema/#lists-and-non-null