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

I think you’re right about it being suited to well-defined scenarios. But I agree too that a regular endpoint to get specific data is more often than not totally acceptable. I’m not aware of many situations where the flexibility of graphql is as useful or important as the demands it places on a team.

I worked on a team where 3 of us were well into our second decade of software development, yet we still had a consultant come in to help us sanity check our graphql implementations and ongoing strategy.

We were mostly on the right track. The struggles we were having were just… Normal.

At that point I really lost steam. Prior to that I was motivated by the thought that something wasn’t clicking yet. Discovering that I understood graphql just fine but it was typically a bad developer experience with obtuse tooling and queries took the wind out of the sails.

The worst part was mutations.

Writing graphql handlers in Rust was also awful. The more you try to leverage the flexibility of graphql, the more Rust freaks out because you’re doing exactly what you shouldn’t in such a strict environment.

Yet… Doing this in a language with weaker typing and less strictness seems like a potential minefield of bugs.

I see the appeal of graphql and I’ve liked it in small one-off situations where it was useful but had limited scope. Otherwise I genuinely hope I don’t work with it again.



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

Search: