Choose Your Own Adventure for client web services
With
Dave Anderson
@dvndrsn
before the adventure
A little bit about me
PROLOGUE TO THE ADVENTURE
As a developer we face choices everyday..
PROLOGUE TO THE ADVENTURE
Those choices have consequences..
PROLOGUE TO THE ADVENTURE
GraphQL offers an alternative to REST...
PROLOGUE TO THE ADVENTURE
What to expect on your journey...
Choose GraphQL or REST
Review examples
Advanced Considerations
Chapter 1
API Architecture and Design
You are a developer.
If you choose a REST, advance to the next section.
One things is for sure: you need a robust API.
What do you choose?
If you choose GraphQL, advance to the following section.
Choose Rest
Architecture and Design
You choose to build your API using REST web service architecture.
Choosing REST is a familiar design decision.
Choose Rest
Architecture and Design
You use HTTP verbs semantically to describe operations on your resources
GET /api/v1/stories/
POST /api/v1/stories/
GET /api/v1/stories/{id}/
PUT /api/v1/stories/{id}/
DELETE /api/v1/stories/{id}/
Choose Rest
Architecture and Design
You build many different endpoints, for each resource.
GET, POST /api/v1/stories/
GET, PATCH, DELETE /api/v1/stories/{id}/
GET, POST /api/v1/stories/{id}/passages/
GET, PATCH, DELETE /api/v1/stories/{id}/passages/{id}/
GET, POST /api/v1/stories/{id}/passages/{id}/choices/
GET, PATCH, DELETE /api/v1/stories/{id}/passages/{id}/choices/{id}/
Choose Rest
Architecture and Design
You choose how to structure your response.
// Hypermedia as the Engine of the Application State - HATEAOS
// GET api/v1/stories/
{
"id": 1,
"title": "REST",
"author": "Dave A.",
"description": "Can have many response structures",
"links": [
{
"href": "1/passages/",
"type": "GET",
"rel": "passages
},
// ... etc
]
}
Choose Rest
Architecture and Design
You receive many requests to add new fields to the API.
..but now some clients are fetching fields that they don't need.
You want to deprecate old fields or refactor the structure of the API by introducing a new set of versioned endpoints.
..but now you're supporting multiple versions of each API resource forever.
Choose Rest
Architecture and Design
You are attacked by a sea monster with as many arms as your API has endpoints and versions.
You die.
Wait, wait, wait.. let's skip back and choose GraphQL.
Choose GraphQL
Architecture and Design
Your friend tells you about a new specification for designing API introduced by Facebook in 2015, called GraphQL.
You choose to explore GraphQL deeper.
Choose GraphQL
Architecture and Design
GraphQL is a query language for your API.
It allows clients
to ask questions of your server
and only get the data they need
in a single request.
Choose GraphQL
Architecture and Design
You define a schema...
type Story {
id: ID,
title: String,
author: String,
passages: [Passage]
}
type Passage {
id: ID,
name: String,
description: String,
is_ending: Boolean,
choices: [Choice]
}
type Choice {
id: ID,
description: String,
toPassage: Passage
}
type Query {
story(id: ID): Story
}
Choose GraphQL
Architecture and Design
Then you write queries against that schema..
query myStory {
story(id:1) {
id
title
passages {
id
name
description
}
}
}
Choose GraphQL
Architecture and Design
And you get a JSON response.
{
"story": {
"id": "1",
"title": "Choose Your Own Adventure with GraphQL",
passages: [
{
"id": "1",
"name": "Beginning",
description: "Your adventure begins",
},
{
"id": "2",
"name": "GraphQL Architecture",
description: "Choose GraphQL!",
},
// ...
]
}
}
Choose GraphQL
Architecture and Design
If you need to change data, write a mutation!
mutation newStory {
createStory (input: {
title: "GraphQL",
author: "Dave A",
description: "Its pretty cool"
}) {
story{
id
title
description
author
}
}
}
Choose GraphQL
Architecture and Design
You use awesome tools to help you build your application.
Like GraphiQL...
Choose GraphQL
Architecture and Design
You use awesome tools to help you build your application.
Or GraphQL voyager...
Choose GraphQL
Architecture and Design
You use awesome tools to help you build your application.
Or GraphQL Faker...
Choose GraphQL
Architecture and Design
Open sourced by Facebook in 2015.
Since open sourcing, we now have a lot of choice!
Which platform do you choose?
If you choose a Python, advance to the next section.
Seriously, choose Python, advance to the next section.
Choose Python + Graphene
Architecture and Design
You choose to use the Graphene framework in Python.
Choose Python + Graphene
Architecture and Design
Graphene Django provides some nice built in Views to handle parsing GraphQL requests.
# Makes GraphiQL available at http://oursite.com/graphql !
urlpatterns = [
...
path(
'graphql/',
GraphQLView.as_view(schema=schema,graphiql=True)
),
...
]
Choose Python + Graphene
Architecture and Design
You write your schema.
class StoryType(graphene.ObjectType):
class Meta:
interfaces = (graphene.Node, )
title = graphene.String()
description = graphene.String()
author = graphene.String()
passages = graphene.List(PassageType)
...
class Query(graphene.ObjectType):
story = graphene.Node.Field(StoryType)
...
schema = graphene.Schema(query=Query)
query myStory {
story(id:1) {
id
title
passages(first: 2) {
id
name
description
}
}
}
Choose Python + Graphene
Architecture and Design
You write resolvers for each of the fields.
class StoryType(graphene.ObjectType):
...
def resolve_title(self, info, **args):
return self.title
...
class Query(graphene.ObjectType):
...
def resolve_story(self, info, **args):
id = args.get("id")
return Story.objects.get(id=id)
...
query myStory {
story(id:1) {
id
title
passages(first: 2) {
id
name
description
}
}
}
Choose Python + Graphene
Architecture and Design
You write mutations for any requests that result in changes to data.
class StoryInput(graphene.InputObjectType):
title = graphene.String(required=True)
description = graphene.String()
author = graphene.String()
class CreateStory(graphene.Mutation):
class Arguments:
input = StoryInput(required=True)
story = graphene.Field(StoryType)
@classmethod
def mutate_and_get_payload(cls, root, info, **input):
story = Story.objects.create(*input)
return cls(story=story)
class Mutation(grapene.ObjecctType):
create_story = graphene.Field(CreateStory)
...
schema = graphene.Schema(
query=Query,
mutation=Mutation
)
mutation newStory {
createStory (input: {
title: "GraphQL",
author: "Dave A",
description: "Its pretty cool"
}) {
story{
id
title
description
author
}
}
}
Choose Python + Graphene
Architecture and Design
You add new fields easily.
You modify existing fields without worrying about breaking clients.
You signal for fields to be depreciated with annotations on your schema.
Choose Python + Graphene
Architecture and Design
What a relief!
You made a great API! Advance to the next section.
Your GraphQL API is coming along so well that you've earned some space shore leave.
CHAPTER 2
Advanced API Considerations
Let's rewind some of our REST decisions and continue.
Your Adventure CONTINUES
Authentication and Rate limiting
Now that you've designed a wonderful schema, it's time to share it with the world.
You need authentication.
Both REST and GraphQL are unopinionated.
Rate limiting is similar for both, but more complex schemes might be appropriate for GraphQL.
If you chose REST OR GraphQL, advance to the next section.
Your Adventure CONTINUES
Authentication and Rate limiting
Arbitrary nesting! Maybe not on a public API..
Your Adventure Continues
Scaling and Performance
Traffic is growing day by day,
you better scale that API before it crashes!
What kind of API did you build?
If you chose to build a REST API, advance to the next section.
If you chose to build a GraphQL API, advance to the following section.
Success! You've built a robust API with all the data and features you need.
Choose Rest
Scaling and Performance
If you've designed your API well, scaling is something that REST does great.
While challenging, it is a well documented task.
Choose Rest
Scaling and Performance
REST lends itself to HTTP caching.
You can also manage complex requests with per endpoint tuning.
Advance to the next section to see what happens with GraphQL.
Seems to be smooth flying..
Choose GraphQL
Scaling and Performance
Scaling is a little more challenging with GraphQL.
HTTP level request caching not generally possible.
Tuning at a per resolver level.
Choose GraphQL
Scaling and Performance
Be wary of serial resolution of fields
Story.title
Story.passage
Passage.name
Passage.choices
Passage.choices
Choices.description
Choices.passage
Passage.description
Time
Choose GraphQL
Scaling and Performance
Data loader and proper configuration can help.
Story.title
Story.passage
Passage.name
Passage.is_ending
Passage.choices
Choices.description
Choices.passage
Passage.description
Time
Choose GraphQL
Scaling and Performance
You try to scale your GraphQL service.
Alone out in space,
the documentation on edge cases is thin...
and StackOverflow posts on scaling are sparse.
You send out an SOS.
Hopefully everything turns out ok.. Advance to the next section.
CHAPTER 3
Frontend Design and Architecture
Let's rewind one last time and continue.
Your Adventure Continues
Building a client web application
Your API is now built, secured and ready to share with the world.
If you chose to build a REST API, advance to the next section.
If you chose to build a GraphQL API, advance to the following section.
Now its time to build a rich web client application.
Choose Rest
Building a client web application
You now have a robust REST API.
There is no standardized way to document REST endpoints, but frameworks like Swagger can help.
Service discovery can be a challenge.
Choose Rest
Building a client web application
You're ready to write some code.
Unfortunately, you need to write boilerplate to handle interactions with the API such as:
Asynchronous fetching...
Error handling...
Data normalization...
And caching.
Choose Rest
Building a client web application
Further optimization for data fetching may be needed.
Your frontend code may need to deal with underfetching and optimize
N+1 requests.
Choose Rest
Building a client web application
Your frontend code becomes a cage of complexity.
You are surrounded by N+1 HTTP requests and sharks and there is no escape!
Gulp!
That's no good.. let's try that again with GraphQL.
Choose GraphQL
Building a client web application
You choose to build a web application using your GraphQL API as a backend.
You rapidly prototype queries using tools and autogenerated documentation.
Choose GraphQL
Building a client web application
Relay and Apollo are powerful frameworks that allow you to focus on writing application code.
However, they are opinionated about your application structure and your GraphQL schema.
Choose GraphQL
Building a client web application
const Story = ({ loading, error, data }) => {
if (loading) {
return (<div>Loading the story!</div>)
}
if (error) {
return (<div>There was an error: {error.message}!</div>)
}
return (
<div>
<div>Title: {data.story.title}</div>
<div>Author: {data.story.author}</div>
<div>Description: {data.story.description}</div>
</div>
)
}
const client = new ApolloClient({
uri: 'MY_COOL_GRAPHQL_URL'
});
ReactDOM.render(
<ApolloProvider client={client}>
<StoryWithData storyId={1} />
</ApolloProvider>,
root
)
const query = gql`
query myStory ($storyId: String) {
story(id:$storyId) {
id
title
passages {
id
name
description
}
}
}
`
const options = (props) => ({
variables: {
storyId: props.storyId,
}
})
const withStoryData = graphql(query, {
alias: 'withStoryData',
options,
})
const StoryContainer = withStoryData(
Story
)
Choose GraphQL
Building a client web application
const withCreateStory = graphql(mutation, {
alias: 'withCreateStory',
props: mapMutationToProps,
})
const StoryFormContainer = connect(
withStoryData,
withCreateStory,
)(StoryForm)
// callback is available in StoryForm component now!
// Pass in values to call the mutation.
const StoryForm = ({ handleCreateStory }) => ({
<button
onClick={() => handleCreateStory(
'Title',
'Author',
'Description',
)}
>
Create a story!
</button>
})
const mutation = gql`
mutation newStory ($input: StoryInput) {
createStory (input: $input) {
story{
id
title
description
author
}
}
}
`
const mapMutationToProps = ({ mutate }) => ({
handleCreateStory: (
title,
author,
description
) => {
mutate({
variables: {
input: { title, author, description },
}
// optimisticResponse: ...,
// update: ...,
})
}
})
Choose GraphQL
Building a client web application
You make more efficient requests from your server.
You write less boilerplate code.
You can easily improve perceived performance through caching and optimistic mutations.
Choose GraphQL
Building a client web application
The web application with GraphQL and Apollo is really coming together.
Everyone shares some cake and pie in the space break room to celebrate.
Mmm, mm.. Turn to the next section.
EPILOGUE TO Your Adventure
A parting word before the next adventure
It was long, hard work, but you built a robust web application and API backend.
GraphQL was useful as a general purpose API with productive frameworks for development.
But REST is still a proven and scalable solution.
Next time what will you choose?
If you choose to build a REST API, advance to the next section.
If you choose to build a GraphQL API, advance to the next section.
The end
Thanks for listening!
Questions?
@dvndrsn
The Rabbit Hole Podcast: http://bit.ly/2Jous2O
Stride Consulting: https://www.stridenyc.com/careers
Dave Anderson
References
Thanks for listening!
Icons8 (open source icons):
https://icons8.com/
Open Clip Art:
https://openclipart.org/
Code Sample:
https://github.com/dvndrsn/cyoa-story
Graphene (Python):
http://docs.graphene-python.org/en/latest/
Apollo (JavaScript):
https://www.apollographql.com/docs/
Choose Your Own Adventure for Client Web Services with GraphQL
By dvndrsn
Choose Your Own Adventure for Client Web Services with GraphQL
In the style of a modern, web-development choose your own adventure, we'll explore the benefits and trade offs of GraphQL and REST. We'll build up an example schema using a choose your own adventure story as the model and leverage that schema in frontend code. We'll also learn about some advanced considerations of GraphQL like performance and scaling.
- 1,391