GraphQL - Evolution or Revolution?

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