4 ms·

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

by Judson 7y ago

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 that Stripe and Shopify have different incentives w/r/t their api. For Stripe, breaking a functioning site harms revenue, and generally the developer is the Stripe customer. For Shopify, their customer is the store owner, and for the most part, the store will continue to function because that is mostly controlled by shopify. The developer api is for added functionality, and it is in the interest of Shopify and the merchant that those apps continue to be updated and utilizing the latest features. So, two different ways of managing breaking changes, but both are ultimately centered around providing the best customer experience.

gingerlime 7y ago
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 happening when previously I never imagined something like this can happen given the API versioning stability.
- Judson 7y ago
  You know, you just jogged my memory here. We did have an issue with Stripe changing the order / timing of payment_failed webhooks, which caused them to be sent before the next payment attempt was known. We used the payment failed hook to send an email to our customers and let them know when we'd be retrying the charge, which was no longer possible because the next_payment_attempt field was null. Before the change, a next_payment_attempt=null meant the charge would not be retried. I reported the issue and the webhook changes were rolled back a month later. Really threw a wrench into our flow. I will say that generally speaking, Stripe is the canonical backwards compatibility API in my mind. With a few edge cases.
- rudasn 7y ago
  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 7y ago
    [deleted]
  - gingerlime 7y ago
    It’s not that. Purely a Stripe backend change in this case. They confirmed it but I’m still waiting for more details.
mr__y 7y ago
>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 need (frequent) updates, many (maybe most) do need them, but some don't. They provide some functionality, they do that well and you could call them "complete". Maybe some security fix could be needed from time to time, but with a mature code being in use for many years event those are not frequent. For example, consider something like ping utility. It does what it does for many decades. There was a need to add IPv6 support, but that was almost two decades ago. Why would anyone need to update it? I do not want any additional functionality, I don't want it to send emails or have social media share button. I want it to send ICMP echo requests and receive ICMP echo replies and nothing more. Aside from some security fixes no updates should be needed for 10+ years. This utility is done. It should not be thrown upon just because there were no updates for many years. While of course neither ecommerce or Shopify platform are "done" and they get many updates now and will get updates in future it does not mean that some functionalities could have reached "done" stage. For a "complete and done" addon, there could be a need for a security fix from time to time. There could be a need for some adjustments if a major browser introduces a new deviation from JS/CSS/HTML standards and forces everyone to update their code. But those events happen from time to time, possibly not that frequently. This means that some addon/plugin would not require any updates during the periods between those events and those periods could be many months/years long. But hey: "this addon did not receive any updates for 13 months, it must be really bad and should be avoided". This leads to a situation where a competing solution with tons of bugs will look better just because it receives two updates a week.
- pc86 7y ago
  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.

by Judson 7y ago

gingerlime 7y ago

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 happening when previously I never imagined something like this can happen given the API versioning stability.

Judson 7y ago
You know, you just jogged my memory here. We did have an issue with Stripe changing the order / timing of payment_failed webhooks, which caused them to be sent before the next payment attempt was known. We used the payment failed hook to send an email to our customers and let them know when we'd be retrying the charge, which was no longer possible because the next_payment_attempt field was null. Before the change, a next_payment_attempt=null meant the charge would not be retried. I reported the issue and the webhook changes were rolled back a month later. Really threw a wrench into our flow. I will say that generally speaking, Stripe is the canonical backwards compatibility API in my mind. With a few edge cases.
rudasn 7y ago
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 7y ago
  [deleted]
- gingerlime 7y ago
  It’s not that. Purely a Stripe backend change in this case. They confirmed it but I’m still waiting for more details.

mr__y 7y ago

>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 need (frequent) updates, many (maybe most) do need them, but some don't. They provide some functionality, they do that well and you could call them "complete". Maybe some security fix could be needed from time to time, but with a mature code being in use for many years event those are not frequent. For example, consider something like ping utility. It does what it does for many decades. There was a need to add IPv6 support, but that was almost two decades ago. Why would anyone need to update it? I do not want any additional functionality, I don't want it to send emails or have social media share button. I want it to send ICMP echo requests and receive ICMP echo replies and nothing more. Aside from some security fixes no updates should be needed for 10+ years. This utility is done. It should not be thrown upon just because there were no updates for many years. While of course neither ecommerce or Shopify platform are "done" and they get many updates now and will get updates in future it does not mean that some functionalities could have reached "done" stage. For a "complete and done" addon, there could be a need for a security fix from time to time. There could be a need for some adjustments if a major browser introduces a new deviation from JS/CSS/HTML standards and forces everyone to update their code. But those events happen from time to time, possibly not that frequently. This means that some addon/plugin would not require any updates during the periods between those events and those periods could be many months/years long. But hey: "this addon did not receive any updates for 13 months, it must be really bad and should be avoided". This leads to a situation where a competing solution with tons of bugs will look better just because it receives two updates a week.

pc86 7y ago
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.