Why UI developers love GraphQL

207 views

Published on

GraphQL is a new API technology that makes it easy to describe the data available in your backend, and then fetch it with a simple query language. In this talk, I go over some of the reasons this is especially great for frontend developers.

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
207
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Why UI developers love GraphQL

  1. 1. Why UI developers love GraphQL Coursera, 9.20.16
  2. 2. A special place in the stack Right between frontend and backend devs
  3. 3. Backend devs implement the API GraphQL is an API technology, so it must make sense to backend people: - Describe data with strong types - Potential for more efficient responses because of explicit fields - Easy to refactor backend to microservices What do you get as a frontend dev?
  4. 4. Speed up your UI development workflow GraphQL enables next-generation tools that let you think less about data fetching. Think about what data you need, and it’s there.
  5. 5. How do you query a GraphQL API? // REST fetch(`api.server.com/posts/1`).then(...) // GraphQL - no special tools needed! fetch(`api.server.com/graphql? query={ post(id: 1) { title, content } }`).then(...)
  6. 6. Benefits over REST, without special client tools - Know exactly which fields we are going to get - Documentation and data exploration built in (something you usually only get with BaaS!) - Nested data fetching is trivial
  7. 7. Basic tooling Realizing the query is more than just a string.
  8. 8. Getting at the query structure - Tag the query to designate that it’s GraphQL - Use a simple regex or AST traversal to find all of the queries - Alternative: put in .graphql files Now the GraphQL query is far more than a “magic string” -- it’s a semantic unit of data fetching const query = gql` query HumanQuery { human(id: "1000") { name height(unit: FOOT) } } `;
  9. 9. Static query validation and analysis Without running the UI: - Typos in fields - Wrong arguments - Deprecated fields - Identify field usage apollostack/eslint-plugin-graphql
  10. 10. In-editor autocomplete - Today: in IntelliJ - Tomorrow: everywhere with the upcoming GraphQL language service jimkyndemeyer/js-graphql-intellij-plugin
  11. 11. It’s super easy to build new tools GraphQL.js: Facebook’s GraphQL tools platform, includes parsing, validation, traversal, etc: graphql/graphql-js GraphQL AST: Super nice to work with, matches up with the spec 1:1, you can use AST explorer: astexplorer.net Introspection: Every GraphQL server is required to provide info in a standard format that works with all tools: graphql.org/learn/introspection/
  12. 12. Caching clients Using the query structure on the client at runtime. Relay
  13. 13. How might we cache REST? 1. Use URL as cache key fetchOrLoadFromCache(`/posts/1`) 2. Write custom normalizer for Redux: decompose responses into objects, store them in separate fields. Might need to handle different endpoints manually, depending on your API design.
  14. 14. Caching GraphQL: Easier or harder? Using URLs or queries isn’t great: fetchOrLoadFromCache(`/graphql?query={...}`) But we gain much more potential: A fancy query structure that tells us exactly what fields we’re looking for.
  15. 15. Example: Overlapping queries query bigQuery { post(id: 1) { title, content author { name, age } } } query smallQuery { post(id: 1) { title, content } } Easy to prefetch data and get subsets of previous queries.
  16. 16. Formalize as paths What’s the atom of GraphQL data? A leaf field. post(id: 1) -> title // bigQuery, smallQuery post(id: 1) -> content // bigQuery, smallQuery post(id: 1) -> author -> name // bigQuery post(id: 1) -> author -> age // bigQuery Lets us easily reason about the data we have fetched, replaces the URLs from REST. This is how Apollo Client works out of the box.
  17. 17. Cache consistency query Sidebar { postFeed { title } } query Post { post(id: 1) { title content } } How do we make the title field for the post refer to one location in the cache?
  18. 18. Cache consistency postFeed[0] -> title -> 'Original title' post(id: 1) -> title -> 'New title' How do we make the title field for the post refer to one location in the cache?
  19. 19. Defining cache IDs for the client Could be server-side like Relay or client-side like Apollo (obj) => obj.__typename + ':' + obj.id
  20. 20. Paths with IDs Now we can easily keep our cache consistent! postFeed[0] -> (id: 1) post(id: 1) -> (id: 1) (id: 1) -> title -> 'New title'
  21. 21. Data flow Now that we have a cache, let’s use it!
  22. 22. Updating the store updates the UI Smart clients execute the queries when the store changes, keeping your UI consistent query Sidebar { postFeed { title } }
  23. 23. Full data loading path Smart clients execute the queries when the store changes, keeping your UI consistent query Sidebar { postFeed { title } } Fetcher query Sidebar { postFeed { title } } Normalizer
  24. 24. Updates can come from anywhere It’s like automated Flux, which takes advantage of the GraphQL query structure query Sidebar { postFeed { title } } Other queries Mutation results Subscription results Redux actions
  25. 25. More tools Today: - Static code generation and native clients: apollo-ios - Pub/sub GraphQL subscriptions: graphql-subscriptions Tomorrow: - Client-side data - Cache expiration - Building your own bespoke clients Let’s build the future together!

×