Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

What comes after REST?

What comes after REST?

An opinionated view of GraphQL and other emerging API approaches for more reliable and flexible systems integration.

Shahid N. Shah

October 12, 2018
Tweet

More Decks by Shahid N. Shah

Other Decks in Technology

Transcript

  1. What comes after REST? AN OPINIONATED VIEW OF GRAPHQL AND

    OTHER EMERGING API APPROACHES FOR MORE RELIABLE AND FLEXIBLE SYSTEMS INTEGRATION BY SHAHID N. SHAH
  2. Audience poll REST? Swagger / OpenAPI? SOAP? oData? ORDS? GraphQL?

    Falcor? gRPC? CORBA? Microservices? DLL Hell? Microservice Hell!
  3. REST has served its purpose for data access Application-centric approaches

    have mostly migrated to a more data-centric and integrated systems strategy. Re-engineering workflows from internal user targets to include users across multiple stakeholders, multiple institutions, and disparate systems using REST based APIs has been successful. As number of endpoints and integrated systems have increased, reliability and flexibility appear to be suffering.
  4. What’s wrong with REST for data queries? Transport, security, business

    logic, and data transfer are more coupled than appropriate. Most of the protocol is driven by convention rather than type-safe verifiable specifications. We’re so afraid of making changes that we create data layers upon data layers leading to microservices hell.
  5. We need something like SQL over a unified data space

    This sucks: GET /search/user/?name=Shahid GET /search/user/?name=Shahid|Yuvi GET /search/user/?name=Shahid|Yuvi&limit=10&offset=20 POST – how do you consistently mutate data vs. execute business logic? PUT – how to you update a single field of a 2 megabyte blob? PATCH – really?
  6. What’s a consistent public API-focused way to manage complex data

    tasks? Select / Join Filter Order Aggregate Page Metadata Schema Version
  7. Major issues facing data API strategies Discovery Registry Documentation Type

    safety Coupling Chattiness over fetching under fetching -> N+1 Idempotency Mutability Traceability Metrics Portability (of code & devs) Monetization
  8. What do I suggest for your architecture? GraphQL for Data

    gRPC for Logic DMN for Business Rules Distributed event-oriented programming OpenTracing & OpenCensus
  9. GraphQL is a query language for APIs GraphQL is a

    query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. As data storage on servers via databases gets more complex (e.g. hierarchical) and data consumption via mobile apps, web pages, reporting tools, etc. needs growing flexibility, standard REST APIs endpoints begin to get unwieldy. A single GraphQL endpoint exposes a typed and validatable data schema to the client, and the client can request only what it needs (similar to SQL). Source: http://graphql.org/
  10. GraphQL myths and misconceptions Nothing to do with graphs or

    graph databases. Not a tool or graph database but a specification. GraphQL will do for arbitrary back ends what Structured Query Language (SQL) did for relational databases. Will not replace REST, but does simplify it and gives it more value for data-heavy use cases. Is language agnostic and can be used in legacy and green field projects. Is transport independent, neutral to message protocols, not opinionated, and data store agnostic.
  11. Why another query language? As data storage on servers via

    databases gets more complex (e.g. hierarchical) and data consumption via mobile apps, web pages, reporting tools, etc. needs growing flexibility, standard REST APIs endpoints begin to get unwieldy. A single GraphQL endpoint exposes a typed data schema to the client, and the client can request only what it needs (similar to SQL). GraphQL is to REST what SQL was to ISAM tables. https://graphql.org/learn
  12. Modern, less brittle data APIs Data structures defined and secured

    at server but shaped by client Data structures strongly typed, relational, and hierarchical Data structures are decoupled from applications and are extensible across versions Source: http://graphql.org/
  13. What makes GraphQL special? Data producers decide what data is

    possible at the server but consumer can shape the data they need at the client. Send a GraphQL query to your API and get exactly what you need, nothing more and nothing less. GraphQL queries always return predictable results. Apps using GraphQL are fast and stable because they control the data they get, not the server. GraphQL creates a uniform API across your entire application without being limited by a specific storage engine. Write GraphQL APIs that leverage your existing data and code with GraphQL engines available in many languages. You provide functions for each field in the type system, and GraphQL calls them with optimal concurrency. Source: http://graphql.org/
  14. The GraphQL architecture and ecosystem are made up of the

    following components: 1. Specifications, shared concepts and knowledge management supports. 2. Authentication. 3. Backend-as-a-service providers. 4. Schema Design tools. 5. Server-side libraries and tools. 6. Client-side frameworks and tools. https://thenewstack.io/graphql-data-query-language-resource-guide/
  15. GraphQL vs. REST Smackdown Schema-first, not transport first Client decides

    data access, not server Strongly typed, custom user types JSON-native nesting Introspection and auto documentation Versioning not required Code generation friendly
  16. Some slick tools to get you going Swagger2GraphQL Postgraphile for

    auto-generating full HTTPS-accessible GraphQL for any PostgreSQL database rejoiner for combining multiple gRPC endpoints into GraphQL
  17. Next steps Kill data access microservices, in favor of GraphQL

    Implement smarter data access with GraphQL Subscriptions / Streams Kill business logic microservices in favor of mutable GraphQL Kill business logic microservices in favor of gRPC when GraphQL underperforms Implement observability using OpenCensus, OpenMetrics and OpenTracing