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.
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.
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?
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/
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.
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
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/
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/
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