Auxilium 3

This is our third major iteration of the Auxilium case management portal.

In this article, I'll talk about what Auxilium 3 will be bringing to the table.

So What Happened to Auxilium 2?

Auxilium 2 has been pre-released (available here) but it should be considered unstable as it was not fully completed. It's close enough to completion, and it is usable however.

The issues with Auxilium 2 became apparent after we started working on data export from Auxilium 1 to Auxilium 2, that's a heck of a lot of data, and Auxilium 1 struggles with it. But Auxilium 2, to be more specific, Deegraph, struggled with the massive dataset even more. Producing load times exceeding 60 seconds.

Because of this, it became clear that Auxilium 2 in its current state was unusable for Auxilium Software's primary client, Veterans Legal Link.

So the development team was met with a tough decision between three options:

Optimise Deegraph as much as humanely possible.
Scrap Auxilium 2 and focus on improving Auxilium 1, and releasing Auxilium 1.1.
Scrap Auxilium 2, and focus on building a new version of Auxilium from scratch.

We stuck with option 1 for a little while, experimenting with different ideas, but ultimately, realised that option 3 was the better move long-term.

What Makes Auxilium 3 Different?

So, there's a few major changes coming in Auxilium 3. The first of which is that Auxilium 3 is actually a collection of databases and a REST API, with the front-end portal only being one possible way of interfacing with Auxilium 3.

Because Auxilium is an open source project, we believe that data access should also be open source. This means that anybody can create an application that uses the Auxilium 3 API - whether that's a mobile app, reporting dashboard, or integration with other case management systems.

So What Actually is Auxilium 3?

So Auxilium 3 will use the following component stack:

CouchDB: Document storage, and revision control, case and user data is stored here.
MariaDB: Data relating to logins, refresh tokens, reset tokens... essentially anything to do with security.
Redis: This'll be responsible for storing indexes of data, along with session data.
RabbitMQ: This'll be responsible for asynchronous operations such as sending emails so that it doesn't block up either the API server or the front end, they'll be a separate microservice that'll handle all that sort of stuff.
REST API: Central service that'll coordinate all the separate services, run CRUD operations, and handle permissions.
Microservice: Separate services will handle specialized tasks like email processing via Microsoft Graph, preventing these operations from blocking the main API or frontend.

That's all quite a lot, and we do realise that Auxilium 3 will be following the kind of comical internet microservice meme stereotype, but in prototyping, we've seen some real speed benefits from this kind of approach.

Architectural Benefits

Auxilium 2's monolithic database approach unfortunately created a bottleneck where operations blocked other operations, meaning that somebody loading the "All Cases" page blocked page loading for anybody else trying to use the portal.

Auxilium 3 distributes load across specialized services, each optimized for specific operations.

The portal being one possible client of the API rather than being tightly coupled with the database allows for parallel development of multiple interfaces, meaning that Auxilium Mobile is a real possibility. It comes the added benefit of enabling horizontal scaling further down the line if required.

Technical Considerations