What comes to you if you want to have some fun with GraphQL?
Join us for the meetup in Munich and enjoy the interesting talk about ‚GraphQL vs. (the) REST ‘.
In this session our colleagues Tsvetan Nikolov (Senior Developer at coliquio) and Tom Sedlmeier (Senior Developer at coliquio) will discuss the basic concepts and how to use them.
We will present you GraphQL on the backend and on the client side with Apollo.
9. LET’S MAKE A LIST OF ALL CHALLENGES SO FAR
• Documentation? - No need. It’s
just an MVP
• Multiple server requests
•What about overfetching data
• What if we need device specific
data?
14. PROS
• statically typed
• no over/under fetching
• language & HTTP agnostic
• completely decouples frontend from backend
• documentation comes at no extra cost
• can save bandwidth
15. CONS
• not easy to implement network caching
• working with file uploads is tricky
• sometimes error reporting can be a bit cryptic
• frontend team must switch to a GraphQL stack
18. HOW DO WE DEAL WITH
DATA FETCHING IN THE FRONTEND?
19. ‣ results in a lot of API endpoints
‣ „chatty“
‣ overfetching: often you don’t need the complete data set
‣ care about client caching and normalization
‣ frontend & backend (deploy) strongly correlated
REST API ARCHITECTURE
23. THE APOLLO CLIENT
‣ universal
‣ cares about caching and normalization
‣ cares about loading state tracking + error handling
‣ version 2 is much smaller, better package management, less deps
36. MORE QUERIES IN ONE COMPONENT
‣ compose it (works like higher-order functions)
‣ Apollo will merge all together
37.
38. APOLLO CLIENT FETCH POLICIES
cache-first Only fetch if data isn’t in the cache
cache-and-network Cache first, then always fetch
network-only Always fetch, never use cache
cache-only Never fetch, try reading from cache
44. OPTIMISTIC UI PATTERN
‣ no place for a spinner anymore
‣ write your mutation as usual
‣ your future response goes in the optimisticResponse param
45. APOLLO HAS A BIG ECOSYSTEM
‣ links
‣ GraphiQL interface for API inspection & documentation
‣ Apollo browser dev tools
‣ Apollo codegen for flow + type script
‣ eslint-plugin-graphql
‣ IDE support
46. REST API ARCHITECTUREREVIEW
‣ results in a lot of API endpoints
‣ „chatty“
‣ overfetching: often you don’t need the complete data set
‣ care about client caching and normalization
‣ frontend & backend (deploy) strongly correlated
47. CONCLUSION & RECOMMENDATION
‣ much less effort than with REST
‣ GraphQL / Apollo Client documentation is fantastic
‣ give it a try, write your first simple query using Star Wars API
http://graphql.org/swapi-graphql
‣ use „ apollo-boost“ for quick-start and first steps
‣ we are still at the beginning, there’s coming more