[reggieband]

I'm not 100% sold on GraphQL but the teams I work with are moving towards it. It does help a bit with micro-service architectures since you'd be writing some API interface to abstract potentially dozens of services anyway. After the pain of writing all of the necessary bindings/schemas/models or whatever they all are it is convenient at least on the calling side. The web GUI for testing out schema's comes in very handy.

The pain I've felt is with API versioning. Someone set a type for a parameter wrong, it was a union between int and string but the original implementation was only typed for int. Since it was sent out to production that becomes too risky to change since the call will fail if the param type is wrong, even though the underlying JS would have handled ints and strings just fine.

Overall it is a pretty neutral technology for me. The benefits and determents seem to balance just enough that I'm not going to pick that battle to fight against it. So while I agree it doesn't add as much value as the hype might suggest, it also doesn't detract enough to worry about.

[lewisl9029]

The versioning problem can usually be resolved fairly elegantly by versioning on a field-by-field level, i.e. adding a new field called x-v2 and serve it alongside x without removing the original. You can add some kind of a deprecation warning to x to dissuade new clients from using it.

With this approach you can end up with a somewhat noisy schema, but for public APIs it's usually worthwhile to just keep the old versions forever to avoid breakage. For private APIs, with good tracking, you can find out when the original field stops getting requested, and clean up your schema then with relatively little risk.

[chung705]

I guess in terms of deprecation, it is not a unique characteristic to GraphQL, it happens to RESTful APIs as well.