GraphQL - Evolution or Revolution?

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