graphql: the missing link between frontend and backend devs

The Missing Link Between Frontend and Backend Devs

GraphQL

Sashko Stubailo @stubailo

Apollo Tech Lead, Meteor

Browser

Web Server

C L I E N T

S E R V E R

A B R I E F H I S T O R Y O F W E B A P P S

<HTML />Sending HTML from a web server to a browser

JavaScript UI

API Server

C L I E N T

S E R V E R

A B R I E F H I S T O R Y O F W E B A P P S

{ data }

Sending data from an API server to a single-page app, for better performance

JavaScript UI

API Server

C L I E N T

S E R V E R

A B R I E F H I S T O R Y O F A P P S

{ data }Sending data from an API server to multiple clients in different environments

Native iOS app

CordovaBrowser Native

Microservice Microservice Microservice

C L I E N T

S E R V E R


Splitting into microservices, waterfall loading and multiple APIs



C L I E N T

S E R V E R


Add an API gateway, now there’s a development bottleneckAPI gateway



C L I E N T

S E R V E R

T H E F U T U R E O F A P P S

The solution: GraphQL as the translation layer between frontend and backend

GraphQL API gateway

• Full-stack developers, where frontend teams build the API

• Separate API team

• Backend services team owns their API

• Feature-oriented teams

T E A M S T R U C T U R E S

Too many API endpoints, one per UI

feature

API endpoints don’t meet UI needs

Possible performance or security issues to

ship faster

Takes too long to build the API for a new

feature

Frontend team develops API

Backend team develops API

Best of both worlds?

The benefits

Flexible: “Make your own endpoints”

query Human { human(id: "1000") { name height(unit: FOOT) } }

{ "human": { "name": "Luke Skywalker", "height": 5.6430448 } }

• Choose from your API’s schema of types, fields, and arguments

• Computed fields, parameters, type conditions, and more

• Validates queries for you

Performance: Get what you need

• No need to hit multiple endpoints to render one page

• Select only the fields that are needed

• Batch across all data requirements

• Eliminate unnecessary fetching with fancy clients, such as Apollo and Relay

query Human { human(id: "1000") { name avatar(size: SMALL) friends { name } } }

Not just a tool: An open source spec

S E R V E R S

• Plain HTTP request • React • Angular • Vue • Polymer • Native iOS/Android

C L I E N T S

• Node.js • Ruby • Python • Scala • Java • Erlang

T O O L S

• API explorer (GraphiQL) • Editor autocomplete • Query validation • Mocking • Performance analysis • Code generation

…and more

Constantly improving

subscription { newComments(postId: 5) { content author { name } } }

S U B S C R I P T I O N S

query { newsFeedPosts { title image comments @defer { content } } }

D E F E R

Think carefully about API needs

Hardcode special endpoints

User Interface Backend

W I T H R E S T

Ask for data

Get the data

User Interface Backend

W I T H G R A P H Q L

C O M M U N I C A T I O N

Backend point of view

const HumanQuery = gql` query Human { human(id: "1000") { name height(unit: FOOT) } } `;

Know exactly which parts of the code are using the fields and endpoints in the API, at runtime and statically, to evaluate backend changes and ask UI devs

Query human

Human name height friends

A tool for GraphQL devs to understand their APIOptics


Don’t need to worry about maintaining UI-specific endpoints to reduce roundtrips

api.example.com/posts/1.json api.example.com/posts/1/detailed.json api.example.com/posts/1/mobile-preview.json api.example.com/v3/posts/1/android-feed.jsonX


No need to version API to change the data available, just add new fields

Frontend point of view

More flexibility to prototype, try different ideas, and act independently


query Human { human { name weather friends { name } } }

Get insight into query performance to fix loading problems without diving into the backend, or have information to give backend team

query Human

Optics


Self-documenting API means the UI developer doesn’t need to hunt around to figure out the parameters or data format

A better API experience for both

A P I W O R K F L O W

• Database schema is not always relevant to frontend developers

• These days, not all of your data is in a database!

D B S C H E M A

• Represents contract between frontend and backend

• Has declared relationships • Can be used directly to

implement the server and mock data

# A comment submitted by a user type Comment { # The SQL ID of this comment id: Int!

# The GitHub user who posted the comment postedBy: User!

# The text of the comment content: String!

# The repository which this comment is about repoName: String! }

G R A P H Q L S C H E M A

Enables new dev workflow

1. UI and API developers agree on schema 2. UI developer mocks data based on schema,

starts implementing UI components and views independently

3. API developer builds out schema, informs UI dev of any necessary changes

4. UI and API connected together, queries test for performance

5. Feature shipped!

Schema

UI API

Product

Conclusion: Developer happiness

B A C K E N D

• Clear and concise API to maintain • Know how people are actually

using the data • No need for frequent endpoint

code changes • Smaller security surface area

F R O N T E N D

• Easy to find, understand and consume data

• Many client-side developer tools for caching, validation, and more

• Make your own endpoints

Conclusion: Communication

• Shared type language • Clear API design process • Self-documenting API layer • UI developers get insights into performance • API devs know who is using the data, why,

and what to optimize for

The Missing Link Between Frontend and Backend Devs

GraphQL

Sashko Stubailo @stubailo Apollo Tech Lead, Meteor

Community docs and general information:

graphql.org

Our Medium publication, with tips and in-depth articles about GraphQL

medium.com/apollo-stack

Apollo GraphQL clients and tools:

dev.apollodata.com

graphql: the missing link between frontend and backend devs

Technology