What is over-fetching?
Over-fetching is fetching too much data, meaning there is data in the response you don't use.
What is Under-fetching?
Under-fetching is not having enough data with a call to an endpoint, forcing you to call a second endpoint.
Results of Over-fetching and Under-fetching
Weather over fetching or under fetching, in both cases, they are performance issues: you either use more bandwidth than ideal, or you are making more HTTP requests than ideal.
In a perfect world, these problems would never arise; we would have exactly the right endpoints to give exactly the right data to our products.
These problems often appear when products scale and iterate. The data we use on pages often changes, and the cost to maintain a separate endpoint with exactly the right data for each component becomes too much.
So, we end up with a compromise between not having too many endpoints, and having the endpoints fit each component needs best. This will lead to over-fetching in some cases (the endpoint will provide more data than needed for one specific component), and under-fetching in some others (you will need to call a second endpoint).
Why Graphql?
GraphQL fixes this problem because it allows you to request which data you want from the server. You specify what you need and will get this data, and only this data, in one trip to the server.
In addition GraphQL enables you to:
- Aggregate data from multiple UI components.
- Create a representation of your data that feels familiar and natural (a graph).
- Ensure that all of your data is statically typed and these types inform what queries the schema supports.
- Reduce the need for breaking changes, but utilize a built-in mechanism for deprecations when you need to.
- Access to a powerful tooling ecosystem with GUIs, editor integrations, code generation, linting, analytics, and more.
We can try out GraphQL without rewriting entire application. For instance, starting with a single HTTP request that wraps an existing REST call. GraphQL schema and business domain model can expand gradually.
GraphQL and HTTP
GraphQL is typically served over HTTP. This is largely due to how common the HTTP protocol is in our industry. GraphQL can be tried by creating a single HTTP request. While HTTP is the most common choice for client-server protocol, it’s not the only one. GraphQL is agnostic to the transport layer. So, for example, we can use WebSockets for GraphQL subscriptions instead of HTTP to consume realtime data.
GraphQL with Microservices
We can integrate GraphQL into microservices architecture. However GraphQL docs recommend having one GraphQL schema as an API gateway rather than having the client talk to multiple GraphQL services. This way, the backend can be split into microservices, but then still aggregate all required data to the frontend from a single API.
There are many ways to create an API gateway. The benefit of using GraphQL is that we can take advantage of features like caching, request budgeting, and planning out query schedules.