Hacker News new | ask | show | jobs
by 013a 2886 days ago
It makes many things easier and many things harder. The lack of really good backend libraries/frameworks outside of NodeJS is the most concerning thing.

Also; debugging and monitoring GraphQL APIs sucks. Considerations:

- Any subfield of a query can throw an error, but the rest of the fields can succeed, because GraphQL frameworks are allowed to run each field resolver asynchronously.

- Because of this, any GraphQL query is capable of returning multiple errors.

- Rate limiting is exceedingly difficult due to nested resolvers. I've seen solutions which involve annotating your schemas with "cost" numbers, and only allowing each query to run up to a maximum "cost" before failing by dynamically adding the costs of each field they request. Traditional rate limiting doesn't work.

- Traditional APM platforms also don't work. Prepare to adopt Apollo Engine and pay them $600/month on top of the money you're already paying New Relic or Datadog.

1 comments

I’ve only heard positives about Absinthe for Elixir fwiw.
The three biggest frameworks are definitely Apollo (JS), Graphene (Python), and Absinthe (Elixir).

The common thread between those is that they're all languages with weak type systems, which is a theme in GraphQL land. Strongly typed languages tend to have usability and safety issues with GraphQL; you end up needing codegen or bypassing type safety to make it work.