[pixelbash]

Me, me!

I picked up Spree in 2015, and still build with it on a weekly basis.

The platform and its ecosystem both have ups and downs, for example the order system is quite complex[1]. For another I have yet to find a perfect way to architect complex extensions.

Most of Spree's power lies in its models. In hindsight my advice to myself would be: start with spree_core, modify the API (I like using cart api's on the frontend) and replace the backend/frontend entirely.

[1] https://github.com/spree/spree/blob/3-5-stable/core/app/mode...

[crisscrosscrash]

Glad to hear the models are sane. I'm trying to get off a horribly convulted system with many issues and have been keeping my eye on Spree for years. Any thoughts about choosing Spree vs Solidus at the point?

I basically have custom frontend everywhere including some of checkout and account pages, so I mainly need to replace cart and payments and checkout and may try to integrate at the API level and handle all UI custom.

I have a bunch of requirements that may need plugins: - Volume pricing - Personalization such that some products can exist in the cart multiple times, but each item has a unique ID - Upsells / add-ons for personalized product. I currently handle this hierarchy outside the cart, but it's brittle. There are thousands of different options per product and they change all the time. Quantities of these have different syncing rules in terms of their quantity vs their parent combined with quantities from an external data source e.g. address book. - Social login, potentially adding login and payments with Amazon. Pondering if it'd be best to go with Auth0.

Promotions seem really powerful which is good, because I use them heavily and would want to add custom ones.

Any thoughts, insights, suggestions given these goals? Looking to support 100k products and millions of promotions.

[pixelbash]

Sounds like an interesting project. I picked Spree over Solidus because Solidus is based on version 2.4 of Spree and I was already on version 3.0 at the time. The split was due to the company behind Spree being bought out but luckily for us another company stepped in and Spree is now moving quite quickly..

Have done personalised line items in the past, when adding to cart there is a function that checks not just the variant being added but the options being added with. The comparison hooks for these options are designed to be extended, so that one should be relatively easy. Complex price changes on orders/line items can be handled via adjusters. These also hook into orders and are very flexible (although I haven't had to build any).

Have also build custom integrations to sync inventory with an external source using webhooks, since everything is fundamentally just Rails underneath it's as easy as you might expect.

No experience with changing the auth system, but since there is a separate plugin for the authentication (spree_devise) I think the intention was/is to make it easy to swap out if needed. I don't know how easy that would be though. There is no address book out of the box (just a save last used address feature), that's one of the features I am finally adding now.

I think you could go one of two ways with this, either a) keep your code light using decorators etc and try to do everything the 'Spree' way so that you can benefit from an easy upgrade path or b) fork spree entirely and manually bring in updates from upstream. I am slowly leaning towards b) because Spree has some design decisions that are incredibly powerful but also make everything much more complicated. Mostly I am referring to the ability to split shipments on checkout here.. I spent hours tracking down a specific line that was rejecting a shipment once. I gave up entirely and replaced spree_frontend early on, but I am mostly a frontend developer.

[crisscrosscrash]

Thanks for insights here. Funny you mention split shipments because that's a current tricky area for me and one I wish my commerce system could handle. I create potentially many shipments from orders right now based on inventory, the types of add-ons chosen, where the buyer is, and current workload. Unfortunately right now, this is all done in a separate system so it's difficult to provide customers with good visibility on shipping times of each product up front.

[leviathant]

Hmm. The one thing that stuck out to me was "millions of promotions" - how are you quantifying that?

Are you developing/looking to develop this yourself internally as a retailer, or are you building this out on behalf of a retailer? Some of the other bits you've mentioned certainly sound complex (although this might be how you've approached these combinations of options and products), but not outside the realm of a Spree/Solidus or Workarea style implementation.

[crisscrosscrash]

I'm developing internally as a retailer. Having millions of coupon codes or gift cards is important for sales and doing deals with partners or sites like Groupon. Then, with many items across many categories, as well as tons of add-on options, application and stacking of multiple rules needs to be powerful, but it seems like Spree now provides all the tools to make that manageable.

[pixelbash]

Also a note around the number of products, I think you would be okay, promotions - see other comment, dynamic adjusters would be fine I think.

One thing to watch out for is Spree leaves cart level orders in the database, and deleting an order is not trivial. I have a cron job that deletes incomplete orders over a certain age, made after I realised ~90% of the database size was made up of abandoned cart data.

[crisscrosscrash]

Thanks that's good to know. Since I'm selling personalized things I'd probably keep all of the abondoned carts around so they're still there when people return. My current database stores all the abandoned carts in serialized blobs with Java objects so anything is better than that for maintenance!