Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GraphQL - Evolution or Revolution?

GraphQL - Evolution or Revolution?

Jonas Helfer

May 21, 2017
Tweet

Other Decks in Programming

Transcript

  1. GraphQL Europe, May 21 2017
    GraphQL - Evolution or Revolution?
    Jonas Helfer
    @helferjs
    Open Source Software Engineer, Meteor

    View Slide

  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

    View Slide

  3. Evolution or Revolution?
    @helferjs

    View Slide

  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

    View Slide

  5. Example: Building a Medium clone
    @helferjs

    View Slide

  6. A history of web API technologies
    SOAP
    1999
    REST
    OData
    2007
    GraphQL
    2015
    Falcor
    @helferjs

    View Slide

  7. Standard Object Access Protocol (1999)
    • A protocol
    • Centered around RPC methods
    • Uses XML
    • Usually over HTTP or SMTP
    @helferjs

    View Slide

  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

    xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
    soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">


    apollographql



    @helferjs

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  17. OData Request
    GET /PostsServiceRW/RecentPosts?$top=3 & $select=Title, Text &
    $filter=Org/any(d:d/Name eq apollographql) HTTP/1.1
    OData-Version: 4.0
    OData-MaxVersion: 4.0
    @helferjs

    View Slide

  18. OData Response (Example)
    @helferjs

    View Slide

  19. XOData — OData’s GraphiQL?
    @helferjs

    View Slide

  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

    View Slide

  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

    View Slide

  22. GraphQL
    query {
    recentPosts(limit: 3) {
    title
    text
    recommends {
    totalCount
    }
    author {
    name
    }
    }
    }
    @helferjs

    View Slide

  23. GraphQL
    • Easy-to-use query language
    • Get exactly what you need
    • Type System
    • Advanced tooling
    • Resolver runtime
    @helferjs

    View Slide

  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

    View Slide

  25. Node interface
    • Every object/resource has a unique id
    • Every resource can be retrieved given its id
    @helferjs

    View Slide

  26. Node interface query
    query {
    node(id: “74fe64c356c2”)
    … on Post {
    title
    author {
    name
    }
    }
    }
    @helferjs

    View Slide

  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

    View Slide

  28. And the winner is …
    @helferjs

    View Slide

  29. GraphQL!






    @helferjs

    View Slide

  30. Why GraphQL is winning
    • Straightforward query language
    • Amazing tooling (GraphiQL, Apollo Launchpad, …)
    • Stronger developer story than Falcor, OData
    • Strong community
    • Incremental adoption
    @helferjs

    View Slide

  31. Evolution or Revolution?
    @helferjs

    View Slide

  32. Technical evolution
    @helferjs

    View Slide

  33. Social revolution

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  37. Who is using GraphQL?
    @helferjs
    Add your logo at graphql.org/users

    View Slide

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

    View Slide