Hacker News Reader

I've found the opposite. Designing a GraphQL API with the extended tail of important features has been an awful lot harder than with REST Apis.

That's not just in terms of idioms (which are useful for abstraction layer sake), but authorization, performance, all the sorts of things that are very known quantities, with extensive framework integration, in REST land. You get a lot farther with the wide ecosystem of tracing and monitoring tools, API gateways, authenticating proxies, all these API integration points and what have you in JSON api land.

In specific language ecosystems with a specific choice of tooling and libraries you can ultimately make good things happen, but it's not nearly as universal. Apollo is an obvious contender. I also like HotChocolate in the dotnet ecosystem.

There are definitely benefits. GraphQL having typed schematization by default is huge, and arguably that's the best feature. That's something you need to be more disciplined about in REST land (e.g. OpenAPI). But there's good tooling to be had on those fronts as well. Arbitrarily-shaped types definitely come with their own set of maintenance challenges versus more static DTOs.

P.S. HotChocolate's EFCore integration [0] is some of the coolest library tech I've seen. Thanks to C#'s builtin data projection functionality (via LINQ), it's able to automatically build a Hasura-style fully baked GraphQL API directly from your database domain model (which you can transform arbitrarily to limit / add additional functionality to via LINQ). It's still not my default choice in a new app, but if I were going to invest in GraphQL it's probably the strongest contender

[0]: https://chillicream.com/blog/2020/03/18/entity-framework

View on HN

1. to learn it, instead of blindly using code generated by your web framework 2. to think about your schema 3. to think about backward and forward compatibility, how you your schema will evolve 3. to apply CQS (Command/Query separation) 4. to think how to properly do pagination 5. to think about security 6. to think about error handling, error retries and idempotency of your mutations etc.