The Great Big Awful World of Ecommerce Frameworks

I’ve been researching ecommerce frameworks for a project I’m embarking on. My key requirements are pretty simple:

Manage small inventory of physical goods (a few dozen SKUs to start with)
Manage fulfillment (shipping workflow) of said goods
Allow for custom discounts based on presence of specific goods in order
Light and fast
Ideally open-source, as I plan on managing deployment and hosting

Also relevant is the fact that I plan on being the sole administrator of this webshop for the foreseeable future, so it’s ok if the system isn’t wrapped in a nice gui. I also don’t expect tons of order volume.

As far as priorities go, speed is up there. So many webshops are frustratingly slow these days, partially due to growing payloads (css/js/images), but also due to dynamic page rendering. A snappy website just feels so much better, and it’s common knowledge that slow sites have a higher bounce rate.

My first thought was to build a static site and use a client-side cart. There’s a neat service out there called Snipcart that aims to fill this niche. They offer all the stuff you’d expect from an ecommerce platform, but via some client-side js. This approach is cool, but it’s not free. Snipcart also doesn’t seem to offer custom discounting logic, which would mean I’d need to write my own and integrate it.

Another problem is reflecting inventory on the site. Unless I’m willing to set up a webhook that listens for out-of-stock events and rebuilds the site, I have to settle for out-of-stock being shown only in the cart instead of on the product page. Not ideal. Here’s a post that evaluates this approach in more detail if you’re interested..

Again, it’s not free. I don’t really want to be tied into a vendor at this point.

So I sighed and went out in search of a suitable monolith. I was pretty set on finding something built on Django, since I have some experience with it and Python is what I know best. Turns out there are two decent solutions out there, Oscar and Saleor. Oscar is a more traditional “framework”; you inherit a bunch of base classes, fill them in with your business logic, and go. It ships with a basic front-end, but it’s pretty dated looking and would likely need to be replaced, as opposed to tweaked.

Saleor is a bit of a different animal. It’s set up less like a framework and more like a forkable project to pick up on. It’s also less generalized than Oscar, and seems aimed more squarely at physical goods. It ships with a nice reactive front-end, and a very slick react-based admin dashboard. Front-end is not my strong suit, so this is very nice. It’s actively developed by mirumee software.

A promising feature of Saleor (though not immediately relevant to me) is its out-of-the-box GraphQL API. This makes it easy to treat Saleor as the One True App, and write a native mobile app (or whatever) around it. This also opens up the possibility of tying in a physical POS system.

So this all sounds good. I got a local version running and played around with it. It feels pretty good. Code is laid out nicely, much more intuitively than Oscar. The front-end payload is reasonable, with the homepage html/css/js coming in just under 700KB uncompressed, most of that being js. I wouldn’t call it light, but it’s pretty good compared to most of the webstores I tested. I plan on serving the heavy stuff via a CDN anyway. You can play with the demo here.

All in all I feel pretty good about using Saleor for this project. I won’t be able to do much building of the webstore until more work is completed on the products and branding, so I’ll report back then.