Software is Not Just Some Code Run on a Computer

When it comes to software development, we’re pretty assertive about it. There are couple of stances we proudly embrace and which influence our decisions the most.

In SpiceFactory, software is a set of concepts beautifully relying on each other to solve complex problem in a simple way.

Every code fragment that comes out of this factory has to be well-thought-out and intuitive to reuse, maintain or improve.

That way, we’re optimizing one of our development key performance indicators — impact to development-cost ratio.

It is impressive how just a little bit smarter than usual abstractions can make development of robust solution a piece of cake.

We do not just “make it work” or “get the job done” — we think, engineer and disrupt.

And just as our own software has to be out-of-this-world good, so does the third-party software we rely on.

Tools and libraries we use meet the highest standards of benefits it provides to the UX and developer satisfaction.

That’s why we’ve decided to jump on board the reactive movement — most prominently React and Akka.

React

User interfaces allows humans to interact with machines programmed to fulfill some of their needs. And that willy-nilly includes some state UI has to reflect.

Let’s use Trello for an example, as it is highly reactive app — whatever happens on server every affected client is updated in near realtime.

Here are couple of facts that are part of the state:

• Which board is the user looking at?
• Is the search box focused?
• Are tickets filtered?
• To whom is the ticket assigned?

Every time any of the facts changes, UI has to be updated. We could rerender whole page just to be safe, but that’s a big no-no as it is a costly operation and we loose some benefits browsers provide us (eg. maintaining the focused state on an input field, while something else is modified). On the other end, we could update only the affected elements.

Traditionally, if we decided to go fully optimal, we would maintain all the mutator handlers to carefully take all of the facts, not just the changed one, into the account and deal with DOM accordingly. The amount of code and, inherently, the cost spirals out of the control easily, as for each fact we have to write a handler which references every other handler — that’s exponential code growth in worst case. Unacceptable.

React solves this problem really good — you get hooked on it the first time you try it. It’s so intuitive because it combines simplicity of a full page rendering with the optimality of minimal DOM updates.

The core of the solution lies in the virtual DOM React provides and uses. Briefly, the app developer writes down how does the whole page render given the state, and the React maintains the browser DOM by:

1. rendering the whole page into a virtual DOM on each state change (with couple of optimizations here and there),
2. making the diff between virtual and browser DOM, and ultimately
3. applying a set of minimal changes to the browser DOM.

Incredible.

Akka

To support epic (interactive and timely as a video game) interfaces, there has to be reactive solution on the backend too.

Such apps often have plenty of events to pass around multiple affected clients and disposable derived data that has to be incrementally computed. And that is solved and maintained with ease using actors and message passing.

In short, we wrap all mutable data kept in memory inside actors. That way, access to that data is synchronous and all mutations are easy to trace because only that actor can change it.

We’ve had (and are still having) a great time crafting well designed and highly dynamic solutions using this approach.

---

That being said, if you are an exceptional individual and like (or even strongly dislike) what you’re seeing on our blog, you’re invited to stop by our office and say hi — we’d love to meet you.