How Shopify Manages API Versioning and Breaking Changes • Hacker News Board

Re: How Shopify Manages API Versioning and Breaking Changes

#91

Post by solatic » Fri, Dec 20, 2019, 1:01 PM UTC

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…

What's the point of a patch release for an API?

If you publish API version 1.0.0, and then internally you fix something and publish 1.0.1 (remember: a patch doesn't change the interface at all), should you continue to serve both the 1.0.0 and 1.0.1 APIs? How are they different from the consumer's perspective? What if your reason to release 1.0.1 is to fix a security issue - in what world is it ethical to continue to serve 1.0.0? If you can discontinue serving 1.0.0 at any time (because of a security patch released with 1.0.1), then you can't offer any long-term durability guarantees for early patch versions, and so indeed, offering older patch versions (when newer patches didn't fix security issues) is more likely to break your consumers when you're forced to discontinue older patch versions for security reasons, than if you refused to serve patch-level variants in the first place.

Because you, as upstream, have no control over whether the pure addition of fields will break downstream (since downstream may or may not be strict about what they accept), you should only offer semantically versioned minor releases if you're willing to guarantee durability for earlier minor versions, and can maintain multiple minor versions of your API in parallel. If not, then be explicit about the potential of your changes to break downstream - use timestamps and document sunset dates.

Re: How Shopify Manages API Versioning and Breaking Changes

#92

Post by volkk » Fri, Dec 20, 2019, 4:26 PM UTC

jdsully wrote: post #79

volkk wrote: post #59

Earlier quoted context omitted.

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?

Not everyone is in the “money is no object” startup economy. Outside of tech small businesses are actually small.

OP wrote that they have employees. if 6k-8k is too much for a company with employees to literally keep it running, that means it was months away from going completely bust anyway

Re: How Shopify Manages API Versioning and Breaking Changes

#93

Post by lol666 » Fri, Dec 20, 2019, 4:51 PM UTC

theturtletalks wrote: post #73

lol666 wrote: post #57

i know, i know, be constructive... but hey, shopify with +10k products is so slow they can version whatever they want...

At that point, I would use something like Gatsby which would build static pages for each of your product pages. You could host that on S3 with a CDN for cheap. You could downgrade the Shopify plan to $9/month since you're not going to be using their storefront.

thank you, but this doesnt solve the speed issues in my case. i could use sylius or any other ecom that i could host myself and use custom speedup on code instead of just on cdn:) shop i mean is in uk and has only uk customers, no need for cdn as customers arent spread globally or even on the continent.. as for static wouldnt that work for every solution? in that case theres no need for shopify at all... but as you say i could even keep static code generated and served from redis instead of s/hdd, that would be even faster

Re: How Shopify Manages API Versioning and Breaking Changes

#94

Post by stickfigure » Fri, Dec 20, 2019, 5:38 PM UTC

celticninja wrote: post #86

stickfigure wrote: post #83

Earlier quoted context omitted.

> ping...Why would anyone need to update it? How about being able to ping TCP ports? I need this for debugging all the time. Yeah, I use tcping instead... but why is this a separate tool? Dumb. I'm pretty sure that for every tool you think is "done", there's someone out there screaming at its inadequacy.

Do one thing, do it well. You could always bind tcping to a shorter alias or create your own ping that does what you need.

You think "one thing" is probe connectivity over ICMP and I think "one thing" is probe connectivity. Someone else could reasonably argue that "one thing" is probe the network.

People use this phrase a lot but I feel that they emphasize the wrong part. It's all about "do it well", no matter what you do.

Re: How Shopify Manages API Versioning and Breaking Changes

#95

Post by theturtletalks » Sat, Dec 21, 2019, 1:33 AM UTC

lol666 wrote: post #93

theturtletalks wrote: post #73

Earlier quoted context omitted.

At that point, I would use something like Gatsby which would build static pages for each of your product pages. You could host that on S3 with a CDN for cheap. You could downgrade the Shopify plan to $9/month since you're not going to be using their storefront.

thank you, but this doesnt solve the speed issues in my case. i could use sylius or any other ecom that i could host myself and use custom speedup on code instead of just on cdn:) shop i mean is in uk and has only uk customers, no need for cdn as customers arent spread globally or even on the continent.. as for static wouldnt that work for every solution? in that case theres no need for shopify at all... but as you s…

The main power of Shopify is the dashboard and the APIs. By having a custom storefront, Shopify just provides the APIs and a nice dashboard for non-programmers to use. You can also ditch Shopify later on since the storefront just builds off their API. Just my 2 cents. For $9/month, hosting something like Magento or even Woocommerce would be difficult.