4 ms·

Yes I've also seen a bunch of these apps with extremely chatty graphql calls because it's so convenient! One component just needs 2 pieces of data = graphql ca

Yes I've also seen a bunch of these apps with extremely chatty graphql calls because it's so convenient! One component just needs 2 pieces of data = graphql call. Another needs more data and they're doing another similar call. And so on. You got query flexibility but now you are drowning in additional network requests because it's so easy for your team to just "query for what they want". To me, if your application doesn't need to have the flexibility in querying, then it isn't worth it. Is your dataset so large you don't wish to overfetch data (you can do that without graphql anyway)? Do you need ad-hoc querying in your UIs? Think about your data, how you will need to expose it and expose it.

cercatrova 4y ago
Seems you're not familiar with recent advances. GraphQL servers have the ability to collate requests together and only redo a query when data changes instead of "whenever they want" because the client and server know exactly what data is used for which component. This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M https://www.youtube.com/watch?v=KT3XKDBZW7M
- exclusiv 4y ago
  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.
  - cercatrova 4y ago
    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-in-relay/ https://relay.dev/docs/principles-and-architecture/thinking-...
    - exclusiv 4y ago
      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.
      - cercatrova 4y ago
        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?
        exclusiv 4y ago
        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.

cercatrova 4y ago

Seems you're not familiar with recent advances. GraphQL servers have the ability to collate requests together and only redo a query when data changes instead of "whenever they want" because the client and server know exactly what data is used for which component. This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M https://www.youtube.com/watch?v=KT3XKDBZW7M

exclusiv 4y ago
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.
- cercatrova 4y ago
  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-in-relay/ https://relay.dev/docs/principles-and-architecture/thinking-...
  - exclusiv 4y ago
    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.
    - cercatrova 4y ago
      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?
      - exclusiv 4y ago
        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.