Learning GraphQL for Mobile

Learning GraphQL for Mobile

A talk at the Omaha Mobile Meetup about the future of GraphQL on Mobile.

Acb8c985ddf8a03c218569e471cc7322?s=128

John Shelley

July 06, 2016
Tweet

Transcript

  1. Learning GraphQL for Mobile John Shelley - @jpshells Mobile (Android)

    Developer @ Hudl http://public.hudl.com/jobs/
  2. • GQL Overview • Mobile Implementation • Demo?

  3. What’s all the fuss about?
 (credit: Degner, Freeman, and Isman

    ) GQL Overview
  4. ◦ GraphQL = “Graph Query Language” ◦ Data query language

    and runtime ◦ Alternative paradigm to REST i.e. client-side apps talking to backend servers CRUD: ◦ Retrieve -> GQL “Query” ◦ Create/Update/Delete -> GQL “Mutation” What even is it?
  5. None
  6. ◦ Graph a set of connected nodes “Graph Query”? Huh?

    ◦ Query power of GQL is in querying
  7. GraphQL vs REST

  8. ◦ User data type REST comparison: Intro { id: <int>

    name: <string> favouriteQuote: <string> thumbnailUrl: <string> }
  9. ◦ REST request (GET): ◦ User data type REST comparison:

    Intro { id: <int>, name: <string> favouriteQuote: <string> thumbnailUrl: <string> } blah.com/api/user/123
  10. ◦ REST request (GET): ◦ GraphQL request (POST): ◦ User

    data type REST comparison: Intro blah.com/api/user/123 blah.com/api/graphql query { user(id: 123) { id name favouriteQuote thumbnailUrl } } { data: { user : { id: 123, name: “Billy Big Braces” favouriteQuote: “blah blah blah…” thumbnailUrl: http://someUrl.com/kjh234/zxc0v8z0.jpg } } } { id: <int>, name: <string> favouriteQuote: <srting> thumbnailUrl: <string> }
  11. ◦ favouriteQuote is huge REST comparison: Unwanted fields

  12. ◦ favouriteQuote is huge REST comparison: Unwanted fields ◦ thumbnailUrl

    is heavy to compute (e.g. requires long running process)
  13. ◦ favouriteQuote is huge REST comparison: Unwanted fields ◦ thumbnailUrl

    is heavy to compute (e.g. requires long running process) ◦ REST solution: blah.com/api/userlightweight/123
  14. ◦ favouriteQuote is huge REST comparison: Unwanted fields ◦ thumbnailUrl

    is heavy to compute (e.g. requires long running process) ◦ REST solution: ◦ GraphQL solution: blah.com/api/userlightweight/123 query { user(id: 123) { id name } } { data: { user : { id: 123, name: “Billy Big Braces” } } }
  15. ◦ A user has friends i.e. a user has connections

    to other users REST comparison: Connections
  16. ◦ A user has friends i.e. a user has connections

    to other users REST comparison: Connections ◦ REST solution: ajax.get('blah.com/api/user/123') .done((data) => { const friendsString = data.friends.join('-'); ajax.get(`blah.com/api/users/${friendsString}`) .done((data) => { // process friends data }); });
  17. ◦ A user has friends i.e. a user has connections

    to other users REST comparison: Connections ◦ REST solution: ajax.get('blah.com/api/user/123') .done((data) => { const friendsString = data.friends.join('-'); ajax.get(`blah.com/api/users/${friendsString}`) .done((data) => { // process friends data }); }); ◦ GraphQL solution: query { user(id: 123) { thumbnailUrl friends { name } } } { data: { user : { thumbnailUrl: “http://someUrl.com/kjh234/zxc0v8z0.jpg” friends: [ { name: “Sammy Sausage”, }, { name: “Sir Lancel Worthington-Hensley”, }, ... }
  18. ◦ AutoComplete ◦ Full featured docs ◦ Use the chrome

    extension ChromeiQL Note: make sure you’re logged in to the server GraphiQL
  19. Mobile + GQL = ♥

  20. Mobile + GQL =

  21. ◦ Choose your own HTTP Stack
 (HttpUrlConnection, OkHttp, Retrofit, Volley,

    etc) ◦ One single endpoint ◦ POST a 2 field content body ◦ Only ever receive a 200 or 500s ◦ ETags/Caching?. . . Setup
  22. None
  23. @POST(“graphql/query") Call<Response> query(@Body Request request); Client

  24. Request

  25. Response

  26. Why? ◦ Okay… so its not refined…but ◦ Ability to

    send less data over the wire. ◦ Ability to chain multiple calls into one. ◦ Ability to create complex queries dynamically. ◦ Clients don’t need to worry about API versioning.
 (A query should never become invalid)
  27. Why? “Rather than creating multiple simultaneous connections to download data,

    or chaining multiple consecutive GET requests, where possible you should bundle those requests into a single GET.” - Google https://developer.android.com/training/efficient-downloads/efficient-network-access.html
  28. Why?

  29. Why? api/videos api/playlists

  30. Why? api/videos api/playlists api/presentations api/video_360 api/playbooks api/video_vr api/video_ios VS api/videos_android

  31. Why? api/graphql/{query}

  32. Mobile + GQL + Apollo = ♥

  33. None
  34. ◦ .graphql files with attached schema ◦ Introspection to provide

    schema requirements ◦ Compile time code generation of ViewModels ◦ Strict parsing of Response based on Request query ◦ Local DB hooks for Sqlite and Core Data ◦ All the benefits without any of the pain Future
  35. Demo https://learngraphql.com/basics/querying-graphql