So if a performance is a must for you and data fetching times are about 10 ms than REST should be a choice. For mutation operations the times for REST and GraphQL are similar. Lets now compare operations for data fetching and mutating for GraphQL and REST.įor notes list and details data fetching GraphQL average time is about 23 ms whereas for corresponding REST GET is about 14 ms. public class MutationGraphType : ObjectGraphType Įnter fullscreen mode Exit fullscreen mode First let's add such controller to Web API project: Here I'll show an approach with adding GraphQL endpoint via standard Web API controller. NET Web App you can add GraphQL to you app in a few ways: for example, via separate endpoint in your controller, adding your custom GraphQL Middleware or you can use NUGET package and add GraphQLHttpMiddleware or even Web Sockets Middleware. Is GraphQL API is a part of your Mobile and Web application or internal microservice?įor.Since GraphQL uses only one endpoint REST route-specific rules should be transferred into GraphQL schema rules: you may need to write authorization, throttling or caching logic in a separate layer. Will it be gateway for REST API or gateway for a number of GraphQL services (here you can expect n + 1 problem and it can be a challenge to design DataLoaders on your layers)? You also should consider here how authorization rules, throttling rates or caching timeouts should be handled.Do you plan design your GraphQL as a Gateway?.Do you plan to expose GraphQL endpoint as a data fetch from only one data storage source?.Do you expect search engines to index your URL (if so, than for these particular issue API REST has to be your choice: search engines do not index POST requests which are often used for sending GraphQL queries).There is API backward compatibility issues "underneath" and a problems for REST and GraphQL are similar - while REST API during development should be kept backward compatible or should be versioned, so GraphQL schema should evolve in the same way: it also has to be backward compatible with a previous schema (Let's imagine, that during developing of new functionality few old fields from new schema have been removed - from a client perspective the issue is the same as when you will remove a fields from a REST API - in both cases client will receive an error in response). If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API. When there's limited control over the data that's returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version.
While there's nothing that prevents a GraphQL service from being versioned just like any other REST API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema. REST API, on the other hand, bases on HTTP and defines a suite of URLs each of which expose a single resource using various HTTP verbs and HTTP error codes in compliance with REST API design standards, for example can be found them here. Obviously, GraphQL typically served over HTTP, and exposes one endpoint (that often designed to accept POST requests, but it is not a must) while it is an "entrypoint" for GraphQL queries: server returns the data that's queried by the client.
GRAPHQL VS REST PERFORMANCE OFFLINE
They are leveraging the technology to enable a consistent access experience across online, nearline, and offline environments.īut is GraphQL an alternative for REST or should be treated as an extension, what are the possible challenges that should be considered when choosing GraphQL? LinkedIn has organized its “economic graph” of relationships between users, using a unified graph to hide complex systems behind a simple GraphQL API.
GRAPHQL VS REST PERFORMANCE SOFTWARE
In 2019, Airbnb software engineer Brie Bunge said about 5.8% of all Airbnb traffic involves GraphQL, and she expected that number to reach 10% by the end of last year. In 2015 GraphQL had became open source, which resulted in growing GraphQL popularity also in fortune 500 companies:Įxpedia Group has moved away from its RESTful API strategy, which was causing hardships for development teams, in favor of a GraphQL approach. An idea was to increase the flexibility of client-server communication, especially for data fetching issues in their mobile apps.
In 2012 Facebook started GraphQL as an internal project.
0 kommentar(er)
