Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: