Ask HN: Does Anyone Like GraphQL?

Being able to co-locate data queries with components in React has been a huge game changer for me when writing reasonably complex frontend apps. However, GraphQL on its own never struck me as being any more beneficial than Rest.

It's only for side projects, but I personally prefer this type of approach over both REST and GraphQL.

You just have to think of it as another function.

In addition I define contract using TypeScript code something like this:

defineOperation('getPosts', { input: { filters: dataTypes.array(...) }, output: dataTypes.array(dataTypes.object({ id: dataTypes.uuid(), title: dataTypes.string()}) })

And this generates typed backend function handler and a frontend client function. Backend is TypeScript also, but it could generate for any language in theory.

I also generate database entities like that, and auto create migrations, etc. You could in theory add documentation into that defineOperation as well.

Very simple, and very smooth in my view. Also debuggable since it's text based (using POST method) with json { "operationName": "getPosts", { "filters": ... }}

In frontend I will have a generated, typed function I can use client.getPosts

and in the backend I just have to define export const getPosts: GetPosts = (requestManager) => ... where GetPosts type is generated.

It's because I think REST methods don't make much sense and the endpoints are arbitrary, in the end it's just easier to reason of everything as a function.

I also don't particularly like how GraphQL forces you into this certain mindset, that feels like in many cases it holds you back rather than makes you productive.

Maybe I was bad at defining REST interfaces. But the interface-definition-language aspect of GQL has been invaluable. It's type safety across the network boundary.

Our server side library auto generates DTO structs to satisfy the schema resolvers. It just removes a lot of boilerplate work when adding routes or new return types.