[HN Gopher] What I wish I knew before building a Shopify App
___________________________________________________________________
What I wish I knew before building a Shopify App
Author : Dragony
Score : 206 points
Date : 2021-03-19 15:40 UTC (7 hours ago)
(HTM) web link (ma.ttias.ch)
(TXT) w3m dump (ma.ttias.ch)
| LMYahooTFY wrote:
| 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.
| tyingq wrote:
| 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.
| isaacbowen wrote:
| 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.
| picodguyo wrote:
| 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.
| that_guy_iain wrote:
| 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)
| hahahahe wrote:
| 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?
| arkitaip wrote:
| 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.
| hahahahe wrote:
| 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.
| arkitaip wrote:
| 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.
| clintonb wrote:
| 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.
| sarora27 wrote:
| 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.
| stickfigure wrote:
| I built a print-on-demand system that integrates into Shopify
| stores. To vent a little...
|
| * 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.
| 8note wrote:
| 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
| disantlor wrote:
| There are definitely several ways to set up complex Shopify
| shipping situations. My livelihood is in good part based on it.
| stickfigure wrote:
| 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.
| disantlor wrote:
| 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.
| theturtletalks wrote:
| 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?
| stickfigure wrote:
| Yes, although you'll probably find that we are not an obvious
| fit for that model. Company info is in my profile.
| deedubaya wrote:
| 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?
| JaggedJax wrote:
| 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.
| drchiu wrote:
| 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.
| boringg wrote:
| 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.
| darepublic wrote:
| What does Shopify offer that a stripe integration doesn't?
| paultannenbaum wrote:
| 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.
| isoskeles wrote:
| 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.
| trutannus wrote:
| 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.
| chiefalchemist wrote:
| 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?
| jeromegv wrote:
| 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.
| chiefalchemist wrote:
| 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.
| lawwantsin17 wrote:
| Shopify is API garbage. I can't believe these idiots are eating
| e-commerce.
| sarabad2021 wrote:
| 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.
| colesantiago wrote:
| 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.
| harlanlewis wrote:
| > 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.
| iamdbtoo wrote:
| 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.
| dubcanada wrote:
| 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.
| theturtletalks wrote:
| 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.
| colesantiago wrote:
| 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.
| Cerium wrote:
| 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.
| bombcar wrote:
| 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.
| mingabunga wrote:
| 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.
| drchiu wrote:
| 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
| colesantiago wrote:
| *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.
| colinloretz wrote:
| 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.
| colesantiago wrote:
| 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.
| colinloretz wrote:
| 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.
| colesantiago wrote:
| 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.
| colinloretz wrote:
| 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.
| [deleted]
| LargeWu wrote:
| They integrate with a lot of payment gateways, even if Stripe
| isn't one of them.
|
| https://www.shopify.com/payment-gateways/united-states
| colesantiago wrote:
| 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.
| toomuchtodo wrote:
| Is Gumroad a better fit perhaps for this use case?
| colesantiago wrote:
| 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?
| toomuchtodo wrote:
| 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/
| SahAssar wrote:
| In that case they still take 2% which is pretty absurd.
| xal wrote:
| Lots of really fair feedback here. We hear you.
| jloveless wrote:
| 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.
| ghostapps wrote:
| 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
| moron4hire wrote:
| > 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.
| code_duck wrote:
| 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.
| donutdan4114 wrote:
| 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.
| mehphp wrote:
| I had the same issue with rate limiting and they doubled mine
| just by asking. YMMV
| Axsuul wrote:
| Doubled it on just your store or for every store you
| integrate with?
| mehphp wrote:
| Every store; granted i asked years ago so not sure if they
| are as flexible now.
| alexbouchard wrote:
| For those of you that aren't in AWS ecosystem or is looking for
| a simpler alternative to EventBridge we've build
| https://hookdeck.io. A good chunk of our customers are either
| Shopify apps or shopify stores. We essentially provide a full
| webhook infrastructure (queuing, retry, alerts, monitoring) out
| of the box. It should help scaling your webhook usage without
| having to go out of your way to build complex ingestion and
| queuing.
| intrasight wrote:
| I read "Shopify App" as one that clones/competes with Shopify. I
| prefer "app that uses Shopify"
| paultannenbaum wrote:
| Shopify has an app store, similar to apple's app store. This is
| what the article is referring to.
| TedDoesntTalk wrote:
| > 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.
| bookmarkable wrote:
| 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.
| moneywoes wrote:
| What did you move to?
| yowlingcat wrote:
| 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.
| jconley wrote:
| 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.
| JRGC wrote:
| +1 on page layout
| drchiu wrote:
| 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.
| iamdbtoo wrote:
| 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.
| jakear wrote:
| > 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.
| elondaits wrote:
| 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.
| jakear wrote:
| 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.
| VRay wrote:
| Man, I wish app reviews worked that way.. relevant XKCD:
| https://xkcd.com/937/
| [deleted]
| danpalmer wrote:
| 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.
| drchiu wrote:
| > 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.
| bwship wrote:
| Keeping your app relevant because the API it is built upon is
| unstable or has breaking changes is hardly a good.
| cosmodisk wrote:
| 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.
| pbreit wrote:
| "Good because if forces you to update"
|
| That's the opposite of good.
| triceratops wrote:
| > 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.
| bartread wrote:
| 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.
| jeromegv wrote:
| OP is wrong. While there's a new version of the API after
| few months, they support older versions for 18 months. They
| have versioning.
| vdfs wrote:
| Correct, but if you make one call to a deprecated api,
| your app will be unlisted immediately
| yowlingcat wrote:
| > 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.
| morpheos137 wrote:
| >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.
| SturgeonsLaw wrote:
| > 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.
| rexpop wrote:
| > forces you to...
|
| Never good.
| rxhernandez wrote:
| Python forces you to indent.
| nijave wrote:
| So code linters, code formatters, and style guides used
| in any well maintained code base.
| xmprt wrote:
| Python is a great language for other reasons. Forcing you
| to indent isn't one of those reasons.
| rxhernandez wrote:
| 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.
| RHSeeger wrote:
| 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.
| pbreit wrote:
| I don't really understand why developers use SDKs/libraries at
| all when the RESTful APIs are easy enough to consume directly.
| echelon wrote:
| 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.
| TedDoesntTalk wrote:
| > 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?
| nullsense wrote:
| 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
| jwgraves2 wrote:
| 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.)
| nirushiv wrote:
| > `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
| yen223 wrote:
| 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
| dubcanada wrote:
| 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.
| brunojppb wrote:
| 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.
| nsomaru wrote:
| Curious as to why this is being downvoted? Could down voters
| please share their views?
___________________________________________________________________
(page generated 2021-03-19 23:00 UTC)