I have a somewhat random question for this group. Our application has a requirement for an "estimate" API - basically, we need to be able to say "if you assembled this particular order with these variants at these prices, what would the total price look like?". It seems like we could achieve this by creating the Orders on the fly and saving them, but then at that point we end up churning the database more than we might otherwise need to. I guess I'm questioning whether it is at all a reasonable thing to attempt to create an Order in memory without saving it. Looking through some of the code, I kind of get the suspicion that there are too many callbacks/etc that will make that an impractical idea - but I'm curious if there's other suggestions. (Alternately, we could potentially explore making the changes persistent but in a transaction which is intentionally rolled back after we get what we need, but even that feels ... perilous)

Hey Tom! We did it in the past using the rolled back transaction. It’s weird for sure! Still, at the moment I don’t think there’s a better way to avoid saving useless records to the database. Another thing you might consider is caching the total: maybe if most of your orders look similar there are just a few arguments to build the cache key and this can save some performance. I never tried this approach in the wild so I may be missing something.

Ooh, that's an interesting suggestion re: caching. I wonder if that would work for us. I can play around with that a little bit.

Depends on the use case, but if they are generally short lived estimates, you could build a javascript solution using localstorage.

Interesting thought too! But unfortunately, this would need to be across platforms (mobile native included), so we need an API to do this at the backend level.

I know that Juul managed to completely rework their order updater to allow for fully in memory updates, so you could do all kinds of stuff with an order without persisting it (which allowed for use cases like this.) Sadly that was never contributed back.

Why can you not just have a ‘service’ object in backend, that just “adds up” product prices ? or you need all the adjustments (promotions, etc..) and shipments cost too ?

Yup, @Loic Mack - the estimate is ideally more inclusive than simply the prices of the items. We need tax, promotions, shipping, etc. That's why I'm playing around with transient orders.

In-memory order calculations are definitely on my personal bucket list, especially since it would allow to accurately compute the cost of future orders on a subscription. Curious to see what you end up doing, since it’s something I’m sure we’ll also evaluate adding to the core at some point!

One of the members of my time did a lot of the work on the in-memory updates at Juul, we'll have to get her involved in that when we get there.

I'll report back here as I investigate, and let y'all know what I end up going with.