4 ms·

> As far as the versioning goes, the prevailing wisdom seems to be that it just isn't needed on graphql apis In reality, of course API versioning is needed. T

> As far as the versioning goes, the prevailing wisdom seems to be that it just isn't needed on graphql apis In reality, of course API versioning is needed. The "prevailing wisdom" is people who like the tool, don't like its limitations, and want to pretend it isn't a problem. . > That said, versioning of a graphql api has been done at scale before. Shopify has done it Perl people will happily point out that object systems exist for Perl. Having it not be a standard, uniform part of the core tool is a severe limitation. Shopify needed this rudimentary feature, and tried to give it away because others need it to, and the tool vendors aren't willing (or able) to deliver.

PUSH_AX 4y ago
> In reality, of course API versioning is needed. I’d recommend not picking a technology that is versionless by design if you think you’re going to need it. Also I’d dispute that versioning is needed as a rule.
- JohnHaugeland 4y ago
  > I’d recommend not picking a technology that is versionless by design if you think you’re going to need it. I mean, I don't pick GraphQL, and this is just one small part of why. Every place that I've ever worked that's attempted to adopt GraphQL has rapidly given it up. . > Also I’d dispute that versioning is needed as a rule. The IEEE once measured peoples' expectations regarding how necessary versioning was, and got a response of something on the order of 40%. There was an uproar, and a whole bunch of people on both sides of the topic tried to call bullshit. Some middle manager somewhere sent in a letter that said approximately "how about you write a follow-up article where you bin the responses by years of experience?" The rest of the story writes itself.
krschultz 4y ago
FB is pretty much on V1 of its GraphQL API with tens of thousands of engineers editing it for over a decade. Every single query is its own version, that's the point. If you want to change the semantics of a field, make a new field and leave the old one for the existing clients. What else would you have to version?
- hu3 4y ago
  We're not Facebook

PUSH_AX 4y ago

> In reality, of course API versioning is needed. I’d recommend not picking a technology that is versionless by design if you think you’re going to need it. Also I’d dispute that versioning is needed as a rule.

JohnHaugeland 4y ago
> I’d recommend not picking a technology that is versionless by design if you think you’re going to need it. I mean, I don't pick GraphQL, and this is just one small part of why. Every place that I've ever worked that's attempted to adopt GraphQL has rapidly given it up. . > Also I’d dispute that versioning is needed as a rule. The IEEE once measured peoples' expectations regarding how necessary versioning was, and got a response of something on the order of 40%. There was an uproar, and a whole bunch of people on both sides of the topic tried to call bullshit. Some middle manager somewhere sent in a letter that said approximately "how about you write a follow-up article where you bin the responses by years of experience?" The rest of the story writes itself.

krschultz 4y ago

FB is pretty much on V1 of its GraphQL API with tens of thousands of engineers editing it for over a decade. Every single query is its own version, that's the point. If you want to change the semantics of a field, make a new field and leave the old one for the existing clients. What else would you have to version?

hu3 4y ago
We're not Facebook