Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Shopify Manages API Versioning and Breaking Changes

engineering.shopify.com

Post reply on HN
Print view View original

51–60 of 95 posts

Re: How Shopify Manages API Versioning and Breaking Changes

#51

Post by posedge »

keithwhor wrote: post #2

Hi everyone. As the founder of an API company, this article has me wondering about the semantics of versioning — so I thought I’d ask the community a question. I hope the Shopify API team doesn’t mind! When you all think about API versioning, what makes the most sense to you — a semver approach (major.minor.patch) a la NPM, or a date-based approach (2020-01-07) a la AWS? Or is some combination of the two desirable? A…

Honestly, I don't see what a non-semantic scheme brings to the table. In SemVer, you can (theoretically) infer compatibility from the version number. A date tells you nothing.

Re: How Shopify Manages API Versioning and Breaking Changes

#52

Post by MentallyRetired »

xal wrote: post #45
MentallyRetired wrote: post #16

Shopify made a change to their API that was easily measurable on who it would affect, but didn't email us. Refused to grant us a temporary exemption (they would do it for $2000/m they said). The end result? They've sunk my business. I've replaced shopify now by writing my own but it's too late. My customers have all gone to my competitors and we're looking at pivoting.

Can you share more details? I run Shopify and that's not something we would do.

Hi Tobi,

It was the change on limitations for variants. We woke up one day to product additions failing. Took about a week for the tech team to figure out that we were being throttled because we were exceeding 50k variants. Totally understandable in the bigger picture of things, but I didn't feel we received adequate warning. Developer support had told us that sometimes they grant temporary exemptions but in our case they refused. They advised we upgrade to shopify plus (they quoted us over $2000) to remove the throttling/limitation. Financially it was out of scope for us, so we had to throttle our own customers, which led to a massive disadvantage.

I ended up writing our own cart software, which was always part of the plan, but in the meantime our business suffered.

I don't hold any grudge about it since we were getting incredible value out of the previous arrangement, and I do think Shopify is amazing software. I've been a paying customer in multiple capacities since at least 2008 and recommend it to people all the time. What happened was just unfortunate timing for us.

Thanks for taking a minute to listen, though. Much appreciated.

Re: How Shopify Manages API Versioning and Breaking Changes

#53

Post by pc86 »

mr__y wrote: post #29
Judson wrote: post #3

It's interesting to compare and contrast this method of API management with Stripe. As far as I understand, the Stripe api would continue to work indefinitely so long as you lock your api version, whereas Shopify would eventually break the app as they essentially backport breaking changes to older api versions. Initially, I thought Stripe's method was superior, and would provide the best API experience, but realized…

>those apps continue to be updated and utilizing the latest features. while this is orthogonal to Shopify API or your post at all, since you mentioned the need of updates, I just wanted to use that opportunity to vent my frustration with the constant push to update everything all the time and judging any piece of software by using "when was the last update" as a metric. The problem I see is that not all apps or libs…

Well first of all I think it's a straw man to imply that anyone would want to send emails or share to Facebook out a ping utility. That's sort of a big thing that makes utilities different than applications.

Edit: I deleted a couple sentences and realize now this might not convey exactly what I meant. Utilities are easy to call "done," applications are not. Applications interact with external forces who do change constantly (other software, business processes, law and regulation, etc). I think in general, updating applications is a necessary thing, bordering on good, regardless of circumstances.

Re: How Shopify Manages API Versioning and Breaking Changes

#54

Post by pbreit »

mr__y wrote: post #29
Judson wrote: post #3

It's interesting to compare and contrast this method of API management with Stripe. As far as I understand, the Stripe api would continue to work indefinitely so long as you lock your api version, whereas Shopify would eventually break the app as they essentially backport breaking changes to older api versions. Initially, I thought Stripe's method was superior, and would provide the best API experience, but realized…

>those apps continue to be updated and utilizing the latest features. while this is orthogonal to Shopify API or your post at all, since you mentioned the need of updates, I just wanted to use that opportunity to vent my frustration with the constant push to update everything all the time and judging any piece of software by using "when was the last update" as a metric. The problem I see is that not all apps or libs…

I don't mind updates that are incremental and backwards compatible.

I LOATHE breaking changes. They are almost never actually necessary.

Re: How Shopify Manages API Versioning and Breaking Changes

#58

Post by bmn__ »

keithwhor wrote: post #2

Hi everyone. As the founder of an API company, this article has me wondering about the semantics of versioning — so I thought I’d ask the community a question. I hope the Shopify API team doesn’t mind! When you all think about API versioning, what makes the most sense to you — a semver approach (major.minor.patch) a la NPM, or a date-based approach (2020-01-07) a la AWS? Or is some combination of the two desirable? A…

> When you all think about API versioning, what makes the most sense to you — a semver approach (major.minor.patch) a la NPM, or a date-based approach (2020-01-07) a la AWS? Or is some combination of the two desirable?

We're talking about HTTP APIs, right? Then neither. These are solutions with bad trade-offs for the problem at hand.

Version the link relations. This follows the principles that make the Web successful (a.k.a. REST). If that seems weird to you¹, consider the following:

You have a personal homepage type Web site. When you change or add or remove a document, do your users need to upgrade their user agent to keep using the site? Why not?

----

¹ Numerous developers are so enamoured with putting a version number into document URIs that they cannot fathom not doing it. This is another mutilation of the mind à la Dijkstra.

Re: How Shopify Manages API Versioning and Breaking Changes

#59

Post by volkk »

MentallyRetired wrote: post #52
xal wrote: post #45

Earlier quoted context omitted.

Can you share more details? I run Shopify and that's not something we would do.

Hi Tobi, It was the change on limitations for variants. We woke up one day to product additions failing. Took about a week for the tech team to figure out that we were being throttled because we were exceeding 50k variants. Totally understandable in the bigger picture of things, but I didn't feel we received adequate warning. Developer support had told us that sometimes they grant temporary exemptions but in our case…

You couldn't pay the 6,000-8,000 for like 3-4 months and keep your business afloat until you rewrote it? Kind of sounds like your business was really really in the red already, or more information is missing?

Re: How Shopify Manages API Versioning and Breaking Changes

#60

Post by [deleted] »

rudasn wrote: post #47
gingerlime wrote: post #10

Earlier quoted context omitted.

Funny that you mention Stripe, because it was definitely the canonical backwards compatibility API for me. ... Until just recently in mid Nov they changed some behavior that caused us to double/triple/quadruple charge customers unintentionally in some not-so-uncommon edge cases... I’m still trying to square this one with their support, so details are a bit thin. But definitely a big surprise for me to see this happen…

Not sure if this helps but there was an issue with chrome submitting forms multiple times recently. It has been fixed in the recent 79 release.

[deleted]
Post reply on HN