[itsjustjordan]

Like most technologies it depends on how you're using it. When I first starting working in GraphQL, paired with a React frontend I used it in an a similar way to REST, pull the data and then do all the logic of what to display on the frontend.

For me I saw the most benefit when I used the schema to define what to display in the frontend, all the logic of what to display is done on the server and my frontend just becomes simple components that render the pulled schema.

[rahimnathwani]

I didn't fully understand what your meant (as I haven't used graphql much), so I asked ChatGPT to explain. It did a decent job, so I figure the answer might help others as well: https://chat.openai.com/share/d708cc93-e920-4b83-b372-83248e...

[xwowsersx]

This seems completely backwards and contradictory to me:

""' Let's return to the user profile example. With GraphQL, instead of the frontend deciding what user data to display and where, this decision-making process can be moved to the server. When the GraphQL server receives a request for user data, the request includes specific fields that the frontend wants. In response, the server sends back exactly what was requested - no more, no less. """

First, it says that the server, instead of the FE decides. Immediately after, it says that "the request includes specific fields that the frontend wants".

If the request specifies the particular fields it wants, then it is the FE deciding what data to display...

So I think ChatGPT has this totally wrong. I'd love to be corrected here, but my understanding is that a (perceived) problem with REST, or at least the way it's used, is that the backend often requires specialized endpoint that anticipate the needs of a particular frontend context. In that sense, they are tightly coupled. This happens because, in order to avoid having to execute dozens of requests in order to fetch the data needed on a particular page or screen, you write some endpoint that is intended, from the outset, for a particular UI in the client app. You also have the opposite problem where an endpoint returns far more data than the client cares about in certain spots. Enter GraphQL: since the client queries for what it needs, it can specify precisely what it wants, ranging from a single nested field to a much more complicated object.

Note: I'm not judging the merits of this GQL pitch. I'm just saying that's the argument, as I've understood it. That being the case, not only is ChatGPT contradictory in the above cited section, but it also has the whole argument backwards.

As always, very glad to be corrected on any of this.

[rahimnathwani]

Yeah I had a similar reaction to yh first response. But after I asked a follow up 'But the frontend is still deciding what data to ask for', it gave me a better explanation and then an example.

That final part made it clear to me (assuming it's not a hallucination!).

[xwowsersx]

Huh. I'll read again and closer. I still think it may very well be wrong hah. This is a funny feeling when examining a ChatGPT response closely...you don't know if it's futile because it really just wrong or if there's more there. Maybe I'll continue the conversation with it to tease this out some more. Glad you shared the chat.

[pharmakom]

the server decides what's on the menu.

the client picks items from the menu

the server sends back exactly those items.

in REST, the server sends all of the items on the menu! as a result you end up creating many different menus.

[itsjustjordan]

I'll flesh out my comment a bit more with a small example of what I mean.

We have an inbox list that is a combination of three different entities (direct message, job request, support message), we display all of these in a unified inbox, rather than pulling all the data with REST and sorting through what fields to use to display as a title and what status maps to which styling/label etc. I can just use my InboxPageQuery and render exactly what it tells me to, being able to build or change entire pages just by pushing new server code really helps with speeding up our dev time.

  {
    "data": {
      "inbox": {
        ...
        "inboxItems": [
          {
            ...
            "subtitle1": {
              "__typename": "InboxStandardText",
              "accessibilityText": "Hi Jordan.\n\nSarah has posted a handyman job near you",
              "components": [
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": "Hi Jordan.\n\nSarah has posted a handyman job near you...",
                  "type": null
                }
              ]
            },
            "subtitle2": {
              "__typename": "InboxStandardText",
              "accessibilityText": "You declined this job today",
              "components": [
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": "Declined",
                  "type": "errored_text"
                },
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": " · ",
                  "type": "errored_text"
                },
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": "07/06/23",
                  "type": "errored_text"
                }
              ]
            },
            ...
          }
        ],
        ...
      }
    }
  }