Download to read offline
More Related Content
![[Ballerina Community Call] Java Interoperability](https://cdn.slidesharecdn.com/ss_thumbnails/ballerinacommunitycall4-javainteroperability-201209051002-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to GraphQL is actually rest
GraphQL is actually rest
- 1. If you knowwhat I mean GRAPHQL IS ACTUALLY REST
- 2. JAKUB RIEDL Software Engineer@iflix lead of GraphQL project
- 3. In we redefinetelevision for a billion people
- 4. WHY DO WENEED API?
- 5. WHY DO WENEED API? TO TRANSFER STATE BETWEEN BACKEND AND FRONTEND
- 6. 1999 SOAP HISTORY OF WEBAPI TECHNOLOGIES 2000 REST 2007 OData 2015 GraphQL Falcor 2013 JSON API
- 7. ● A protocol ●XML Based ● RPC methods ● Usually over HTTP or SMTP SOAP Standard Object Access Protocol (1999)
- 8. SOAP Standard ObjectAccess Protocol (1999)
- 9. ● Architectural styleintroduced by Roy Fielding in his PhD dissertation ● Most commonly uses JSON ● Centered around resources ● Usually over HTTP REST Representational State Transfer (2000)
- 10. ● Client -Server ● Stateless ● Cacheable ● Layered System ● Uniform Interface ○ Identification of resources ○ Manipulation of resources through these representations ○ Self-descriptive messages ○ Hypermedia as the engine of application state REST ARCHITECTURAL CONSTRAINTS
- 11. REST Representational StateTransfer (2000)
- 12. RESTful One endpointper resource Users CommentsPosts Browser AndroidiOS - Server centric Pros - Flexible - Easy to implement - Decoupled features Cons - Coupled BE w/ FE - Lots of roundtrips - Over-fetching - Inconsistent - Complex clients
- 13. - Client centric(ish) Pros - One round trip - Exactly what you need Cons - Inflexible - Inconsistent - Expensive - Slow to iterate REST-ish One endpoint per view (Backend for frontend) View A (web) View C (mobile) View B (web) Browser AndroidiOS
- 14. RESTful One gatewaywith resources Users CommentsPosts Browser AndroidiOS Standardized API Layer Pros - Flexible - Decoupled - No extra roundtrips - Consistent - Easier for clients Cons - Single point of failure - Perf overhead
- 15.
- 16. Users CommentsPosts Browser AndroidiOS Requirements -Client centric - Minimize roundtrips - Reduce data transfer - Flexible - Decoupled - Consistent ?
- 17. Users CommentsPosts Browser AndroidiOS RealRequirements - Fast to iterate - Time to market - Developer experience - Tooling - Docs ?
- 18. ● $select: choosewhich fields you want ● $expand: fetch related resources ● $top + $skip: pagination ● $filter (eq, lt, startswith, ...): server-side filtering ● $metadata: introspection + discovery ODATA “The best way how to REST” * * says Microsoft
- 19.
- 20.
- 21.
- 22. ● All datamodelled as a JSON object with references ● All values resolve asynchronously ● “Routes” determine how data is fetched ● Data is treated as graph ● Easy to learn & use ● No type system, no arguments ● Limited tooling FALCOR
- 23.
- 24. ● “The cleanway” ● Leverages features of HTTP (caching, content negotiation, ...) ● Not typed by default ● Limited tooling JSON API
- 25.
- 26. ● Easy-to-use querylanguage ● Strongly typed = consistent ● Very popular last months ● Great tooling ● Ready made clients ● Great developer experience ● Complexity comes with scale GRAPHQL
- 27.
- 28. ● Client -Server ● Stateless ● Cacheable ● Layered System ● Uniform Interface ○ Identification of resources ○ Manipulation of resources through these representations ○ Self-descriptive messages ○ Hypermedia as the engine of application state IS GRAPHQL RESTful?
- 29. ● Every object/resourcehas a globally unique id ● Every resource can be retrieved given its id NODE INTERFACE
- 30.
- 31. Uniform interface ● Identificationof resources ● Manipulation of resources through these representations ● Self-descriptive messages ● Hypermedia as the engine of application state GRAPHQL + NODE INTERFACE == RESTful
- 32.
- 33. WHAT TO CHOOSE? ITDEPENDS.
- 34.
- 35. SUMMARY REST IS NOTA STANDARD
- 36. SUMMARY REST IS NOTA STANDARD FOCUS ON YOUR NEEDS
- 37. THANKS TO JONAS HELFER:GRAPHQL - EVOLUTION OR REVOLUTION?
- 38.
- 39.