Hacker News Reader

Comment by lijok | Hacker News Reader

Can’t understand people’s obsession with client libraries. What need is there for a graphql client? Why is writing raw queries insufficient?

View on HN

Because people like to use typed languages and in that case writing raw queries makes you work against the typesystem essentially.

I see, so bindings for gql constructs is what we’re after?

Yeah. But since gql is very flexible, you then also want to combine them in an adhoc way but still get the right structure/types back. Then there is also batching, reusing inputs and so on, so ultimately a library saves a lot of time and effort when things grow bigger.

If you use OpenAPI/Swagger you can most likely generate the client code along with the types. I use the npm package below, and it just seems to work simply without any headaches.

https://github.com/hey-api/openapi-ts

so .. a matter of taste? Sure you enjoy swagger over the numerous GQL code gen alternatives.

I was responding to your point specifically about manually writing code in typed languages, highlighting that there are solutions to avoid that. I am not dismissing your use of GraphQL.

First, that was not me who you just responded to.

Second, I don't think it's very comparable. The big drawback of "RESTful APIs" is that you cannot combine things. You call an endpoint and you add some query parameters, that's pretty much it.

In Graphql, you can combine and even nest queries. You simply cannot (or don't want to) generate all combinations in advance, so you'll decide adhoc in your code. Therefore you need a library that can do these combinations adhoc for you in a typesafe way.

I would recommend to check out feTS[0], it infers the types from the endpoints without the need of generating files, I find this easier to work with because you don't have an extra step when the schema changes. I have to say I didn't used it yet, is on my radar to try it when the opportunity arrives.

https://the-guild.dev/openapi/fets

One thing I like about the codegen approach is that the generated code provides a snapshot of the changes through time in my Git history, which I refer to quite often.

Thanks for sharing feTS. It looks pretty awesome and I will be checking it out.

You want to execute a single query for a given page for performance. But whether a field is included in the query should depend on whether a component uses that field. If you write the raw query without fragments, you introduce implicit coupling between the query declaration and the subcomponents, which (like with REST endpoints, CSS classes, etc) means the query becomes append-only. Removing fields is dangerous and requires research, which devs on a Friday won’t do. Especially if you’re making changes to a component used across many pages.

Okay, so write fragments. However, without a framework like Relay (and soon Apollo), you still receive, at runtime, the entire network response. ie there is no masking at the fragment level. This means that there still is an implicit dependency between components, and removing fields is still dangerous.

That’s why you need Relay.

I make that case here - https://youtu.be/lhVGdErZuN4?si=tOJNWl-j-Uj28RUs

I used to think like you. Until I used and understood the Relay GraphQL library. The learning curve is a bit steep. But if you are consuming a lot of GraphQL data in a web browser, this is totally worth the investment.

GraphQL really shines with data intensive applications where you need pagination, filtering, sorting, projections etc.

Normalized caching, pagination, and code generation are some features that many developers find appealing and are supported out of the box by many GraphQL clients.

Reply on news.ycombinator.com