GraphQL: Nested queries vs root queries












2















I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.



Let's examine both in this example where the current user, me, has many invitations.



Root queries



me {
id
name
}

invitations {
id
message
}


The resolver for invitations returns invitations for the current user.



Nested query



me {
id
name
invitations {
id
message
}
}


These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.



What is the recommended way to design GraphQL queries?










share|improve this question



























    2















    I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.



    Let's examine both in this example where the current user, me, has many invitations.



    Root queries



    me {
    id
    name
    }

    invitations {
    id
    message
    }


    The resolver for invitations returns invitations for the current user.



    Nested query



    me {
    id
    name
    invitations {
    id
    message
    }
    }


    These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.



    What is the recommended way to design GraphQL queries?










    share|improve this question

























      2












      2








      2








      I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.



      Let's examine both in this example where the current user, me, has many invitations.



      Root queries



      me {
      id
      name
      }

      invitations {
      id
      message
      }


      The resolver for invitations returns invitations for the current user.



      Nested query



      me {
      id
      name
      invitations {
      id
      message
      }
      }


      These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.



      What is the recommended way to design GraphQL queries?










      share|improve this question














      I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.



      Let's examine both in this example where the current user, me, has many invitations.



      Root queries



      me {
      id
      name
      }

      invitations {
      id
      message
      }


      The resolver for invitations returns invitations for the current user.



      Nested query



      me {
      id
      name
      invitations {
      id
      message
      }
      }


      These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.



      What is the recommended way to design GraphQL queries?







      graphql apollo






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 3 at 17:06









      nomadodanomadoda

      480316




      480316
























          2 Answers
          2






          active

          oldest

          votes


















          2














          One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.



          So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.






          share|improve this answer

































            1














            I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.



            As a rule of thumb, it's better to think about consuming that API, not providing it.






            share|improve this answer
























              Your Answer






              StackExchange.ifUsing("editor", function () {
              StackExchange.using("externalEditor", function () {
              StackExchange.using("snippets", function () {
              StackExchange.snippets.init();
              });
              });
              }, "code-snippets");

              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "1"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54026744%2fgraphql-nested-queries-vs-root-queries%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              2














              One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.



              So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.






              share|improve this answer






























                2














                One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.



                So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.






                share|improve this answer




























                  2












                  2








                  2







                  One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.



                  So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.






                  share|improve this answer















                  One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.



                  So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Jan 4 at 8:59









                  xwlee

                  623721




                  623721










                  answered Jan 3 at 17:34









                  Ken ChanKen Chan

                  41.4k1596114




                  41.4k1596114

























                      1














                      I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.



                      As a rule of thumb, it's better to think about consuming that API, not providing it.






                      share|improve this answer




























                        1














                        I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.



                        As a rule of thumb, it's better to think about consuming that API, not providing it.






                        share|improve this answer


























                          1












                          1








                          1







                          I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.



                          As a rule of thumb, it's better to think about consuming that API, not providing it.






                          share|improve this answer













                          I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.



                          As a rule of thumb, it's better to think about consuming that API, not providing it.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Jan 6 at 21:33









                          Radosław MiernikRadosław Miernik

                          2,49132432




                          2,49132432






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Stack Overflow!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54026744%2fgraphql-nested-queries-vs-root-queries%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Monofisismo

                              Angular Downloading a file using contenturl with Basic Authentication

                              Olmecas