Ask HN: Were you happy moving your API from REST to GraphQL?

Re:Ask HN: Were you happy moving your API from REST to GraphQL? by 013a on Thursday July 19, 2018 @11:37AM (#17567299)

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.

[ Parent | on HN ]

Re:Ask HN: Were you happy moving your API from REST to GraphQL? by brightball on Thursday July 19, 2018 @11:41AM (#17567338)

I’ve only heard positives about Absinthe for Elixir fwiw.

[ Parent | on HN ]

Re:Ask HN: Were you happy moving your API from REST to GraphQL? by 013a on Thursday July 19, 2018 @07:58PM (#17571407)

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.

[ Parent | on HN ]