Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Does Anyone Like GraphQL?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Ask HN: Does Anyone Like GraphQL?

#31

Post by itsjustjordan »

rahimnathwani wrote: post #18
itsjustjordan wrote: post #14

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 beco…

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...

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"
                }
              ]
            },
            ...
          }
        ],
        ...
      }
    }
  }

Re: Ask HN: Does Anyone Like GraphQL?

#32

Post by csomar »

Here is a different perspective: I like GraphQL because it helps with communicating with other developers. I have lost count of the hours I spent trying to understand a REST API or find where the docs for the REST API are... Sometimes people just add an endpoint and that's that.

With GraphQL, there is a minimum of communication that it is done by the specs and the choices of the frameworks. There are some costs and downsides but for me they are definitively worth it.

Re: Ask HN: Does Anyone Like GraphQL?

#33

Post by prohobo »

I like it conceptually, but I never actually need it... So yeah.

Implemented a gql API a few times and it felt like it was more efficient than a typical REST API with all the caching and flexibility, as well as feeling more functional because of the handlers. That said, it's not that much better and many apps simply don't need it. Often it's okay to just have a "gimme everything whenever I want it" endpoint that sends 100KB of data.

I'd say graphql is useful when you're worried about requests killing your server.

Re: Ask HN: Does Anyone Like GraphQL?

#34

Post by n_e »

I'm very happy with GraphQL. We use it mainly for APIs that are consumed by several clients (web app, mobile app, other services).

The main benefit to us is that it's a huge time saver. There is almost no similar/duplicated code for similar operations (for example search, list and get operations). It's also very easy to write a generic API once, without thinking to much about how the clients will use it, and have it used in ways that weren't anticipated at the time it was written.

It's also pretty easy to have the API made of entities that are always the same, rather than having routes that return slightly different data.

Another benefit is that the default / basic tooling works well and with no setup. The playground works, it's easy to generate idiomatic clients in many languages, which is not really the case with openapi or grpc.

However, although I have no data to back this up, I feel that the adoption is not that high, and more advanced or unusual tooling doesn't exist or isn't very good or progressing.

Another problem is that developers don't seem to grasp the best practices intuitively and the docs don't make it very clear what they are, but it's necessary to use them to have a useful API and not a slow, more complicated version of REST.

Re: Ask HN: Does Anyone Like GraphQL?

#35

Post by danwee »

I don't. Not because of the idea of itself (I think the idea is good), but because of the implementation: we need yet another layer of abstraction to make it happen.

I would use GraphQL if it were natively supported (just like GET/POST/PATCH is, so no libraries on top needed).

Re: Ask HN: Does Anyone Like GraphQL?

#36

Post by danwee »

langsa wrote: post #12
sbegaudeau wrote: post #4

In my company, we are building a set of monolith applications based on frontend and backend modules that we can compose (Spring jars and React npm packages). As the maintainer of several of those modules, I don't know how my modules will be integrated in each monolith and I don't know exactly how all the complete frontend of each monolith will interact with each API. Having the ability to define small schemas for eac…

This is an interesting use case, I could see why GraphQL would be useful here where the contract between frontend and backend modules is not known in full and can change often. Out of curiosity, is the reason for the contract between these modules not being fully known / being able to change often because of how your company wants to use them or is there another reason? I'm just wondering if the reason for this is wa…

> This is an interesting use case, I could see why GraphQL would be useful here where the contract between frontend and backend modules is not known in full and can change often.

But that's a misconception. If your contracts between frontend and backend are not known, you cannot just "open" your backend resources to the frontend so they are queried at will. That creates a huge entanglement that is only discovered after years of maintenance (at the beginning it may seem as a huge boost in productivity, but it's just pure tech debt: the debt you pay for not designing contracts between frontend and backend)

Re: Ask HN: Does Anyone Like GraphQL?

#37

Post by n_e »

bern4444 wrote: post #30

GraphQL doesn't allow for recursive types. This limitation cropped up in a project and was a frustrating (re)discovery. You have to pick a maximum depth and explicitly define that depth. It abuses POST. No way to tell by a quick glance at the network tab the purpose of a request. Whichever team controls the implementation of the resolvers decides the return structure which may be less than ideal for the front end tea…

> GraphQL doesn't allow for recursive types.

It does, this schema works:

  type Item {
    id: ID!
    children: [Item!]!
  }

  type Query {
    root: Item!
  }
GraphQL queries describe the shape of the response, so with this schema it's not possible to ask recursively for "the full tree up to an arbitrary depth". One way to solve this would be to add a "descendants" field that returns a list of all the children, grand-children...

Re: Ask HN: Does Anyone Like GraphQL?

#38

Post by lakomen »

I think that it's one solution where there could be a much better one.

I use go with ent and the gql extension. The way it works, having hooks and privacy extensions is just so lovely. But querying is rather painful for me. It requires an additional tool, because I'm not used to the syntax. It feels very non-intuitive, but I'm rather at the beginning of it, so it's a me thing.

I was thinking why not just pure SQL queries as an alternative? All it would require is a proper filtering/security middleware.

Re: Ask HN: Does Anyone Like GraphQL?

#39

Post by quickthrower2 »

jokethrowaway wrote: post #16

After the initial hype and adoption, the middle managers who don't code still love it. Every other developer hates it. Pretty much like Redux or Facebook's ridiculous architecture before that (flux? Something?) I hear to more and more React and next.js hate everyday as well. Hopefully this is a sign we're ready for the next great thing in frontend. Not sure what it will be; personally I moved all the projects I can t…

The next big thing is Python-only frameworks that have react-like interfaces so you can do web dev without curly braces.

Re: Ask HN: Does Anyone Like GraphQL?

#40

Post by sbegaudeau »

langsa wrote: post #12
sbegaudeau wrote: post #4

In my company, we are building a set of monolith applications based on frontend and backend modules that we can compose (Spring jars and React npm packages). As the maintainer of several of those modules, I don't know how my modules will be integrated in each monolith and I don't know exactly how all the complete frontend of each monolith will interact with each API. Having the ability to define small schemas for eac…

This is an interesting use case, I could see why GraphQL would be useful here where the contract between frontend and backend modules is not known in full and can change often. Out of curiosity, is the reason for the contract between these modules not being fully known / being able to change often because of how your company wants to use them or is there another reason? I'm just wondering if the reason for this is wa…

We have a small core module with its core GraphQL schema and additional modules which are all extending this core module. We want to have the liberty to leverage those modules in various applications for the needs of our clients.

To give you some examples, in one use case our modules are used within desktop applications running locally, in a couple others they are used in regular web applications, in another they are embedded in a Java server running inside a VS Code extension (no network connection required everything runs locally). Sometimes we have our regular frontend modules which are performing some queries to our backend modules but in the VS Code extension for example, the VS Code integrations performs other kind of queries to our backend modules.

Each modules bring some capabilities and our projects can take those capabilities and reuse some or all of them.

Post reply on HN