graphql: the missing link between frontend and backend devs
Post on 16-Apr-2017
1.722 Views
Preview:
TRANSCRIPT
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
A B R I E F H I S T O R Y O F A P P S
Splitting into microservices, waterfall loading and multiple APIs
CordovaBrowser Native
Microservice Microservice Microservice
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
Add an API gateway, now there’s a development bottleneckAPI gateway
CordovaBrowser Native
Microservice Microservice Microservice
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
Backend point of view
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
Backend point of view
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
Frontend point of view
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
Frontend point of view
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
top related