[Sytten]

What I really like with graphql that IMO all the other spec lack is a nice human readable format. When as a team you design a new API no way I am going to write openapi spec, but I can reason in GraphQL schema. Then each side takes the contract and go implement the frontend and the backend and it just works.

[junon]

There are many, many frameworks for IPC/RPC or even REST that have human-readable schemas.

GraphQL is a performance nightmare, and while it might have nice and flashy dev tooling, it's fundamentally unoptimizable without extensive development investment - something that isn't an issue with REST.

[lbhdc]

> GraphQL is a performance nightmare, and while it might have nice and flashy dev tooling, it's fundamentally unoptimizable without extensive development investment - something that isn't an issue with REST.

That feels really true. I worked on a really large gql api, and it was a performance nightmare, lots of 10+ second queries that thrashed our database.

Fine grained security was a nightmare. We found no existing solutions, and rolled a few different solutions for this that were all awful and leaky. Eventually we threw a bunch of money at h1 to tease it all out.

[Sytten]

Citations very much needed for REST. JsonSchema is not human readable. Some RPC yes but their support on web tech is meh (grpc-web for example is a mess).

Having written large code bases in graphql I really disagree with this statement. It is just a different mindset and I like it. It does make you think way more in terms of data and their relations instead of endpoints. Sure you might get N+1 problems but its easy to mitigate and I prefer doing that on the backend instead of the frontend doing those calls.

[CharlieDigital]

If you want to do that, try gRPC and Proto.

But I feel like REST and OpenAPI are fine especially if you start from the backend. I think with .NET Web APIs, the story is particularly good since it has out-of-the-box tooling for OpenAPI spec generation based on your exposed endpoints and models and then the option to customize that as needed.

I've recently been working with it trying to get hot reload working on the frontend client generation and it's a fantastic DX with minimal wiring: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit...

[Sytten]

Grpc browser support is pretty bad, I still can't wrap my head around the whole grpc-web thing that looks like giant hacks.

Openapi is not human readable IMO and the point is you design the API waaaay before you write any line of code. The api should express the business needs and be a two way discussion with the frontend people.

[CharlieDigital]

OpenAPI itself doesn't need to be human readable because it's readily translated into human readable form using tools like Redocly, RapiDoc, or any other host of tools that create output documents from input OpenAPI spec.

[dontlaugh]

There’s also Twirp, if gRPC doesn’t fit your requirements.

[nlarew]

> no way I am going to write openapi spec

I don't get the stubbornness here. OpenAPI is not hard??? It's just JSON schema + some routes and effectively conveys the same information as a GraphQL schema, possibly more if you're not using custom directives and such.

> Then each side takes the contract and go implement the frontend and the backend and it just works

This is not unique to GraphQL. There's almost zero difference between programming to an OpenAPI spec vs a GraphQL schema - they're both API interface definitions.

[gadflyinyoureye]

Auto generate the contract. That might be easier in some languages like TypeScript or Java, but it’s just done as part of the build.

[anttiviljami]

You don’t actually want that.

Code should not inform design.

Design informs code.

[gadflyinyoureye]

Use the code to do the design. Don’t implement the damn thing. Just work in a nicer medium like Typescript. Add attributes. Remove attributes. Move things around in the refactoring tool. Then generate the doc. Forget about the whole “this is what the database does” stuff.