GraphQL viewer-contextual queries on the top-level or within the viewer type?











up vote
0
down vote

favorite












When building the query and type graph structure in a GraphQL API, where would you put highly contextual queries that only apply to the viewer?



On the top-level (query.friendRequests)



This would remove noise in the User entity and only keep queries in there that are queryable for all users. Not just the viewing user.
It would add much more top-level queries with a risk of them becoming specialists in specific things which is not really thinking-in-a-graph and model-data-around-business-logic ideas.



On the viewer entity (query.viewer.friendRequests)



From a data perspective, this makes more sense to put it underneath the viewer entity (which is a User type). friend requests always belong to a parent object which is always a user.



Other Examples




  • Dashboard widgets

  • User notifications

  • Action items / TODO items / Task lists

  • Messages

  • Counters and badges


What are you guys' thoughts on this? What would be a good best-practice to follow for viewing user contextual queries that don't apply to other user entities in an API implementation?










share|improve this question


























    up vote
    0
    down vote

    favorite












    When building the query and type graph structure in a GraphQL API, where would you put highly contextual queries that only apply to the viewer?



    On the top-level (query.friendRequests)



    This would remove noise in the User entity and only keep queries in there that are queryable for all users. Not just the viewing user.
    It would add much more top-level queries with a risk of them becoming specialists in specific things which is not really thinking-in-a-graph and model-data-around-business-logic ideas.



    On the viewer entity (query.viewer.friendRequests)



    From a data perspective, this makes more sense to put it underneath the viewer entity (which is a User type). friend requests always belong to a parent object which is always a user.



    Other Examples




    • Dashboard widgets

    • User notifications

    • Action items / TODO items / Task lists

    • Messages

    • Counters and badges


    What are you guys' thoughts on this? What would be a good best-practice to follow for viewing user contextual queries that don't apply to other user entities in an API implementation?










    share|improve this question
























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      When building the query and type graph structure in a GraphQL API, where would you put highly contextual queries that only apply to the viewer?



      On the top-level (query.friendRequests)



      This would remove noise in the User entity and only keep queries in there that are queryable for all users. Not just the viewing user.
      It would add much more top-level queries with a risk of them becoming specialists in specific things which is not really thinking-in-a-graph and model-data-around-business-logic ideas.



      On the viewer entity (query.viewer.friendRequests)



      From a data perspective, this makes more sense to put it underneath the viewer entity (which is a User type). friend requests always belong to a parent object which is always a user.



      Other Examples




      • Dashboard widgets

      • User notifications

      • Action items / TODO items / Task lists

      • Messages

      • Counters and badges


      What are you guys' thoughts on this? What would be a good best-practice to follow for viewing user contextual queries that don't apply to other user entities in an API implementation?










      share|improve this question













      When building the query and type graph structure in a GraphQL API, where would you put highly contextual queries that only apply to the viewer?



      On the top-level (query.friendRequests)



      This would remove noise in the User entity and only keep queries in there that are queryable for all users. Not just the viewing user.
      It would add much more top-level queries with a risk of them becoming specialists in specific things which is not really thinking-in-a-graph and model-data-around-business-logic ideas.



      On the viewer entity (query.viewer.friendRequests)



      From a data perspective, this makes more sense to put it underneath the viewer entity (which is a User type). friend requests always belong to a parent object which is always a user.



      Other Examples




      • Dashboard widgets

      • User notifications

      • Action items / TODO items / Task lists

      • Messages

      • Counters and badges


      What are you guys' thoughts on this? What would be a good best-practice to follow for viewing user contextual queries that don't apply to other user entities in an API implementation?







      graphql api-design






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 21 at 23:56









      Sarah Henkens

      1




      1
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote













          We have always put it under a specific field in Query. First we started with a me query that would return a user. But this did not turn out very practical because the user type got very big and also most fields did not need the whole user object but only the user's ID. In your example we would have done two queries



          SELECT * FROM account WHERE id = $id
          SELECT * FROM friend_request WHERE account_id = $id


          Unless we would query a trivial field on the me query the first query was completely wasted.



          Then we got inspired a bit this thread and especially this answer from Lee Byron




          Viewer is what we used everywhere at FB, so it’s stuck with me. Also, a Viewer is not a User, it’s an Auth session - which references a User. So there’s a useful distinction of terms.




          Now we have a viewer query that returns a Viewer object. This object then has a field user to query the actual user object. This also might or might not help solving the problem around private and public fields on your user object.






          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',
            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%2f53422098%2fgraphql-viewer-contextual-queries-on-the-top-level-or-within-the-viewer-type%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote













            We have always put it under a specific field in Query. First we started with a me query that would return a user. But this did not turn out very practical because the user type got very big and also most fields did not need the whole user object but only the user's ID. In your example we would have done two queries



            SELECT * FROM account WHERE id = $id
            SELECT * FROM friend_request WHERE account_id = $id


            Unless we would query a trivial field on the me query the first query was completely wasted.



            Then we got inspired a bit this thread and especially this answer from Lee Byron




            Viewer is what we used everywhere at FB, so it’s stuck with me. Also, a Viewer is not a User, it’s an Auth session - which references a User. So there’s a useful distinction of terms.




            Now we have a viewer query that returns a Viewer object. This object then has a field user to query the actual user object. This also might or might not help solving the problem around private and public fields on your user object.






            share|improve this answer

























              up vote
              0
              down vote













              We have always put it under a specific field in Query. First we started with a me query that would return a user. But this did not turn out very practical because the user type got very big and also most fields did not need the whole user object but only the user's ID. In your example we would have done two queries



              SELECT * FROM account WHERE id = $id
              SELECT * FROM friend_request WHERE account_id = $id


              Unless we would query a trivial field on the me query the first query was completely wasted.



              Then we got inspired a bit this thread and especially this answer from Lee Byron




              Viewer is what we used everywhere at FB, so it’s stuck with me. Also, a Viewer is not a User, it’s an Auth session - which references a User. So there’s a useful distinction of terms.




              Now we have a viewer query that returns a Viewer object. This object then has a field user to query the actual user object. This also might or might not help solving the problem around private and public fields on your user object.






              share|improve this answer























                up vote
                0
                down vote










                up vote
                0
                down vote









                We have always put it under a specific field in Query. First we started with a me query that would return a user. But this did not turn out very practical because the user type got very big and also most fields did not need the whole user object but only the user's ID. In your example we would have done two queries



                SELECT * FROM account WHERE id = $id
                SELECT * FROM friend_request WHERE account_id = $id


                Unless we would query a trivial field on the me query the first query was completely wasted.



                Then we got inspired a bit this thread and especially this answer from Lee Byron




                Viewer is what we used everywhere at FB, so it’s stuck with me. Also, a Viewer is not a User, it’s an Auth session - which references a User. So there’s a useful distinction of terms.




                Now we have a viewer query that returns a Viewer object. This object then has a field user to query the actual user object. This also might or might not help solving the problem around private and public fields on your user object.






                share|improve this answer












                We have always put it under a specific field in Query. First we started with a me query that would return a user. But this did not turn out very practical because the user type got very big and also most fields did not need the whole user object but only the user's ID. In your example we would have done two queries



                SELECT * FROM account WHERE id = $id
                SELECT * FROM friend_request WHERE account_id = $id


                Unless we would query a trivial field on the me query the first query was completely wasted.



                Then we got inspired a bit this thread and especially this answer from Lee Byron




                Viewer is what we used everywhere at FB, so it’s stuck with me. Also, a Viewer is not a User, it’s an Auth session - which references a User. So there’s a useful distinction of terms.




                Now we have a viewer query that returns a Viewer object. This object then has a field user to query the actual user object. This also might or might not help solving the problem around private and public fields on your user object.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 22 at 9:44









                Herku

                2,155712




                2,155712






























                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422098%2fgraphql-viewer-contextual-queries-on-the-top-level-or-within-the-viewer-type%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

                    What visual should I use to simply compare current year value vs last year in Power BI desktop

                    How to ignore python UserWarning in pytest?

                    Alexandru Averescu