[cheriot]

GraphQL shifts complexity to the server instead of the client. That can be an advantage when there's multiple clients or just one client iterating faster than the underlying logic. There's certainly a short term cost to GraphQL compared to REST, but there's a lot of use cases with positive ROI outside FANGs.

When read and write becomes real time sync, though, I've always thought Firebase was under appreciated.

[vlozko]

I'm not entirely sure I agree that it shifts complexity. I think there's more complexity on both the client and the server end. I work extensively with GraphQL on the client end (iOS) and there's certainly more work involved compared to a REST endpoint for more larger applications. Notably:

* The mapping of the response to the types used in your app balloons. There's heavy use of Swift's Codable to map the JSON result to objects. I'm finding in a lot of cases where I'd be making queries and I don't need the resultant root object but rather a value one or two levels deeper. This has caused me to write a number of "shell" types to help streamline the decoding process.

* Different GraphQL requests can query for different fields on the same type, thus forcing your app to have to different types for arguably the same thing or have optional fields in more places that I would like.

* There's security implications with exposing your backend to any kind of request. GraphQL supports hashed queries so that the entire request isn't sent over each time and prevent the abuse that can result from an exposed API. Setting up and supporting this infrastructure takes some amount of resources.

* More complex to provide response metadata, such as cache control and request/response IDs. Granted, some of this could/should be moved to the response header but more complex types are trickier to handle.

That all being said, I'm quite happy with the trade offs compared to using REST, including:

* With REST, some of the endpoints ended up returning massive results as they had to support Android, iOS, and Web use cases. It's really hard to audit what fields were still in use by the app and the ROI on cleaning up the endpoints was minimal.

* Related to the above, it's easier to deprecate certain fields and make the changes on all the platforms appropriately. Given that GraphQL supports tracing of queries/fields usage, it's a lot easier to know when a field is no longer in use and be able to clean it up. Granted, this is more of a backend plus vs a client but it provides a much more smoother migration process for the client.

* Explicit declaration of non-null fields. Fantastic for mapping types. The entire GraphQL query fails if a resolver returns null for a non-null-defined field, giving the app a piece of mind with regards to type safety.

I agree there's definitely a short-term cost but a big ROI.