Re:JrGQL, a GraphQL alternative
by lewisl9029 on Sunday August 13, 2017 @07:54PM
(#15005683)
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.
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.