In Memoriam: Order Updater
As a member of its core team, I always want to make Solidus better. There are literally endless ways I could do that. Lately, I've been spending some time directing open-source work at Super Good. I've been helping folks on the team find things to work on and coaching some of them through that work.
The team has a big piece of work on the go: the in-memory order updater. The current order updater is the class responsible for examining an order and ensuring that its state is up-to-date and consistent.
An order's state might not be up-to-date and consistent for a variety of reasons. A very common reason is that an item was added or removed from the order. When this happens, we need to ensure taxes are updated, recalculate the shipments, and may need to apply/remove promotions. For example, if the item removed had triggered a free shipping promotion, that promotion would need to get removed.
Most operations that modify an order call out to the order updater. It's one of the more important objects in Solidus.
At Super Good, we're working on replacing the current order updater. Our new order updater will be capable of operating on orders that are already loaded into memory without touching the database.
We're doing this for two reasons. First, loading all the records associated with an order and then doing all the "updating" should be more performant. It's an easy win. There are certain things that you can't expect to be preloaded (global state like the shipping configuration, tax configuration, and promotions), but you can preload all of the order state.
The more important reason is that the in-memory order updater allows us to simulate operations on orders. This allows us to, for example, tell a customer how much their order would be if they added a certain item to it with absolute certainty, factoring in promotions and other dynamic behaviour.
We know that people have built subscription systems on Solidus that emulated this behaviour, but in ways that weren't 100% reliable. We also know that at least one store created an in-memory updater. Unfortunately, that code wasn't contributed back to Solidus.
Keep an eye on that PR. We're spending a little time on it each week and hope to get some stores testing it soon. Once available, you should get some free performance by switching to it.
This week's episode of Dead Code dove into debugging distributed systems using simulation testing, but that topic wasn't what stood out to me.
Stevan's insight that Erlang's strength isn't in BEAM's lightweight process model as much as in OTP's library of behaviours is really interesting. It makes me wonder if that's something that Ruby could use.
Rails provides conventions and structure. That's good and we like that, but it's only useful if you're building the kinds of web applications that fit into that model. Luckily, that's most web applications, but web applications aren't everything.
I can imagine a set of more general-purpose building blocks and conventions for building Ruby applications that one might use for all kinds of applications. I don't really know what that would look like, but it's an interesting idea.
I listen to some weird shit. I know. Today, I'm not going to link you to some weird-ass extreme metal. Dutch symphonic metal legends, Epica, dropped a new album. It's fun, cheesy goodness. Give it a listen.