Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is an astute question. I have only ever built a non-toy GraphQL server in 2016, for evaluation purposes. Never used in production.

Tooling back then was probably much more primitive than it is today, so apply that discount to the subsequent statements.

Writing GraphQL resolvers for the API that we were building was painful and required a solid understanding of our data model and what the database was capable of (we were using MongoDB). We were much happier at the time to stick to tried and true REST API tools and frameworks than to jump on the GraphQL bandwagon.

All the complexity of managing REST calls was simply pushed from the client side to the GraphQL resolution server. This complexity seems irreducible to me, and I am highly skeptical of anyone claiming that they can make this complexity vanish.

Have never so much as been tempted to use GraphQL since then. Unfortunately, this probably also marks my entry into dinosaur-hood.



> All the complexity of managing REST calls was simply pushed from the client side to the GraphQL resolution server

That itself is useful. It is much easier to manage complexity on a server that you control in the same datacenter as your DB in a language of your choice than it is in JS with limited bandwidth.


The easiest way for us to manage this complexity was to add new, simple, RPC endpoints to our vanilla API. It certainly wasn't worth adding GraphQL resolvers to the mix.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: