Actually, I also tried to move to GraphQL and still haven't a good fit yet. GraphQL queries are hard to translate to efficient SQL, and there are additional problems to tackle like authorization which is much complicated than the REST model.
Actually, I also tried to move to GraphQL and still haven't a good fit yet. GraphQL queries are hard to translate to efficient SQL, and there are additional problems to tackle like authorization which is much complicated than the REST model.
So what would be a 1 line request in REST format is now 100x longer and complex and why? It's an internal service so we weren't worried about reducing bandwidth costs (the problem FB was presumably trying to solve). I assume it was adopted because it's sexy and/or the developer wanted an excuse to use it.
I also wonder about the performance benefits if your data is in a SQL db...if you're running a no-SQL db then you can specify only the fields you want but I'm guessing a SQL db is likely to lock and read the entire row/record, even if it's only returning a subset of values.
If you're building a big, public-facing API or if people will only want a small subset of available data fields exposed by the API, GraphQL makes sense, but I feel like devs are swapping out easier-to-implement and use REST APIs just because GraphQL sounds cool.