GraphQL - Evolution or Revolution?

GraphQL - Evolution or Revolution?

6bf996b0a495020ca5de706bcc776271?s=128

Jonas Helfer

May 21, 2017
Tweet

Transcript

  1. GraphQL Europe, May 21 2017 GraphQL - Evolution or Revolution?

    Jonas Helfer @helferjs Open Source Software Engineer, Meteor
  2. Why we chose GraphQL at Meteor Our requirements: 1. Support

    any data source 2. Allow joins across data sources 3. Declarative data fetching 4. Real-time support @helferjs
  3. Evolution or Revolution? @helferjs

  4. What problem are we trying to solve? Backend Frontend transfer

    state Backend has access to all data Frontend operates on a subset of the data @helferjs
  5. Example: Building a Medium clone @helferjs

  6. A history of web API technologies SOAP 1999 REST OData

    2007 GraphQL 2015 Falcor @helferjs
  7. Standard Object Access Protocol (1999) • A protocol • Centered

    around RPC methods • Uses XML • Usually over HTTP or SMTP @helferjs
  8. Standard Object Access Protocol (1999) GET /RecentPosts HTTP/1.1 Host: www.medium-clone.com

    Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetRecentPosts> <m:PublicationName>apollographql</m:PublicationName> </m:GetRecentPosts> </soap:Body> </soap:Envelope> @helferjs
  9. Representational State Transfer (2000) • Architectural style introduced by Roy

    Fielding in his PhD dissertation • Centered around resources • Most commonly uses JSON or XML • Usually over HTTP @helferjs
  10. REST Architectural Constraints 1. Client-Server 2. Stateless 3. Cacheable 4.

    Layered System 5. Uniform Interface A. Identification of resources B. Manipulation of resources through these representations C. Self-descriptive messages D. Hypermedia as the engine of application state @helferjs
  11. Representational State Transfer (2000) GET /apollographql/recentPosts HTTP/1.1 Host: www.medium-clone.com Content-Type:

    application/json; charset=utf-8 Content-Length: nnn ——————————————————— HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn [{ “id”: “ae1db58d72”, “title”: “Why GraphQL is the future”, “author”: “/users/helfer”, “text”: “…” },{ … }] @helferjs
  12. RESTful - one endpoint per resource Endpoint 1 Endpoint 2

    Endpoint 3 Cordova Browser Native Users Posts Comments Pros • flexible • decoupled Cons • lots of roundtrips • overfetching • complex clients @helferjs
  13. REST-ish - one endpoint per view Endpoint 1 Endpoint 2

    Endpoint 3 Browser Native View A (web) View B (web) View C (mobile) Pros • one roundtrip • exactly what you need Cons • inflexible • high maintenance cost • high development cost • slow to iterate @helferjs
  14. Cordova Browser Native SQL Redis External API Standardized API layer

    The need for a standardized API layer @helferjs Requirements • one roundtrip • get just what you need • flexible • decoupled • discoverable
  15. Cordova Browser Native SQL Redis External API OData? Falcor? GraphQL?

    The need for a standardized API layer Requirements • one roundtrip • get just what you need • flexible • decoupled • discoverable @helferjs
  16. • $select: choose which fields you want • $expand: fetch

    related resources • $top + $skip: pagination • $filter (eq, lt, startswith, …): server-side filtering • $metadata: introspection + discovery OData (2007) — “The best way to REST” * * if you believe Microsoft @helferjs
  17. OData Request GET /PostsServiceRW/RecentPosts?$top=3 &amp; $select=Title, Text &amp; $filter=Org/any(d:d/Name eq

    apollographql) HTTP/1.1 OData-Version: 4.0 OData-MaxVersion: 4.0 @helferjs
  18. OData Response (Example) @helferjs

  19. XOData — OData’s GraphiQL? @helferjs

  20. Falcor • All data modelled as a JSON object with

    references • All values resolve asynchronously • “Routes” determine how data is fetched • Data is treated as a graph (not tree) • Easy to learn & use • No type system, no arguments @helferjs
  21. Falcor // ask for name and age of user with

    id = 5 model.get(“users[5]['name','age']"); // eventually get something like { "users": { "5": { "name": "John Doe", "age": 33 } } @helferjs
  22. GraphQL query { recentPosts(limit: 3) { title text recommends {

    totalCount } author { name } } } @helferjs
  23. GraphQL • Easy-to-use query language • Get exactly what you

    need • Type System • Advanced tooling • Resolver runtime @helferjs
  24. Is GraphQL RESTful? 1. Client-Server ✅ 2. Stateless ✅ 3.

    Cacheable ✅ 4. Layered System ✅ 5. Uniform Interface A. Identification of resources ❌ B. Manipulation of resources through these representations ✅ C. Self-descriptive messages ✅ D. Hypermedia as the engine of application state ❌ @helferjs
  25. Node interface • Every object/resource has a unique id •

    Every resource can be retrieved given its id @helferjs
  26. Node interface query query { node(id: “74fe64c356c2”) … on Post

    { title author { name } } } @helferjs
  27. GraphQL + node interface == RESTful Uniform Interface ✅ A.

    Identification of resources ✅ B. Manipulation of resources through these representations ✅ C. Self-descriptive messages ✅ D. Hypermedia as the engine of application state ✅ @helferjs
  28. And the winner is … @helferjs

  29. GraphQL! @helferjs

  30. Why GraphQL is winning • Straightforward query language • Amazing

    tooling (GraphiQL, Apollo Launchpad, …) • Stronger developer story than Falcor, OData • Strong community • Incremental adoption @helferjs
  31. Evolution or Revolution? @helferjs

  32. Technical evolution @helferjs

  33. Social revolution

  34. Join the revolution! Ways to get involved: • Join the

    GraphQL and Apollo communities on Slack! • Contribute to GraphQL and Apollo on GitHub! • Use the #graphql hashtag on Twitter! • Show launchpad.graphql.com to a colleague. • Give a talk about GraphQL! • Organize a GraphQL meetup! @helferjs
  35. GraphQL vs Falcor Reasons to use GraphQL • supports arguments

    • has a type system + introspection • strong community • great tooling • implementations in more languages Reasons to use Falcor • simpler model for simple apps • out-of-the-box client caching @helferjs
  36. GraphQL vs OData Reasons to use GraphQL • easier to

    use and implement • supports arguments everywhere • strong community • better (and free) tooling • implementations in more languages Reasons to use OData • built-in server-side filtering • strong .NET support @helferjs
  37. Who is using GraphQL? @helferjs Add your logo at graphql.org/users

  38. We’re hiring! meteor.io/jobs Jonas Helfer @helferjs www.apollodata.com