Hacker News Reader

Comment by exclusiv | Hacker News Reader

That doesn't prevent your frontend and components from making a ton of extra network requests because graphql makes it easy for frontend devs to do fire a new query for their component.

Simple example:

1. header component - dev queries user for first name to do a welcome message.

2. sidebar component - another dev does a query for first/last/avatar/profile/etc.

Your app sends 2 network calls. Certainly it doesn't have to, but I've seen this chattiness get implemented.

So you avoided overfetching of data like official REST APIs but now you have more network calls.

View on HN

Yes, it does. As I explained, GraphQL servers can see which requests should be collated and deduplicated and puts them all into one request. For example, Relay:

> Relay combines the advantages of both of these approaches by allowing components to specify what data they require, but to coalesce those requirements into a single query that fetches the data for an entire subtree of components. In other words, it determines statically (i.e. before your application runs; at the time you write your code) the requirements for an entire view!

> This is achieved with the help of GraphQL. Functional components use one or more GraphQL fragments to describe their data requirements. These fragments are then nested within other fragments, and ultimately within queries. And when such a query is fetched, Relay will make a single network request for it and all of its nested fragments. In other words, the Relay runtime is then able to make a single network request for all of the data required by a view!

https://relay.dev/docs/principles-and-architecture/thinking-...

Ok but I'm talking about your client application sending multiple network calls at different times. How does the server prevent that? It doesn't.

In order to prevent the frontend from doing that, I have to be sure to enforce usage of another layer. Devs need to use fragments and relay and not just fire off their own ad-hoc graphql queries.

Which is interesting, and thanks for sharing. I would move toward implementing this on any graphql project, especially an inherited, network chatty graphql project.

But I still prefer keeping the frontend really dumb and just sending the data it needs, that has been identified.

Most of the time a REST or REST like API endpoint is sufficient, and it doesn't matter if you overfetch some data, you avoid extra graphql layers (now enforcing fragments/relay, extra resolvers, potential performance issues, multiple schemas and access concerns).

I like GraphQL but it seems like a lot of overhead for little gain for many projects. One project has 3 different graphql schemas. Can't be exposing the whole tree to every user type.

I can see why frontend devs would like it though (need this data, probably already available), but a REST or REST-like API is more enjoyable for me unless I'm building a framework or on top of a framework or a client that needs ultimate ad-hoc query ability where it really shines to me.

By that logic even a REST endpoint server can't stop people from making network calls at different times. How would you even stop that, simply make people wait until a set time before collating and sending out the data?

I don't see frontends using REST servers doing what I see with GraphQL.

UI using REST server tends to centralize the API client, call the endpoint(s), and make that available to all components.

UI using GraphQL often has frontend devs doing their components, running their ad-hoc queries for "just what they need". More network calls.

So overfetching like with REST tends to lead to less network calls unless you are extra diligent on a GraphQL project.

Reply on news.ycombinator.com