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
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.
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.
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?
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
What do I suggest for your architecture? GraphQL for Data gRPC for Logic DMN for Business Rules Distributed event-oriented programming OpenTracing & OpenCensus
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/
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.
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
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/
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/
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/
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
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
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
shah
shogo452
m3hiro3
matsujirushi
optim
kohbis
hcrane
keithyokoma
taka2noda
doradora09
jordihofc
whywaita
newrelic2023
robhawkes
jrom
jonrohan
dougneiner
davidbonilla
kevinliebholz
trallard
akmur
paulrobertlloyd
carmenintech
destraynor
sachag