What I wish I knew before building a Shopify App(ma.ttias.ch)
ma.ttias.ch
What I wish I knew before building a Shopify App
https://ma.ttias.ch/what-i-wish-i-knew-before-building-a-shopify-app.html
174 comments
Naming differences are the product of having names and enough surface area to where you can't remember all of what's in the API at once imo.
You can get variations in 2 digit country code vs 3 digit vs some other representation easily regardless of what language you're using
You can get variations in 2 digit country code vs 3 digit vs some other representation easily regardless of what language you're using
If you had a statically-typed language, you could have a single Address type and that's that.
That is definitely easier to work with but may not solve all problems. In the parent example, they mention Country and CountryCode. What if one team decided that they needed codes and the other needs the full name?
There has to be company-level standards to ensure consistency. And it is so hard to enforce standards unless a culture of revisiting and generalising things is created while growing from a small team.
There has to be company-level standards to ensure consistency. And it is so hard to enforce standards unless a culture of revisiting and generalising things is created while growing from a small team.
It is not hard to standardise an Address type across a company (they are a shopping product after all)
Or better yet, define which types are required and which are optional so at least naming is consistent
Or better yet, define which types are required and which are optional so at least naming is consistent
As someone who has worked on addresses for a large corperate system, addresses can get very complicated. International localization, formatting, different usages (shipping, billing, mailing, taxes), multiple addresses per user, and security all start to add up, with many different part of the application having different requirements. Even as the team that owned addresses we debated whether new use cases should spin up their own implemention. Though it's pretty interesting seeing how different countries do addresses differently.for example, users in South Korea expect to be able to search for addresses and just enter an apartment number. Some countries went to near 9 lines of info.
Shopify does not have this problem. There is no excuse for these addresses to be different. Case in point - look at Order vs FulfillmentOrder. The destination is a simple copy! Even worse, FO is missing the country code and province code, including only the (useless for shipping) full text. It's daft.
A typed language helps because you would have to make an explicit decision to use a non-standard Address. And the 2 vs 3 digit country code conflict is an issue with "stringly typed" code; don't do that, make a CountryCode type instead and constrain it.
A typed language helps because you would have to make an explicit decision to use a non-standard Address. And the 2 vs 3 digit country code conflict is an issue with "stringly typed" code; don't do that, make a CountryCode type instead and constrain it.
> About 1 in 5 of my CI runs fail with mysterious 500 errors. It's infuriating.
I see these daily, with errors that suggest the cloudflare layer is unable to connect to origin.
I see these daily, with errors that suggest the cloudflare layer is unable to connect to origin.
The inconsistency thing is likely just different teams/people working on the API.
I’d bet very few people who work there know all the APIs that exist.
I’d bet very few people who work there know all the APIs that exist.
Regardless of the proximate cause, it's very frustrating when companies don't prioritize good documentation.
There are definitely several ways to set up complex Shopify shipping situations. My livelihood is in good part based on it.
Oh sure... I make everything one pound, and create fixed rates for 1#, 2#, 3#, etc... but there's a (low) finite number of entries you can add, so if someone orders more than N units, they get free shipping for the rest. It's a terrible workaround. Etsy does not have this problem.
Or perhaps you are thinking about creating a carrier service, so Shopify will fetch shipping prices in realtime? That's for people on Shopify Plus plans, which costs $2k/mo+.
Actually, that's not quite true! There's a wholly undocumented option for non-plus merchants to get the carrier service feature enabled on their account for a monthly fee of something like $25. They have to reach out to support.
Everything with Shopify is like this. Great for consultants who have already internalized all this knowledge, sure.
Or perhaps you are thinking about creating a carrier service, so Shopify will fetch shipping prices in realtime? That's for people on Shopify Plus plans, which costs $2k/mo+.
Actually, that's not quite true! There's a wholly undocumented option for non-plus merchants to get the carrier service feature enabled on their account for a monthly fee of something like $25. They have to reach out to support.
Everything with Shopify is like this. Great for consultants who have already internalized all this knowledge, sure.
but why should it necessarily be that much different? better documentation sure, always. but in my experience Shopify solves ~70% of the cases extremely well and I, having learned some of the quirks, have very little problem filling the gaps. I will say, the app development, to the point of the article, IS a bit annoying hah. But I'm very surprised by all these API complaints. I think the API is very nice; maybe not quite Stripe-level but highly effective.
So your job is being a gatekeeper for Shopify’s shipping setup capabilities?
This is a great list, ill add in that there is no partner UI for billing obejects. If you lose a secret token then no one can access it, even though shopify has it on record and you have to beg the client to press uninstall.
Support is friendly and prompt but knows nothing about the apis.
Support is friendly and prompt but knows nothing about the apis.
Hey, I'm building an e-commerce operations platform that let's you connect any e-commerce platform to fulfillment and 3PL platforms. We're integrating with Printly and the like right now. Is there an API for your platform yet?
Yes, although you'll probably find that we are not an obvious fit for that model. Company info is in my profile.
I've been building Shopify apps for around 5 years now, and have 4 apps with around 15k users. I feel the pain this author feels with some additional notes..
Our apps are built in PHP using the polaris.css for styling components. We have some embedded apps currently (before Shopify began requiring the session token). Personally, the embedded experience is only good for simpler apps. If your app is more complex with lots of options and settings and things to show, the embedded experience is SO SMALL. Literally 40% of the screen is taken up by the Shopify admin leaving only a small portion for your app. Makes interface design more difficult when so much of the top/left part of the screen is taken up by Shopify admin.
Their API and webhooks are "fairly" reliable. We're consuming around 10k to 20k webhooks per hour and performing 20k to 50k API calls per hour. We rarely have issues. We are using their Amazon EventBridge integration to accept webhooks as a sort of buffer against them DDOSing our applications.
The largest issue with their API at scale is dealing with the API limits of 2 to 4 requests per second. Since some things require performing multiple API calls, and we deal with massive e-commerce stores that may need to perform 100,000 tasks, it can take a long time to perform the work (we have to artificially delay the API calls to not hit their limits). Also their GraphQL API has a complex limit system based on the "amount" of data returned, which makes fetching data even more complicated than their REST API.
My other big gripe with their API is that they have a GraphQL and REST API with different features. They support different filters, different fields they return, different types of objects... It's a real PITA to try and work seamlessly between two different APIs (e.g. data formatted differently). And neither API is 100% solid, depending on the features your app needs you will basically need to use both APIs.
Generally my experience has been pretty good with Shopify. Their API changes can be scary, but at least they use versioning so they don't break the current version you're using. They are constantly adding new features too.
Our apps are built in PHP using the polaris.css for styling components. We have some embedded apps currently (before Shopify began requiring the session token). Personally, the embedded experience is only good for simpler apps. If your app is more complex with lots of options and settings and things to show, the embedded experience is SO SMALL. Literally 40% of the screen is taken up by the Shopify admin leaving only a small portion for your app. Makes interface design more difficult when so much of the top/left part of the screen is taken up by Shopify admin.
Their API and webhooks are "fairly" reliable. We're consuming around 10k to 20k webhooks per hour and performing 20k to 50k API calls per hour. We rarely have issues. We are using their Amazon EventBridge integration to accept webhooks as a sort of buffer against them DDOSing our applications.
The largest issue with their API at scale is dealing with the API limits of 2 to 4 requests per second. Since some things require performing multiple API calls, and we deal with massive e-commerce stores that may need to perform 100,000 tasks, it can take a long time to perform the work (we have to artificially delay the API calls to not hit their limits). Also their GraphQL API has a complex limit system based on the "amount" of data returned, which makes fetching data even more complicated than their REST API.
My other big gripe with their API is that they have a GraphQL and REST API with different features. They support different filters, different fields they return, different types of objects... It's a real PITA to try and work seamlessly between two different APIs (e.g. data formatted differently). And neither API is 100% solid, depending on the features your app needs you will basically need to use both APIs.
Generally my experience has been pretty good with Shopify. Their API changes can be scary, but at least they use versioning so they don't break the current version you're using. They are constantly adding new features too.
For those of you that aren't in AWS ecosystem or are looking for a simpler alternative to EventBridge we've built https://hookdeck.io. A good chunk of our customers is either Shopify apps or Shopify stores. We essentially provide a full webhook infrastructure (queuing, retry, alerts, monitoring) out of the box. It should help to scale your webhook usage without having to go out of your way to build complex ingestion and queuing.
I think companies DDOSing endpoints is one of the least talked about issues with some webhooks implementations. Every time I tell people we offer it with Diahook[1] they look like it's the first time they even considered this...
[1] https://www.diahook.com
[1] https://www.diahook.com
Would you mind sharing how profitable your apps are? Do you think that a Shopify app is a good side-hustle for an experienced engineer?
My biggest problem with the ecosystem is how Shopify tries to deflect their own customer problems onto their partners to solve. And oftentimes, these same customers expect the partners to solve it for free.
Examples:
- Their default theme (provided by Shopify) has problems. Blame it on the app developer. "It's the app's fault." Yes, there are some poorly developed apps, but this lumps together the good with the bad.
- Customers use the app review system to hold developer hostage for feature requests. "Create this feature for us and I'll edit my review."
- Shopify's customer service reps says, "It must be the app that's causing this." Reading the CSR's emails, it is clear that this person does not understand the (technical) issues and is only trying to close the ticket. Customer takes what the CSR says as gospel and you, as the developer, spends a lot of time trying to fight that mindset.
I can't help but feel a big part of Shopify's early strategy was that the demographic of customers they were trying to attract just weren't a great type of customer, and that the partner program allowed them to enlist a lot of hungry developers willing to work for free (or next to nothing).
There is definitely room for improvement. I have mixed feelings about it, as their ecosystem provided me with a way to make a living many years ago. I don't depend on them anymore, but I wouldn't argue against trying your luck out there if you're starting out. Just recognize that there is a certain culture and way of practice there.
Examples:
- Their default theme (provided by Shopify) has problems. Blame it on the app developer. "It's the app's fault." Yes, there are some poorly developed apps, but this lumps together the good with the bad.
- Customers use the app review system to hold developer hostage for feature requests. "Create this feature for us and I'll edit my review."
- Shopify's customer service reps says, "It must be the app that's causing this." Reading the CSR's emails, it is clear that this person does not understand the (technical) issues and is only trying to close the ticket. Customer takes what the CSR says as gospel and you, as the developer, spends a lot of time trying to fight that mindset.
I can't help but feel a big part of Shopify's early strategy was that the demographic of customers they were trying to attract just weren't a great type of customer, and that the partner program allowed them to enlist a lot of hungry developers willing to work for free (or next to nothing).
There is definitely room for improvement. I have mixed feelings about it, as their ecosystem provided me with a way to make a living many years ago. I don't depend on them anymore, but I wouldn't argue against trying your luck out there if you're starting out. Just recognize that there is a certain culture and way of practice there.
This is similar my experience with making Shopify themes. It definitely feels like the third-parties that support the platform are not really considered. The developer experience is generally terrible and there's little incentive to change it because the developer isn't Shopify's customer, that would be the shop owner.
My experience as well r.e. the reviews. You'll get emails of people wanting an extended trial or wanting your app for free, or threatening to rate your app a 1 star review. When you contact Shopify about this problem -- they simply tell you to "work with the merchant."
Being almost 1 year into this, and having app that's now finally paying my bills, I'm feeling that I am just becoming another Shopify tech support person. My next venture/app will definitely be outside of this platform.
Also, Shopify's free themes are all terribly slow. Kinda ironic considering how hard they're pushing us recently with new storefront app performance requirements.
Also, Shopify's free themes are all terribly slow. Kinda ironic considering how hard they're pushing us recently with new storefront app performance requirements.
This is 100% my experience as a developer of Shopify POS plugins (building features that "should" just be included in the core product). I entered their ecosystem 9 months ago bright-eyed with the hope of being the captain of my own ship and hopefully building a living; I now feel like I have essentially signed myself up to build core features for their app (and dealing with frustrated customers who, rightfully, believe this feature should just be free and included), with the added handicap of being a third-party developer, and making significantly less than what I would make if I simply worked or contracted for them.
For now my apps are growing each month, but the culture and practices have left a bad taste in my mouth such that I also know that this is not for me in the long-term, and hope to someday exit their ecosystem.
For now my apps are growing each month, but the culture and practices have left a bad taste in my mouth such that I also know that this is not for me in the long-term, and hope to someday exit their ecosystem.
[deleted]
> Customers use the app review system to hold developer hostage for feature requests. "Create this feature for us and I'll edit my review."
To be fair this is pretty reasonable. Lets say 5 stars is highly recommend, 4 is recommend, 3 is neutral. If you’re building a new feature and it wouldn’t change anyone from being neutral about the product to recommending it, or from recommending the product to highly recommending it, maybe rethink building that feature.
To be fair this is pretty reasonable. Lets say 5 stars is highly recommend, 4 is recommend, 3 is neutral. If you’re building a new feature and it wouldn’t change anyone from being neutral about the product to recommending it, or from recommending the product to highly recommending it, maybe rethink building that feature.
Man, I wish app reviews worked that way.. relevant XKCD: https://xkcd.com/937/
It's not reasonable. That's a psycho that paid for a product, got what they paid for, and now want to extort the developer for extra features instead of paying more.
The question is whether the missing feature could be reasonably inferred to be present based on competing products or the product’s description.
Let’s say I buy a camera. It takes photos well enough, but I soon learn that it can only transfer the photos to my computer over WiFi or the cloud. This is terribly slow and not in-line with what I’d expect from a camera, so I leave a 3 star review saying that while it works fine, not being able to transfer photos quickly means I cannot recommend it, and that if this feature were added in a software update I’d rate it 5 stars.
Imo this is totally reasonable and a review whose contribution to the average rating I would value much more than “5 stars, the photos are good. I’m upset however that I can’t transfer them quickly, but oh well that’s a missing feature and I’m not allowed to complain about missing features in a way that affects the star rating because that would make the people who didn’t implant them upset”
On the other hand if I leave a review for the camera saying “3 stars, this did not come with a exposure and zoom configuration that let me capture the andromeda galaxy, please add and I’ll make 5 stars”, that’s a whole different story.
Let’s say I buy a camera. It takes photos well enough, but I soon learn that it can only transfer the photos to my computer over WiFi or the cloud. This is terribly slow and not in-line with what I’d expect from a camera, so I leave a 3 star review saying that while it works fine, not being able to transfer photos quickly means I cannot recommend it, and that if this feature were added in a software update I’d rate it 5 stars.
Imo this is totally reasonable and a review whose contribution to the average rating I would value much more than “5 stars, the photos are good. I’m upset however that I can’t transfer them quickly, but oh well that’s a missing feature and I’m not allowed to complain about missing features in a way that affects the star rating because that would make the people who didn’t implant them upset”
On the other hand if I leave a review for the camera saying “3 stars, this did not come with a exposure and zoom configuration that let me capture the andromeda galaxy, please add and I’ll make 5 stars”, that’s a whole different story.
We've just started developing a Shopify integration and used their Python API library because we're building it into an existing large Django codebase, and I've been shocked at the quality of the API library. We're now aiming to rewrite the bits we need.
- `import shopify` makes an API request. If their API rate limits you, your server will probably crash. This happened to us in production.
- That API request gets a dynamic list of supported API versions. If the version you've hard-coded in your app (because it's what you support) is no longer in that list, it will raise a VersionNotFoundError and your app will probably fail in some significant way.
- There's no connection persistence. Every API call sets up and tears down a full connection, a noticeable performance impact.
- Internally the library uses a lot of global state, it's certainly not safe to use in async code – too easy to use the wrong credentials on a request – and I suspect it's also not thread safe.
- Despite having something called a Session, very similar in documentation to a requests.Session or httpx.Session, it's neither, it's just a container for some creds. No sessions are available at all.
- It's mostly a wrapper around Pyactiveresource, which appears to have a lot of similar issues – internal state that's hidden that causes things to not work as you expect.
I suspect that the Python library was developed by Ruby engineers, some of the practices are things I've seen in Ruby but that just don't fit into the Python ecosystem.
From what I can tell their API deprecation strategy is quite hostile to developers.
I think it would be difficult to build what I'd consider to be production-grade services on top of the library. This is in stark contrast to others such as Stripe's API/libraries which are fantastic.
- `import shopify` makes an API request. If their API rate limits you, your server will probably crash. This happened to us in production.
- That API request gets a dynamic list of supported API versions. If the version you've hard-coded in your app (because it's what you support) is no longer in that list, it will raise a VersionNotFoundError and your app will probably fail in some significant way.
- There's no connection persistence. Every API call sets up and tears down a full connection, a noticeable performance impact.
- Internally the library uses a lot of global state, it's certainly not safe to use in async code – too easy to use the wrong credentials on a request – and I suspect it's also not thread safe.
- Despite having something called a Session, very similar in documentation to a requests.Session or httpx.Session, it's neither, it's just a container for some creds. No sessions are available at all.
- It's mostly a wrapper around Pyactiveresource, which appears to have a lot of similar issues – internal state that's hidden that causes things to not work as you expect.
I suspect that the Python library was developed by Ruby engineers, some of the practices are things I've seen in Ruby but that just don't fit into the Python ecosystem.
From what I can tell their API deprecation strategy is quite hostile to developers.
I think it would be difficult to build what I'd consider to be production-grade services on top of the library. This is in stark contrast to others such as Stripe's API/libraries which are fantastic.
> `import shopify` makes an API request.
Especially for a company that prides itself on great API design, this is head scratching.
‘shopify.Init()’ seems like such an obvious solution
Especially for a company that prides itself on great API design, this is head scratching.
‘shopify.Init()’ seems like such an obvious solution
The fact that you can have side effects on imports, and that a lot of libraries relied on side effects on import, was one of my biggest sources of frustration with Python
What other packages have you seen abusing import side effects?
Shopify is the first one I've seen, so I don't think it's quite as common as you are implying, but I'm curious to know what other bad behavior you have found
Shopify is the first one I've seen, so I don't think it's quite as common as you are implying, but I'm curious to know what other bad behavior you have found
An example in the standard library is the antigravity package. While it is an inside joke it still requires a HTTP transaction similar to the shopify package import.
Not GP but I've been bitten by plenty of first-party implicit side-effects, both intended (by not me not now) and not (by me or otherwise).
Sometimes libraries do a switcheroo where they run interpreted code on startup to locate the "real" implementation in a shared object, and then load that and replace themselves with it. I'm not sure this is really idomatic, but here's an example of what it looks like from OpenCV:
https://github.com/opencv/opencv/blob/master/modules/python/...
https://github.com/opencv/opencv/blob/master/modules/python/...
SKiDL (circuit design library) does this to a very large extent...
https://github.com/xesscorp/skidl
https://github.com/xesscorp/skidl
Can’t you do this with any interpreted language? On ruby your import could redefine anything.
Is there any real way around that? The import keyword might as well be renamed to exec.
I think this depends on how brutal the workarounds you will accept are
Almost all 3rd party SDKs should be avoided like the plague as a general rule. I have a much better time taking control of the HTTP requests to 3rd party APIs
I don't really understand why developers use SDKs/libraries at all when the RESTful APIs are easy enough to consume directly.
Handroll marshalling for every payload, handle the auth sequence, check arguments, endpoint semantics, sort out sparse versus full entity patching mismatch, build in retry that matches status codes, and do this for every endpoint.
If you're moving fast, you don't have time for this. Especially if it isn't your core competency / core product.
If you're moving fast, you don't have time for this. Especially if it isn't your core competency / core product.
> sort out sparse versus full entity patching mismatch
I thought we are talking about Shopify... where people browse and search products, buy products, make a transaction, and review past orders/invoices/transactions.
Where does PATCH fit?
I thought we are talking about Shopify... where people browse and search products, buy products, make a transaction, and review past orders/invoices/transactions.
Where does PATCH fit?
Customers do all that, but admins also upload and edit products, orders, and other entities typical of an eCommerce model. I’m assuming it’s that?
Shopping cart is an obvious one.
Depends to be honest. Where they expose OpenAPI docs it's dead simple to generate the models from that. In .NET I use those plus Refit and boom. Now I have full control and it took barely any time.
I like this approach too, but a non trivial amount of time the models come out wrong. I assume this is because of bad openapi docs, but maybe I'm wrong.
What do you use to consume the openapi docs and generate models with?
What do you use to consume the openapi docs and generate models with?
Haha yes we got bitten by that on a recent project but it resulted in a minor bug we patched pretty quick. I don't mind taking that downside.
Can't remember the exact name of it but it's one of the open API generators that supports all the major languages. Unfortunately the csharp and dotnet core generator generates clients with RestSharp which doesn't use the almighty HttpClient, so I consider them unusable, but it generates the models faithfully. If it so happens the open API spec is wrong that's unfortunate. Though usually if they have an SDK I just use the models directly from the SDK! That's the absolute sweet spot for me. Especially if their SDK is generated off open API it probably stays perfectly or acceptably accurate with incentives to correct any inaccuracies.
Can't remember the exact name of it but it's one of the open API generators that supports all the major languages. Unfortunately the csharp and dotnet core generator generates clients with RestSharp which doesn't use the almighty HttpClient, so I consider them unusable, but it generates the models faithfully. If it so happens the open API spec is wrong that's unfortunate. Though usually if they have an SDK I just use the models directly from the SDK! That's the absolute sweet spot for me. Especially if their SDK is generated off open API it probably stays perfectly or acceptably accurate with incentives to correct any inaccuracies.
Most APIs there's usually only a handful of endpoints. There's never an auth sequence, just a simple API key. Patching is exceedingly rare. I don't want an SDK to auto-retry. Interacting with an API actually usually is or needs to be a core competency.
I still think the major promise of RESTful APIs is avoided by the prevalence of SDKs.
I still think the major promise of RESTful APIs is avoided by the prevalence of SDKs.
One word answer: Types.
If you dont use a language with strong type safety the benefits are less.
For instance the OpenAPI3 (Swagger-NG) standard. It allows the typing/schema'ing of the JSON bodies. It also provides a bunch of generators[1] that can be used to generate client libs. And when the languages of the client libs permit it, those libs come with lots of type safety and greatly reduce boilerplate.
1: https://openapi-generator.tech/docs/generators/
If you dont use a language with strong type safety the benefits are less.
For instance the OpenAPI3 (Swagger-NG) standard. It allows the typing/schema'ing of the JSON bodies. It also provides a bunch of generators[1] that can be used to generate client libs. And when the languages of the client libs permit it, those libs come with lots of type safety and greatly reduce boilerplate.
1: https://openapi-generator.tech/docs/generators/
One of the reason I don't like types.
There really shouldn't be much boilerplate to passing JSON around back and forth.
There really shouldn't be much boilerplate to passing JSON around back and forth.
I also find it frustrating as a python / django / vue developer working on Shopify apps.
The python api doc is not good. I'm always not sure about how to call the api. I can only leave an issue on GitHub.
The ecosystem obviously leans toward react and ruby. The examples are not suitable for me most of the time. The tooling like CLI, example will not include what you need.
Use Polaris for your UI? Sorry, it's not supporting vue. You need to build it with npm. Only for react. But I want the easy way to work with CDN
Need python examples on the latest session token auth? Sorry, there is no such thing. I spent 2 - 3 weeks working on it (and still working now). What I got are the workflow diagram and step instructions. Welcome back to the uni!
But the session token auth is mandatory for all new apps. You must use it NOW!
Developer / Partner support? Please provide a store id to identify yourself. But I clicked the link INSIDE the partner portal. (Half an hour later, still got nothing. ) I spend an hour and get nothing most of the time. The worst thing is that they answer you 'Sorry, I don't know or it is not feasible' with a thousand word long email.
The python api doc is not good. I'm always not sure about how to call the api. I can only leave an issue on GitHub.
The ecosystem obviously leans toward react and ruby. The examples are not suitable for me most of the time. The tooling like CLI, example will not include what you need.
Use Polaris for your UI? Sorry, it's not supporting vue. You need to build it with npm. Only for react. But I want the easy way to work with CDN
Need python examples on the latest session token auth? Sorry, there is no such thing. I spent 2 - 3 weeks working on it (and still working now). What I got are the workflow diagram and step instructions. Welcome back to the uni!
But the session token auth is mandatory for all new apps. You must use it NOW!
Developer / Partner support? Please provide a store id to identify yourself. But I clicked the link INSIDE the partner portal. (Half an hour later, still got nothing. ) I spend an hour and get nothing most of the time. The worst thing is that they answer you 'Sorry, I don't know or it is not feasible' with a thousand word long email.
Being a python developer I am interested to know more. Are there resources you use to make the app? Do they provide rest api?
> From what I can tell their API deprecation strategy is quite hostile to developers.
Yes, every 3 months you need to revisit the API. It's good and bad. It means that if you're casually developing an app, this will consume a lot of time. Good because if forces you to update and keep your app relevant.
Yes, every 3 months you need to revisit the API. It's good and bad. It means that if you're casually developing an app, this will consume a lot of time. Good because if forces you to update and keep your app relevant.
Well, yeah, but why do they need to make changes to their API so frequently? This is both developer and business hostile. I get extremely pissy when paying for a service where the provider regularly dumps non-value-adding work into my product backlog that sucks up time I could invest in more valuable areas.
This is very poor from Shopify's perspective if that's the case: API can change as often as they want,but each new version comes as a new thing with its own documentation and so on,while the old ones stay there for a long time with whatever functionality was supported. I did receive some emails from Salesforce, saying they will be retiring version 7 of their API soon. Guess what, their current version is 51.
>Good because if forces you to update and keep your app relevant.
The real question we should be asking is, is churn adding value? I understand security updates but otherwise you can only improve the wheel so many times before it just becomes a waste of time (decreasing marginal returns). Software engineering _badly_ needs a concept of finished version and mature software. Often there is very little gained from a new framework every few months besides assuaging the egos of a new generation of developers.
The real question we should be asking is, is churn adding value? I understand security updates but otherwise you can only improve the wheel so many times before it just becomes a waste of time (decreasing marginal returns). Software engineering _badly_ needs a concept of finished version and mature software. Often there is very little gained from a new framework every few months besides assuaging the egos of a new generation of developers.
> Software engineering _badly_ needs a concept of finished version and mature software
It used to be like that. Back before the expectation of regular updates, in fact back before downloading updates off the internet was considered desirable or even feasible, when releasing a patch was a borderline embarrassing admission that we didn't get it right the first time, software shipped on CD and the version that shipped was understood to be the version installed on the vast, vast majority of customer systems, so it had better be a finished product or there were reputations on the line.
It used to be like that. Back before the expectation of regular updates, in fact back before downloading updates off the internet was considered desirable or even feasible, when releasing a patch was a borderline embarrassing admission that we didn't get it right the first time, software shipped on CD and the version that shipped was understood to be the version installed on the vast, vast majority of customer systems, so it had better be a finished product or there were reputations on the line.
Keeping your app relevant because the API it is built upon is unstable or has breaking changes is hardly a good.
"Good because if forces you to update"
That's the opposite of good.
That's the opposite of good.
> forces you to update and keep your app relevant.
"Relevant" to whom? As long as the store is selling stuff, it's highly relevant to the buyer and seller.
"Relevant" to whom? As long as the store is selling stuff, it's highly relevant to the buyer and seller.
> Good because if forces you to update and keep your app relevant.
That is the consumer being "good". There is nothing regarding the provider there which is good.
That is the consumer being "good". There is nothing regarding the provider there which is good.
> forces you to...
Never good.
Never good.
Python forces you to indent.
Python is a great language for other reasons. Forcing you to indent isn't one of those reasons.
The statement wasn't on greatness. The statement was on "never good."
I think the programming community largely agrees that indenting is good. If something is forcing you to do something that is good, then it definitely doesn't fall into the category of "never good."
I can't think of a single time in the nearly 10 years of using Python daily that made me want it to operate differently w.r.t. indenting.
I think the programming community largely agrees that indenting is good. If something is forcing you to do something that is good, then it definitely doesn't fall into the category of "never good."
I can't think of a single time in the nearly 10 years of using Python daily that made me want it to operate differently w.r.t. indenting.
The programming community most certainly does not agree that "forcing you to indent the way the language designer decided you should indent" is good. There are lots of programmers that disagree with it. There are lots that agree with it. But the "programming community" as a whole has certainly not come to a consensus on it.
When you're testing fragments of code by copying from one place to another to run, such as just pasting directly into a shell, indenting is an unnecessary hassle.
Indenting is good. (as is, generally, being consistent and readable)
Indenting as code always struck me as a horrible idea. Better than, say, type coercion... but still horrible.
Indenting as code always struck me as a horrible idea. Better than, say, type coercion... but still horrible.
So code linters, code formatters, and style guides used in any well maintained code base.
Many of the pain points in the OP and comments are things we're addressing at Saleor.
Open Source First with Cloud option
Exclusive focus on GraphQL API
API-first rather than headless as an afterthought
Solid Documentation
*Responsive community and team
Fastest growing oss commerce platform on gh. Proven at scale. For a headless solution that prioritizes dev experience above all else, please check us out.
(Full disclosure, Saleor Head of Growth. A friend sent me this link. Yes, my account is new.)
(Full disclosure, Saleor Head of Growth. A friend sent me this link. Yes, my account is new.)
Shopify is an extremely restrictive platform for merchants and developers, I urge people not to use it if they wish to build on top of it.
There isn't ways to have a custom checkout (one page) with this system and subscriptions are not natively built in, relying on a third party ecosystem.
Theme development is also arcane and not the standard way web developers build a simple website.
Oh and they disallow you to use Stripe for your store and you have to go through Shopify payments instead.
There isn't ways to have a custom checkout (one page) with this system and subscriptions are not natively built in, relying on a third party ecosystem.
Theme development is also arcane and not the standard way web developers build a simple website.
Oh and they disallow you to use Stripe for your store and you have to go through Shopify payments instead.
While I agree with the first and second point.
Theme development is the same as any other system. It's very similar to a Drupal or Wordpress commerce. I am not sure I fully see what you mean.
Obviously they don't allow you to use another payment processor, why would they? They make money by having people use their payment processor. There is no benefit to them allowing people to bypass this and implement their own payment system.
The custom checkout can be a con, but it's also a pro. It allows your customers to feel at home in a native environment. Not having to deal with every ecommerce site completely different checkout system.
Theme development is the same as any other system. It's very similar to a Drupal or Wordpress commerce. I am not sure I fully see what you mean.
Obviously they don't allow you to use another payment processor, why would they? They make money by having people use their payment processor. There is no benefit to them allowing people to bypass this and implement their own payment system.
The custom checkout can be a con, but it's also a pro. It allows your customers to feel at home in a native environment. Not having to deal with every ecommerce site completely different checkout system.
The Shopify Billing API is extremely restrictive. Our application works with all e-commerce platforms (BigCommerce, Magento, Woocommerce, etc). We charge 1 monthly fee so a user can connect all of their shops. How are we supposed to charge the user if the first shop they connect is not Shopify? What if the 2nd shop is Shopify and they have already paid using Stripe? Shopify says they won't approve our application. Guess they don't like it when applications support more than just Shopify.
On top of that, there are applications that can have this payment flow except you need permission to accept outside payments. Shopify only gives this to established companies.
Late last year, they also got rid of unlisted applications and now all applications have to be approved even if you don't want it in their app store.
Shopify is building its moat and getting more and more restrictive. I'm very glad we abstracted all of the operations out of Shopify directly and now can use any platform or even Stripe directly. If you want to build an e-commerce store with Shopify still, use the $9/month plan and use Shopify just as a CMS and integrate with payments separately.
On top of that, there are applications that can have this payment flow except you need permission to accept outside payments. Shopify only gives this to established companies.
Late last year, they also got rid of unlisted applications and now all applications have to be approved even if you don't want it in their app store.
Shopify is building its moat and getting more and more restrictive. I'm very glad we abstracted all of the operations out of Shopify directly and now can use any platform or even Stripe directly. If you want to build an e-commerce store with Shopify still, use the $9/month plan and use Shopify just as a CMS and integrate with payments separately.
This was exactly the same problem for us. Worse, we were integrating Amazon and Shopify testers wanted our Amazon keys for their testing. Our users have already paid with Stripe and we are not allowed to use Shopify app since payments are not Shopify Payment.
if your app fails their ludicrous testing (one was failed as our icon had wrong font from website) they ban any submission for few months, don't allow integration with other ecommerce platforms, don't allow shopify orders to be cross platform, don't allow non-shopify payments.
And they always nickel and dime their users including Shopify payments. You think Amazon is bad? Wait till you get on Shopify
if your app fails their ludicrous testing (one was failed as our icon had wrong font from website) they ban any submission for few months, don't allow integration with other ecommerce platforms, don't allow shopify orders to be cross platform, don't allow non-shopify payments.
And they always nickel and dime their users including Shopify payments. You think Amazon is bad? Wait till you get on Shopify
With one site I developed with Shopify, I have a huge cart abandonment rate because of that 3 step checkout, even with the accelerated checkouts like Apple/Google Pay.
A single page modal checkout on the same page is the way to go these days, even Stripe's new checkout is unfortunately doing the same thing with not keeping the user on the same page.
A single page modal checkout on the same page is the way to go these days, even Stripe's new checkout is unfortunately doing the same thing with not keeping the user on the same page.
One thing with Shopify that drives the high abandonment rate is that shipping rates are usually not calculated until the second page of checkout. On many stores the only way to get a shipping estimate is to add something to a cart and get to the second page of checkout.
This is huge - and annoying. I like to avoid Amazon when I can, but if I can't figure out what shipping is going to cost until the cart is almost finished being checked out, I'll bounce.
In small business stores most users checkout as guests, so the website only has enough info to provide a shipping estimate after they have your address.
At least let me pick a country or something and give me a ballpark.
With a lot of US-only retailers the only way to find out they won’t ship outside the US is to try and checkout and look for a country drop down.
And the ones that will ship, shipping for a small parcel can range from inconsequential (free/$10) through punishing ($80) to absurd ($300).
I don’t need an exact amount, but there can be a couple order of magnitude difference between stores when trying to ship to Canada and often no way to determine they even will at all without going through the checkout flow.
With a lot of US-only retailers the only way to find out they won’t ship outside the US is to try and checkout and look for a country drop down.
And the ones that will ship, shipping for a small parcel can range from inconsequential (free/$10) through punishing ($80) to absurd ($300).
I don’t need an exact amount, but there can be a couple order of magnitude difference between stores when trying to ship to Canada and often no way to determine they even will at all without going through the checkout flow.
Exactly - and in the USA I just need a “zip code = estimate” so I know if I’m looking at $10 or $50.
And that suggests to me that these are not the kind of abandonments that are going to be avoided by redesigning your checkout. This user weld simply bounce somewhere else instead. It is trivial to put a shipping estimate on the product pages, and make customers bounce there instead...but they will still bounce
Agree. Started off using it because everyone is and it's quick to get going and setup a store, but as soon as you do any custom stuff it's a nightmare. We eventually ran in to a problem where any site updates wouldn't save, and there's no way to debug anything. We'd started to move to bigcommerce so that just accelerated it. Bigcommerce is more flexible but settings all over the place.
Subscriptions is now available as part of their API. It does require a bit of time* to understand it though.
* - May vary depending on your level of experience with GraphQL
* - May vary depending on your level of experience with GraphQL
*API
But not natively within Shopify's UI, You have to use 3rd party apps have to make use of this API. For merchants this is useless to them if they don't want to use a 3rd party app for this feature.
But not natively within Shopify's UI, You have to use 3rd party apps have to make use of this API. For merchants this is useless to them if they don't want to use a 3rd party app for this feature.
We just built our own subscriptions on the Subscription API and it is extremely thin. Just a few gripes that I had to build around:
1. The "SubscriptionContract" isn't much of a contract at all. You can set a subscription to cancelled but still bill against it for example.
2. It keeps track of a "next billing date" but it does not bill the customer for you like Stripe does, you have to keep track of the next billing date and attempt to bill against the contract yourself.
Is this subscription api suitable for digital only businesses that have say a membership system?.
Last time I checked most of the shopify apps out there are not suited to this.
Last time I checked most of the shopify apps out there are not suited to this.
Are you thinking for digital products like a PDF or purely for membership access?
When you create a billing attempt against a subscription, it creates a Shopify order that is tied to that subscription. You could definitely have the order be tied to a digital product.
While you could definitely make it work for a membership system, I think I'd recommend literally anything else. Happy to elaborate or answer any specific questions you might have.
When you create a billing attempt against a subscription, it creates a Shopify order that is tied to that subscription. You could definitely have the order be tied to a digital product.
While you could definitely make it work for a membership system, I think I'd recommend literally anything else. Happy to elaborate or answer any specific questions you might have.
What would you recommend for a membership system, thinking about this route since waiting for Shopify's subscription API's to mature but time isn't on my side on this.
If you're not already in the Shopify ecosystem, I'd look at Stripe Subscriptions with Checkout which requires a small amount of development that lives in something like a lambda or netlify function.
- https://stripe.com/docs/billing/subscriptions/checkout
- https://www.netlify.com/blog/2020/07/13/manage-subscriptions...
If you want something out of the box, there are tools like Memberful, Gumroad, etc that take quite a vig on top of the payment processing.
If you want something out of the box, there are tools like Memberful, Gumroad, etc that take quite a vig on top of the payment processing.
[deleted]
They integrate with a lot of payment gateways, even if Stripe isn't one of them.
https://www.shopify.com/payment-gateways/united-states
https://www.shopify.com/payment-gateways/united-states
Have to admit, while this is good and reassuring for accepting worldwide payments, Shopify is no good on the subscriptions front and this is very poor if your subscriptions business is digital, like a membership system.
Is Gumroad a better fit perhaps for this use case?
Gumroad looks cool, but the percentages they are taking are extortionate, not sure if they are better.
It would get to a point where I am giving thousands of pounds to Gumroad to lock myself in. How customisable is it, can it do Apple / Google Pay?
It would get to a point where I am giving thousands of pounds to Gumroad to lock myself in. How customisable is it, can it do Apple / Google Pay?
Not sure if it does mobile payments natively. Depending on your content, Ghost [1] might be another option with a more palatable cost.
[1] https://ghost.org/
[1] https://ghost.org/
In that case they still take 2% which is pretty absurd.
> not the standard way web developers build a simple website
I would like to see this standard described and what level of agreement you get.
I would like to see this standard described and what level of agreement you get.
Not OP, and I don't know if you've ever worked within Shopify, but the developer experience is generally terrible. They've given up supporting most of their own tools and basically just tell you to work within their site admin IDE which is also lacking in many ways.
Ugh, I can so relate to this right now. I followed their Node embedded app tutorial closely, submitted my app, then found out they no longer allow embedded apps to use cookies like their tutorial does. Finding up to date documentation is a struggle and some of the components they suggest you use are closed source and completely undocumented.
I had previously built a rails app using Shopify CLI and it failed review due to some endless cookies loop that I could not reproduce caused by their gem. In the end, I just rolled my own OAuth / user database / Billing - but talk about a waste of time.
I share some of the pains the author raises. One major thing that is a bit discouraging is the inconsistent feature support they have between REST and GraphQL APIs. Neither of them cover all functionalities, so sometimes you have to be bouncing back and forth between REST and GraphQL.
On the other hand, they are doing an amazing job and constantly providing updates. Their docs are really good and improving everyday. Kudos to the shopify dev team.
On the other hand, they are doing an amazing job and constantly providing updates. Their docs are really good and improving everyday. Kudos to the shopify dev team.
Curious as to why this is being downvoted? Could down voters please share their views?
Lots of really fair feedback here. We hear you.
There's also a lack of communication with the dev partners in general (e.g. the recent Service Worker issues). Building up a more robust partner program with (perhaps) a different support team could be really helpful.
Developer of Simple Purchase Orders here https://apps.shopify.com/simple-po
This is the best bit of developing for Shopify imo, this is the CEO reading the comments and taking them on board.
So here are some more!
Good - Partner support isn't great, however, if you can figure out how to get to a named employee, which is quite easy with their Slack for partners, they are super helpful. Just this week I am migrating to React and Polaris (mostly due to third party cookies being blocked by browsers and having to move to JWTs for auth). I had a niche problem that I dreaded going through support with, so I posted in the relevant Slack channel and a dev got in touch and fixed it for me in minutes.
Bad - 20% commission is starting to look expensive now Google and Apple have dropped their fees - They only pay out in dollars to PayPal which results in a 3% fee for non-US (and Canada?) devs since December - Python API is not kept up to date - There have been numerous copycat apps that the original devs have had to kick up a huge fuss to remove
Thanks to @donutdan and this post https://news.ycombinator.com/item?id=15149528 for originally introducing me to Shopify Apps nearly 4 years ago, its been fun
This is the best bit of developing for Shopify imo, this is the CEO reading the comments and taking them on board.
So here are some more!
Good - Partner support isn't great, however, if you can figure out how to get to a named employee, which is quite easy with their Slack for partners, they are super helpful. Just this week I am migrating to React and Polaris (mostly due to third party cookies being blocked by browsers and having to move to JWTs for auth). I had a niche problem that I dreaded going through support with, so I posted in the relevant Slack channel and a dev got in touch and fixed it for me in minutes.
Bad - 20% commission is starting to look expensive now Google and Apple have dropped their fees - They only pay out in dollars to PayPal which results in a 3% fee for non-US (and Canada?) devs since December - Python API is not kept up to date - There have been numerous copycat apps that the original devs have had to kick up a huge fuss to remove
Thanks to @donutdan and this post https://news.ycombinator.com/item?id=15149528 for originally introducing me to Shopify Apps nearly 4 years ago, its been fun
Would love to see the online store design experience released. Just throwing that out there. Excited to explore the possibilities.
CORS support in the predictive search API please, or better search in the Storefront API.
It’s great to see you are here and listening to feedback.
While we have you ear can I repeat a long-standing request.
Set price multi currency support.
We built an Ecommerce site for a leading global brand with thousands of SKUs.
The lack of a method to set a fixed price for multiple currencies on a single product in a store has created significant complexity for us.
We have to create a store with around a thousand SKU’s for each local currency just to set the price.
The software and process gymnastics required to synchronise product information, images, inventory data, fulfillments and tracking could be avoided with local currency pricing.
Having multiple stores makes it mostly impossible to make use of third party apps that would otherwise enable the client to do more with shopify.
While we have you ear can I repeat a long-standing request.
Set price multi currency support.
We built an Ecommerce site for a leading global brand with thousands of SKUs.
The lack of a method to set a fixed price for multiple currencies on a single product in a store has created significant complexity for us.
We have to create a store with around a thousand SKU’s for each local currency just to set the price.
The software and process gymnastics required to synchronise product information, images, inventory data, fulfillments and tracking could be avoided with local currency pricing.
Having multiple stores makes it mostly impossible to make use of third party apps that would otherwise enable the client to do more with shopify.
We have this same problem. I am trying to work out at the moment if this is solved by using Shopify +
We manage it by our product data being in our ERP, and use Shopify as a dumb front end. The marketing people still hate it though.
We manage it by our product data being in our ERP, and use Shopify as a dumb front end. The marketing people still hate it though.
> if this is solved by using Shopify +
It isn’t, plus makes it marginally less painful, single login etc. It doesn’t add anything for multi currency.
We did raise this with the plus onboarding guys and they confirmed it was not possible.
> We manage it by our product data being in our ERP
Same here, in fact we go one further and built a headless store in front, along with a proxy for inventory because the stock API is so slow.
The original goal was to use pure Shopify. The end result is more like a glorified shopping cart and and fulfillment backend.
If we did it again I think we’d be better off building on a payment provider like Stripe.
It isn’t, plus makes it marginally less painful, single login etc. It doesn’t add anything for multi currency.
We did raise this with the plus onboarding guys and they confirmed it was not possible.
> We manage it by our product data being in our ERP
Same here, in fact we go one further and built a headless store in front, along with a proxy for inventory because the stock API is so slow.
The original goal was to use pure Shopify. The end result is more like a glorified shopping cart and and fulfillment backend.
If we did it again I think we’d be better off building on a payment provider like Stripe.
I developed on the Shopify platform for a while. I found it very odd how restrictive their endpoint was. Most of my job involved creating really hacky workaround for their weirdly missing features.
Maybe not that helpful of an addition, but the most surprising thing I found was that Shopify has an option for an "app proxy", in which you can have some separate, custom web server that gets proxied through your Shopify store.
I've used this to some success in building a more robust product customization app (with functionality very specific to our business), more so than what I could find on their store. The biggest con for using the app proxy is around authentication. You can't do much special stuff with auth, basically the simplest option is to just wrap your proxied pages in a liquid check for customer.id. (Although, I can see this as a pro rather than a con, as it forces you to keep the proxy app simple.)
My biggest worry is one day Shopify just decides to discontinue app proxies. It doesn't seem like an option they try to point developers toward, so I don't trust it and am thinking about building on top of their API to avoid this.
I've used this to some success in building a more robust product customization app (with functionality very specific to our business), more so than what I could find on their store. The biggest con for using the app proxy is around authentication. You can't do much special stuff with auth, basically the simplest option is to just wrap your proxied pages in a liquid check for customer.id. (Although, I can see this as a pro rather than a con, as it forces you to keep the proxy app simple.)
My biggest worry is one day Shopify just decides to discontinue app proxies. It doesn't seem like an option they try to point developers toward, so I don't trust it and am thinking about building on top of their API to avoid this.
So I appear to be on a Shopify black list.
I've called them, my bank, and on a few occasions even tried other people's cards.
I'm declined no matter what, by Shopify. It's been this way for well over a year. Sometimes retailers will manually process a transaction, but otherwise it's infuriating for me to see Shopify grow in the market.
I've called them, my bank, and on a few occasions even tried other people's cards.
I'm declined no matter what, by Shopify. It's been this way for well over a year. Sometimes retailers will manually process a transaction, but otherwise it's infuriating for me to see Shopify grow in the market.
You can see some of the indicators they use here:
https://help.shopify.com/en/manual/orders/fraud-analysis#fra...
The thing where it calculates ip geolocation distance from the shipping address is a potential culprit. Maybe your IP address has a bad entry in their ip geo mapping software.
They also don't like proxies and VPNs.
https://help.shopify.com/en/manual/orders/fraud-analysis#fra...
The thing where it calculates ip geolocation distance from the shipping address is a potential culprit. Maybe your IP address has a bad entry in their ip geo mapping software.
They also don't like proxies and VPNs.
anything to do with marijuana, they will ban you because they are processed by stripe and american company
Polaris does have a CSS file - https://github.com/Shopify/polaris-react#using-the-css-compo...
You are free to use it as you want, it doesn't support the dynamic components obviously since it's CSS. But you can easily reimplement the parts you want.
You are free to use it as you want, it doesn't support the dynamic components obviously since it's CSS. But you can easily reimplement the parts you want.
I'm reading a good number of the comments and while I understand it's not a sample without bias, I have to ask:
How did Shopify get to be the beast that it is?
Why doesn't someone else step up and into what looks like a massive opportunity, especially since Covid have push so many transactions online?
I have worked with Shopify customizing themes and adding custom functionality. It good when it great and you're within its sweetspot. But then it drops off like a cliff. The developer workflow? Shockingly dated.
I've worked with WooCommerce. Great tool. But it requires knowledge and resources.
I've taken the BigCommerce training. Felt like Shopify 3.x but I'm not sure they're positioning well for the long term.
I know there are others.
It seems to me that there's a sweetspot between Shopify and WooComm. User friends yet also developer friendly. Perhaps not easy to do. But that's not humans on Mars either, is it?
How did Shopify get to be the beast that it is?
Why doesn't someone else step up and into what looks like a massive opportunity, especially since Covid have push so many transactions online?
I have worked with Shopify customizing themes and adding custom functionality. It good when it great and you're within its sweetspot. But then it drops off like a cliff. The developer workflow? Shockingly dated.
I've worked with WooCommerce. Great tool. But it requires knowledge and resources.
I've taken the BigCommerce training. Felt like Shopify 3.x but I'm not sure they're positioning well for the long term.
I know there are others.
It seems to me that there's a sweetspot between Shopify and WooComm. User friends yet also developer friendly. Perhaps not easy to do. But that's not humans on Mars either, is it?
At the end of the day, the customer is the one deciding what they will pay for based on what is available to them. Majority of apps are on Shopify. Customer has no knowledge of the dev tools and how hard they are to use.
Yes and no. The issue here is presenting as "dev friendly" and not being true to that. Wix, Webflow, Squrespace don't do that. They're not.
But Shopify wants to say one thing but do another. Why do devs subject themselves to a platform with well known limitations.
Note: I like Shopify. But only for cases that are within its sweet spot.
But Shopify wants to say one thing but do another. Why do devs subject themselves to a platform with well known limitations.
Note: I like Shopify. But only for cases that are within its sweet spot.
There are a lot of options in e-commerce, all of them with thousands of shops: WooCommerce, Magento, Jumpseller, Bigcommerce, Prestashop, Wix WooCommerce etc...
> How did Shopify get to be the beast that it is?
Its amazingly simple to get started. It will push the products into a shoppingCart array, do the arithmetic adding up the prices. Clearly not something you should pay for. It's one hell of a deal - for them.
I'm sure there is a special place in hell for self proclaimed developers who want to help shopify create a playstore/appstore like monopoly. I'm happy they are this terrible at everything nice.
But the getting started process is wonderful. Its all fantastic until the iron gate closes behind you and the room goes on fire.
Its amazingly simple to get started. It will push the products into a shoppingCart array, do the arithmetic adding up the prices. Clearly not something you should pay for. It's one hell of a deal - for them.
I'm sure there is a special place in hell for self proclaimed developers who want to help shopify create a playstore/appstore like monopoly. I'm happy they are this terrible at everything nice.
But the getting started process is wonderful. Its all fantastic until the iron gate closes behind you and the room goes on fire.
This is a familiar struggle, as far as the concepts. I did a rather similar project based on Etsy about 10 years ago. We made a javascript-invoked widget (probably an iframe IIR), intended to be embedded onto blogs and webpages with a single line of code. This gathered a lot of data from Etsy. Shop details, items for sale, feedback, favoriters. Somewhere there's an article on the Etsy blog, but if curious you can check out this blog article. http://happycloudmoments.blogspot.com/2010/07/craftcult-intr...
At the time I already had a popular site based on their API. I had noticed that in general, it's a tough business to be a disconnected 3rd party developing on a closed platform. You're at the whim of the platform owner, slave to their intentions and decisions, good or bad. It's like having a remote job where nobody talks to you.
I got over API unreliability with a system to retry calls a few times. Etsy API calls could fail in several distinct ways, so my parser had a lot of stages (check for HTTP status, parse for certain strings, check if it's empty or an empty string, so forth). The calls also occasionally took much longer than usual. I implemented a caching system for the widgets.
It sounds like Shopify reliability is much worse than Etsy's at the time. Other than outages, I believe we'd get about 2% of calls failing for different reasons, which would usually work on a retry.
Changes were difficult to deal with because they could come suddenly. The worst ones were breaking changes that apparently Etsy was unaware of. I'd start getting errors and have no idea if it was a bug or an intentional change, and write workarounds only for them to fix the bug a few days later. We also experienced the removal of features with other apps. Or, one time we spent a couple months on a feature and then it turned out Etsy had been working on the same thing themselves.
At the time I already had a popular site based on their API. I had noticed that in general, it's a tough business to be a disconnected 3rd party developing on a closed platform. You're at the whim of the platform owner, slave to their intentions and decisions, good or bad. It's like having a remote job where nobody talks to you.
I got over API unreliability with a system to retry calls a few times. Etsy API calls could fail in several distinct ways, so my parser had a lot of stages (check for HTTP status, parse for certain strings, check if it's empty or an empty string, so forth). The calls also occasionally took much longer than usual. I implemented a caching system for the widgets.
It sounds like Shopify reliability is much worse than Etsy's at the time. Other than outages, I believe we'd get about 2% of calls failing for different reasons, which would usually work on a retry.
Changes were difficult to deal with because they could come suddenly. The worst ones were breaking changes that apparently Etsy was unaware of. I'd start getting errors and have no idea if it was a bug or an intentional change, and write workarounds only for them to fix the bug a few days later. We also experienced the removal of features with other apps. Or, one time we spent a couple months on a feature and then it turned out Etsy had been working on the same thing themselves.
I've heard shopify has been shaking down SaaS apps for past revenue % which they charge outside of the shopify ecosystem. Does anyone know if this is true or have more details?
Their terms seem a little unclear to me, but it seems that they claim they are due a percentage of anything you charge a customer who uses your Shopify app, even if you don't bill extra for use of that app.
However in practice I have found Shopify not too strict about fees charged outside of Shopify. I suppose if you were actually charging your customers specifically for the app but doing it outside Shopify to avoid the cut they would come after you.
I find BigCommerce a worse offender here. They copied Shopify's terms and constantly hound you asking for a cut of money even if you offer a free plugin with your standard service. Their method of collecting this info is also arcane, manual, and threatening. I would drop BigCommerce support in a second if they challenged us on this. So far they have backed down when we tell them we don't charge extra specifically for BigCommerce. But they still hound us monthly to submit a $0 report.
However in practice I have found Shopify not too strict about fees charged outside of Shopify. I suppose if you were actually charging your customers specifically for the app but doing it outside Shopify to avoid the cut they would come after you.
I find BigCommerce a worse offender here. They copied Shopify's terms and constantly hound you asking for a cut of money even if you offer a free plugin with your standard service. Their method of collecting this info is also arcane, manual, and threatening. I would drop BigCommerce support in a second if they challenged us on this. So far they have backed down when we tell them we don't charge extra specifically for BigCommerce. But they still hound us monthly to submit a $0 report.
Yes, this is true. There's a lot of pressure, I suspect, since they've come out as a publicly traded company.
I've built on Shopify before. While they're great, you'll find that it's hard to grow your company in it (save for a few notable exceptions). And then there's the platform dependent nature of it all.
I would not build a business on top of another company's platform.
I've built on Shopify before. While they're great, you'll find that it's hard to grow your company in it (save for a few notable exceptions). And then there's the platform dependent nature of it all.
I would not build a business on top of another company's platform.
They did that for a couple developer companies that were intentionally not paying their rev-share agreement. There was an article on HN about it recently.
It made sense that they would take down bad actors in the community.
It made sense that they would take down bad actors in the community.
In support of the platform:
* I've never had zero options for solving a problem. Ten years ago, I needed to build a customer login system on top of Shopify. (Like, before Shopify had one of its own.) I had enough room to do that in javascript, and it became an app called Gatekeeper. (Today's spiritual successor: Locksmith.)
* Whoever works on patterns at Shopify does a really, really good job. They think through things slowly and thoroughly, resulting in resource models that that are usually refined over time, instead of remodeled entirely. This is a good sign.
* This is a second bullet point to underscore the previous point about Shopify's pattern-making. I've been on this platform for a decade straight, and I don't deal with systemic inconsistency. I'm only here because Shopify is really, really good at patterns.
* This is a third pattern-related point to observe that Shopify usually defers solving a problem, rather than putting forward a fragile or brittle solution. (How long did it take for order editing to arrive?) By my reading, they'd rather take a while to land on and deliver a solution that will create a broader future, than more quickly deliver a solution that will limit the future.
* Yes, there are occasionally major/breaking API changes. Honestly, I love this. For me, it forces the whole system to stay engaged, and stay alive. Yes, I know the counter-arguments to this. :)
This is why I'm still here, ten years later. Yes, some things are short-term hard. But the things that are long-term important are all locked in.
---
Also yeah, building and sustaining an app is work. This is part of why I made https://apps.shopify.com/mechanic. I love the Shopify platform, so, so much, and also I needed a way to solve really specific problems more quickly, and keep those solutions running more sustainably. So: platform within a platform. Lots of nested similarity here, in the way that Shopify thinks about solving problems and the way Mechanic thinks about solving problems within Shopify.
* I've never had zero options for solving a problem. Ten years ago, I needed to build a customer login system on top of Shopify. (Like, before Shopify had one of its own.) I had enough room to do that in javascript, and it became an app called Gatekeeper. (Today's spiritual successor: Locksmith.)
* Whoever works on patterns at Shopify does a really, really good job. They think through things slowly and thoroughly, resulting in resource models that that are usually refined over time, instead of remodeled entirely. This is a good sign.
* This is a second bullet point to underscore the previous point about Shopify's pattern-making. I've been on this platform for a decade straight, and I don't deal with systemic inconsistency. I'm only here because Shopify is really, really good at patterns.
* This is a third pattern-related point to observe that Shopify usually defers solving a problem, rather than putting forward a fragile or brittle solution. (How long did it take for order editing to arrive?) By my reading, they'd rather take a while to land on and deliver a solution that will create a broader future, than more quickly deliver a solution that will limit the future.
* Yes, there are occasionally major/breaking API changes. Honestly, I love this. For me, it forces the whole system to stay engaged, and stay alive. Yes, I know the counter-arguments to this. :)
This is why I'm still here, ten years later. Yes, some things are short-term hard. But the things that are long-term important are all locked in.
---
Also yeah, building and sustaining an app is work. This is part of why I made https://apps.shopify.com/mechanic. I love the Shopify platform, so, so much, and also I needed a way to solve really specific problems more quickly, and keep those solutions running more sustainably. So: platform within a platform. Lots of nested similarity here, in the way that Shopify thinks about solving problems and the way Mechanic thinks about solving problems within Shopify.
Ah, I was going to build an app just like that! Guess not, anymore.
Looks like you took a cool idea and did an awesome job of executing of it!
>Locksmith
Are your customers B2B mainly?
Are your customers B2B mainly?
Biggest issue I'm dealing with is their integrated iframe app view and trying to persist a session since cross-site cookies are being blocked more and more. For instance Safari now blocks them by default and Chrome announced they are doing the same. That means when the user logs in via the frame, you can't set a cookie or add a jwt to the localstorage. All blocked and there are no workarounds. Awesome.
Does anyone have any experiences with Saleor? Shopify's tech seems like a clusterfuck by 2021 standards in a lot of ways (Liquid templates make theme reusability a pain or borderline impossible; backend issues mentioned in this thread), and yet, I'm not sure any of its mature proprietary competitors (Magento, BigCommerce, etc) are any better; if anything, I consistently hear that they are worse with some caveats.
What I am trying to figure out is if Shopify is "bad" or just "warty" -- I realize that is subjective and heavily depends on what one is trying to use it for, but it's still a challenge to reason about.
What I am trying to figure out is if Shopify is "bad" or just "warty" -- I realize that is subjective and heavily depends on what one is trying to use it for, but it's still a challenge to reason about.
We use a forked and heavily modified Saleor at Brava (https://www.brava.com). Our version is over two years old. It brings with it all of the headaches of running your own eCommerce. At the time we chose it because of our requirements. If you want to geek out and implement lots of custom eCommerce stuff then go for it. It's a pretty good platform, but it's custom eCommerce, and eCommerce is complicated. If I just wanted to sell things I'd personally use Shopify or Webflow or such.
Thank you for the trust in Saleor jconley - Brava looks great! Mirek from Saleor here. While we originally started with the idea of fork-it-and-make-it-your-own, a huge part of our effort over the last 2 years was to provide enough API and structure to help avoiding forking. Extensibility through our plugins and extensions system (Saleor Apps) has became one of the big goals of the project and most big brands today don't take the forking route anymore. It's all about front-end development now with Saleor (where we recommend using NextJS or Gatsby as a "glue" for a JS/TS app). To further free developers' time we also developed Saleor Cloud and the burden of maintenance, upgrade and performance are on us.
Hi -- glad to see you in my subthread! First of all, Saleor's codebase seems a lot closer to modern modularity than the rest of the open source e-commerce system, and so I like it architecturally from a high level. The main wrinkle I've seen, as you mention, is that I'd love to use Saleor in django as an app without having to fork it, which as of when I last looked at it (about 4-5 months ago) still wasn't possible.
This is because what I'm interested in is doing interesting things with the Saleor backend using it as a library not as a server, so to speak. That is to say, I'd like to be able to `pip install saleor` on my existing django backend, plug it into my app, and away I go without too much issue. How far away is Saleor's backend from this right now? Is this doable and it's just a matter of a finite number of steps, or are there deep structural challenges to supporting this sort of use case?
Thanks!
This is because what I'm interested in is doing interesting things with the Saleor backend using it as a library not as a server, so to speak. That is to say, I'd like to be able to `pip install saleor` on my existing django backend, plug it into my app, and away I go without too much issue. How far away is Saleor's backend from this right now? Is this doable and it's just a matter of a finite number of steps, or are there deep structural challenges to supporting this sort of use case?
Thanks!
Thanks! I see what you're saying about Django apps but currently this is not a priority and taken the size of the project wouldn't be easy.
> You're going to integrate your code into their proprietary platform, so they need the integration to be as straight forward as possible. Thus an SPA is a very good candidate.
This makes no sense.
This makes no sense.
I built a shopify app for my ecommerce monitoring system and my system is mostly written in PHP I have some Go and Python for various stuff by the core is in PHP mainly because I think PHP is really good language for web apps, it's designed for it, literally. I went to use the Shopify php library and it's literally dead, I looked at the issues and there was a Shopify employee advising people to use an unoffical one that basically supports everything. It's cool the employee pointed people in the right direction but I think it's a sad state of affairs that one of the most popular web programming languages in the word has no support from them.
Also, the reason people can't use Shopify with my system yet is that even to be approved for an unlisited application you need to allow for account creation via Shopify. I understand for listed apps in the store but if I want to have an app where they click a button on my site and I connect to their shopify system and get data I still need to support this feature I won't use. That saddened me. I just need to create time to allow for account creation via their app store and figure out what that means getting the info and how to handle user confirmation if at all.
(Shameless plug - https://www.ootliers.com)
Also, the reason people can't use Shopify with my system yet is that even to be approved for an unlisited application you need to allow for account creation via Shopify. I understand for listed apps in the store but if I want to have an app where they click a button on my site and I connect to their shopify system and get data I still need to support this feature I won't use. That saddened me. I just need to create time to allow for account creation via their app store and figure out what that means getting the info and how to handle user confirmation if at all.
(Shameless plug - https://www.ootliers.com)
I recently got an app on to the Shopify app store. The review process is the worst that I've been through.
My rejections in chronological order:
1. Rejected for having text in the app icon. The text was our company's name and is our logo which we had to change for Shopify...
2. Rejected because we didn't implement the GDPR webhooks. We don't operate in Europe so I didn't think they apply. I could have read this in the documentation but still...
3. My shop set up geographic restrictions for a few South East Asian countries and the shopify tester tested with a store with an Albania as the country, USD as the currency, and a fictional address. Shopify actually prevents this kind of invalid installation (that's the whole point of the geographic restriction). So when my store rejected his onboarding attempt with a generic error due to what was previously thought to be nothing more than a sanity check, he rejected my app and imposed a 2 week ban on my partner account from resubmitting.
Ultimately, I was able to appeal the decision through a different channel. We had our first customer waiting to use our app so this added an extra 10 days of delay and a whole bunch of unneeded stress in my startup.
My rejections in chronological order:
1. Rejected for having text in the app icon. The text was our company's name and is our logo which we had to change for Shopify...
2. Rejected because we didn't implement the GDPR webhooks. We don't operate in Europe so I didn't think they apply. I could have read this in the documentation but still...
3. My shop set up geographic restrictions for a few South East Asian countries and the shopify tester tested with a store with an Albania as the country, USD as the currency, and a fictional address. Shopify actually prevents this kind of invalid installation (that's the whole point of the geographic restriction). So when my store rejected his onboarding attempt with a generic error due to what was previously thought to be nothing more than a sanity check, he rejected my app and imposed a 2 week ban on my partner account from resubmitting.
Ultimately, I was able to appeal the decision through a different channel. We had our first customer waiting to use our app so this added an extra 10 days of delay and a whole bunch of unneeded stress in my startup.
I think I remember seeing your thread (and responding to it). That sucks.
I'd be curious if any of the Shopify app devs in this thread have an opinion on how they handle customer data.
As a Shopify store owner, I was aghast how common it was on the platform to require allowing third party apps entirely too much information about my end customers. I was very uncomfortable leaving some otherwise promising apps installed in my store, and eventually gave up on Shopify entirely.
As a Shopify store owner, I was aghast how common it was on the platform to require allowing third party apps entirely too much information about my end customers. I was very uncomfortable leaving some otherwise promising apps installed in my store, and eventually gave up on Shopify entirely.
What did you move to?
> To my surprise every 10 refreshes or so, I would get a 404 error. For the hardcoded resource no less! It's frustrating to work with an API that already seems unreliable when testing locally.
Google actively does this with many of their APIs. Running locally, their APIs will be very unreliable. Once you're live on the domain you've configured, everything is much more reliable.
I don't know if they do it to force you to consider cases where the API returns errors, or if it's some kind of anti-scraping provision, but it can be extremely confusing and frustrating if it's your first time working with the API and you're not sure how things are going to actually work (if at all!) when you deploy.
Google actively does this with many of their APIs. Running locally, their APIs will be very unreliable. Once you're live on the domain you've configured, everything is much more reliable.
I don't know if they do it to force you to consider cases where the API returns errors, or if it's some kind of anti-scraping provision, but it can be extremely confusing and frustrating if it's your first time working with the API and you're not sure how things are going to actually work (if at all!) when you deploy.
To the OP, they do provide the raw HTML to Polaris Components (this is what I use -- I don't know React). Not sure if that's the same as HTML "components" though.
[deleted]
The Checkout thing is a con that prevents fairly run of the mill stuff like conversion tracking sigh
[deleted]
Are there any viable alternatives to shopify for developers that don't have these issues?
+1 on page layout
>Integration with the shop frontend is difficult if you're not making a theme
As someone on the opposite end of this problem (I'm in custom theme development), the client wanting to install a new app is an immediate source of frustration for reasons almost completely out of your or their control.
If your app just gives us a manual install option, that's usually the best solution for me. I can make judgments as a developer as how best to incorporate your app into my theme. Furthermore, because I'm doing it manually, I get to follow all of my version control and testing practices. You see, Shopify actually promotes some very terrible development practices (not your fault). I have to avoid that by working in development themes, storing all my code in a self-hosted Git repository elsewhere, tagging all my production deploys, and using Git to tell me what files have been changed so I can be ultra-conservative in my deploys. Why do I need to do that? Well...
Some apps have automatic installers, which try to guess what theme you're using and then install files as they wish to the current production theme. Not only is that dangerous (what if the app breaks something?), even if the app does install correctly; it usually doesn't hit the developer themes and any developer working out of the Git tree is now working with stale files. I have to pull theme exports and compare changes to reverse-engineer what was added so that we don't wind up accidentally uninstalling half the app when we change a product template or something.
Part of the problem is that Shopify is specifically designed to be both "easy to use" and give it's merchants a high level of control over their storefront. This precludes a lot of otherwise obvious solutions to this problem, for various reasons:
1. You can't use Git as a deployment mechanism because it has a terrible UX and most new merchants aren't going to figure out how to use it. Even with a non-terrible UX you still need to educate users about it's various failure modes, including merge conflicts and the like. 2. It would be nice to have standard extension points between app and theme developers, but that winds up tying the hands of both a little. Part of the problem is that any level of extensibility also either takes things out of the hands of theme developers, or requires new users understand how to implement the component. I was hoping something like the new section system (which I haven't gotten a chance to play around yet) would fix this for app developers.
If Shopify was willing to go a little bit up-market (and, given how they've become the favorite platform of Facebook scammers, they should) they could fix these problems by offering ways for theme and app developers to agree on specific extension points. This kind of ruins the whole "just edit this template to get a thing on your theme" aspect of it, but Shopify's really outgrowing what it started with IMHO.
(By the way, there's a special circle of hell reserved for page builder apps that store everything in the current production theme. I recently had to deal with a client whose shop no longer allowed them to clone their main template as it was full of literally hundreds of templates and assets from this one app. After literal hours of manual garbage collection, I was able to get it to the point where a theme clone merely took 20 minutes rather than failing outright.)
As someone on the opposite end of this problem (I'm in custom theme development), the client wanting to install a new app is an immediate source of frustration for reasons almost completely out of your or their control.
If your app just gives us a manual install option, that's usually the best solution for me. I can make judgments as a developer as how best to incorporate your app into my theme. Furthermore, because I'm doing it manually, I get to follow all of my version control and testing practices. You see, Shopify actually promotes some very terrible development practices (not your fault). I have to avoid that by working in development themes, storing all my code in a self-hosted Git repository elsewhere, tagging all my production deploys, and using Git to tell me what files have been changed so I can be ultra-conservative in my deploys. Why do I need to do that? Well...
Some apps have automatic installers, which try to guess what theme you're using and then install files as they wish to the current production theme. Not only is that dangerous (what if the app breaks something?), even if the app does install correctly; it usually doesn't hit the developer themes and any developer working out of the Git tree is now working with stale files. I have to pull theme exports and compare changes to reverse-engineer what was added so that we don't wind up accidentally uninstalling half the app when we change a product template or something.
Part of the problem is that Shopify is specifically designed to be both "easy to use" and give it's merchants a high level of control over their storefront. This precludes a lot of otherwise obvious solutions to this problem, for various reasons:
1. You can't use Git as a deployment mechanism because it has a terrible UX and most new merchants aren't going to figure out how to use it. Even with a non-terrible UX you still need to educate users about it's various failure modes, including merge conflicts and the like. 2. It would be nice to have standard extension points between app and theme developers, but that winds up tying the hands of both a little. Part of the problem is that any level of extensibility also either takes things out of the hands of theme developers, or requires new users understand how to implement the component. I was hoping something like the new section system (which I haven't gotten a chance to play around yet) would fix this for app developers.
If Shopify was willing to go a little bit up-market (and, given how they've become the favorite platform of Facebook scammers, they should) they could fix these problems by offering ways for theme and app developers to agree on specific extension points. This kind of ruins the whole "just edit this template to get a thing on your theme" aspect of it, but Shopify's really outgrowing what it started with IMHO.
(By the way, there's a special circle of hell reserved for page builder apps that store everything in the current production theme. I recently had to deal with a client whose shop no longer allowed them to clone their main template as it was full of literally hundreds of templates and assets from this one app. After literal hours of manual garbage collection, I was able to get it to the point where a theme clone merely took 20 minutes rather than failing outright.)
I just don’t get why people continue to build around Shopify. Is Stripe/Square not good enough? Don’t you save a ton by forgoing Shopify?
Shopify offers a full ecom platform and let's you launch in days if you really have to. Upfront you aren't paying anything. Creating Shopify's functionality will take you years and hundreds of thousands of dollars to develop.
Years? I did it in a week. Shopify is a platform of value add services. I can see mom and pops using it but not devs.
You did not recreate Shopify in a week. You think you did but you only implemented a custom solution that does 5% of what Shopify offers, including the expensive stuff like compliance, support, etc.
No sane business is going to use a random dev with a total custom e-commerce solution when they could throw a couple of dollars at shopify each month and get 100x the value.
No sane business is going to use a random dev with a total custom e-commerce solution when they could throw a couple of dollars at shopify each month and get 100x the value.
This sounds interesting. I sincerely thought a shop was just a website displaying products. I got this idea to work. People can buy things. Was that not the point? I can hear you wonder but yes, I'm really this naive. You are saying I'm missing out on 100x the profit? Could you give one or more examples of this?
If we drop all of the things not useful to developers (or actively get in the way) I'm left with:
Logically, at least some of the 1500 ready made adons must do something that is hard to make yourself. The downside is that you have to pay and that writing things (not available in their app store) yourself might be hard to impossible.
They offer SEO tools which (I hear) are quite good. End of the day yours is just another shoppify shop which makes it hard to compete with others doing the same thing on the same platform. WooCommerce is argued to provide better results. I have no idea how a self made website compares.
Integration with accounting software, shipping providers and payment processors out of the box is kinda nice but one should be able to figure this out.
There are also hundreds (joking) of downsides that I'm not able to judge.
Overall it seems a good solution if your store isn't to small and isn't to big. It might be fun using it to buy time while you transition from small custom to a large custom solution.
Logically, at least some of the 1500 ready made adons must do something that is hard to make yourself. The downside is that you have to pay and that writing things (not available in their app store) yourself might be hard to impossible.
They offer SEO tools which (I hear) are quite good. End of the day yours is just another shoppify shop which makes it hard to compete with others doing the same thing on the same platform. WooCommerce is argued to provide better results. I have no idea how a self made website compares.
Integration with accounting software, shipping providers and payment processors out of the box is kinda nice but one should be able to figure this out.
There are also hundreds (joking) of downsides that I'm not able to judge.
Overall it seems a good solution if your store isn't to small and isn't to big. It might be fun using it to buy time while you transition from small custom to a large custom solution.
Former Magento Cloud team member here.
Most ecomm businesses are more complex than connecting a front end to a payments gateway. Generally requires multiple complex systems (Product Management System, Order Management System, CRM, etc) to work together seamlessly. This is where platforms like Shopify or Magento are really valuable. They give you all the pieces you need to build your business w/o needing to reinvent the wheel.
Most ecomm businesses are more complex than connecting a front end to a payments gateway. Generally requires multiple complex systems (Product Management System, Order Management System, CRM, etc) to work together seamlessly. This is where platforms like Shopify or Magento are really valuable. They give you all the pieces you need to build your business w/o needing to reinvent the wheel.
Don't forget inventory management, warehouse management, shipping etc.
Often platforms do a little of these themselves but lots of businesses have needs that require them to use specialised solutions that handle those aspects of their business better than Shopify does as each is a complex domain in its own right.
Often platforms do a little of these themselves but lots of businesses have needs that require them to use specialised solutions that handle those aspects of their business better than Shopify does as each is a complex domain in its own right.
Stripe is only good for payments. Square does storefronts, but I have no experience with them. Shopify is “good enough” if you need to get a storefront up quickly, and integrate with payments and shipping.
What does Shopify offer that a stripe integration doesn't?
Apples to Oranges.
Shopify allows non devs to easily set up an ecommerce store, that is their biggest value add. Things like inventory management, shipping, site hosting etc.
Shopify allows non devs to easily set up an ecommerce store, that is their biggest value add. Things like inventory management, shipping, site hosting etc.
I read "Shopify App" as one that clones/competes with Shopify. I prefer "app that uses Shopify"
Shopify has an app store, similar to apple's app store. This is what the article is referring to.
I didn't know that it had gone from being a payment API to a developer platform.
* I can concur that their API is unreliable. About 1 in 5 of my CI runs fail with mysterious 500 errors. It's infuriating.
* The support channels are a wasteland. Do not expect help.
* The documentation is super thin. At first glance it looks decent - there's the objects, there's the fields those objects have. But it's missing all the details about how those fields are supposed to work. Example: A Fulfillment has a tracking_numbers array, but there doesn't seem to be any way to add multiple tracking numbers. The docs are silent, and questions about this in the support channels remain unanswered. For years.
* There are two completely different APIs (graphql and REST), which do not have equal capabilities. If Shopify is planning on deprecating one of them, they should give us guidance.
* The API is inconsistent. I count at least FIVE different representations of an Address structure, each slightly different for no apparent reason. Eg "country" vs "countryCode". This is the kind of thing that creeps into projects in dynamic languages when nobody's paying attention.
* There's a lot of overengineered stuff. The Metadata API is really unpleasant compared to Stripe's simpler approach.
* There's no way to set up common shipping scenarios like "$N for first item, $M for each additional".
I could go on. But I will say this: It's better than Etsy's API. Though Etsy is finally working on it again, so maybe that will change.