GraphQL as an API gateway in microservices architecture - Shipra Gupta

Показать описание

Have you heard of the term GraphQL, and not sure what it is about? Ever had to choose between API comfortable for users and “the right REST” API? Does your client make multiple rest requests corresponding to one click on UI? One backend service and multiple clients with different data requirements because of which you end up overfetching or underfetching the data? Do you own and maintain a fleet of REST endpoints and are tired of constantly checking with the client teams, on the usage of these endpoints or on the return types in the responses? Do you want to remove client teams’ dependencies on API teams? Did you have to maintain different versions of an api? ##REST vs GraphQL With a REST API, you would typically gather the data by accessing multiple endpoints. In the example, these could be /users/ endpoint to fetch the initial user data. Secondly, there’s likely to be a /users//posts endpoint that returns all the posts for a user. The third endpoint will then be the /users//followers that returns a list of followers per user. In GraphQL on the other hand, you’d simply send a single query to the GraphQL server that includes the concrete data requirements. Advantages Increased performance minimizes server round trips by aggregating data(schema stiching) from multiple source in a single request which reduces network overhead Optimum Payload- No more overfetching or underfetching of data by specifying the required data. Conditionally load or mutate data according to different client needs using resolvers. Increased developer experience With GraphQL, Client engineers don’t have to spend time to ask the API team to add or modify something. GraphQL is self-documenting which means less time trying to figure out how to use an undocumented API. Client engineers have all the control and request only things they need without modifications on the backend. This is truly liberating. Evolve your API without versions In GraphQL there are no API versions as there used to be in REST. Add new fields and types to your GraphQL API without impacting existing queries. Aging fields can be deprecated and hidden from tools. Thus a client receives a deprecation warning when querying a deprecated field. After a while, the deprecated field may be removed from the schema when not many clients are using it anymore. By using a single evolving version, GraphQL APIs give apps continuous access to new features and encourage cleaner, more maintainable server code. Improved Security, Strong Types and Validation GraphQL schemas are defined using the GraphQL Schema Definition Language (SDL). This schema serves as the contract(Single source of truth) between the client and the server to define how a client can access the data. Once the schema is defined, the teams working on frontend and backends can do their work without further communication since they both are aware of the definite structure of the data that’s sent over the network. GraphQL offers enhanced security over JSON RESTful APIs for two main reasons: a strongly typed schema (e.g., data and type validation) and an ability to filter sensitive data (no unintentionally leaked data). Graceful degradation during a service outage In microservices, it is common that requesting data fails because one of the underlying services is temporarily unavailable. GraphQL solves this problem elegantly by allowing resolvers to report errors to the client without terminating the entire request. In this way, clients can be made aware of service outages when requesting data, and react to the data that is available. Then they can potentially retry only the failing portion of the request at a future time by simply modifying the client query to backfill the missing data. Rich open source community Today, reference implementations of the GraphQL specification are available in various languages and there’s a plethora of GraphQL clients. In addition, lots of tooling provide seamless workflows and make for an amazing developer experience when building GraphQL APIs.