4 ms·

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

• valenterry 2y ago
  Because people like to use typed languages and in that case writing raw queries makes you work against the typesystem essentially.
  • lijok 2y ago
    I see, so bindings for gql constructs is what we’re after?
    • valenterry 2y ago
      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.
  • JoeyJoJoJr 2y ago
    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 https://github.com/hey-api/openapi-ts
    • tossandthrow 2y ago
      so .. a matter of taste? Sure you enjoy swagger over the numerous GQL code gen alternatives.
      • JoeyJoJoJr 2y ago
        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.
        • valenterry 2y ago
          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.
    • norman784 2y ago
      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 https://the-guild.dev/openapi/fets
      • JoeyJoJoJr 2y ago
        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.
• cheema33 2y ago
  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.
• rbalicki 2y ago
  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 https://youtu.be/lhVGdErZuN4?si=tOJNWl-j-Uj28RUs
• jdauriemma 2y ago
  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.