BOOST Docs

Appearance

BOOST.Core ​

BOOST.Core is still under production. Its foundations was developed by Assar Leideman during the summer of 2024.

The TODO-list: ​

Structure based on functionality ​

We have already started, but not finished, the migration to structuring packages after the end problem they are trying to solve and nothing else. This means that for example, all authorization related stuff should be put in one separate package/entity. It means that the users caches and permissions caches should move to the repository, and that they should not be a repetition of one another.

Code cleanup ​

A whole load of old code is included right now. Many Utils such as UUID exist at multiple locations etc. For the release version all unneccessary junk must be cleaned.

Separating the "framework" from the implementation ​

Right now, a lot of code that sort of belong to the essence of the middleware is still written in the middleware. The repository, BOOST.Core package amongst other things should be moved to the BOOST.Middleware project

Writing configuration to DB ​

See Design Choicesfor motivation. We want to create a functionality in the middleware to load all configured relations and BOOST.Records made using Java annotations, and write to a sort of master database. This is so that we define what the "correct" setup is at only one place, and we want that to be the java source.

Caching ​

This is difficult. Period. It is not even certain that caching is neccessary anymore. Since BOOST.Repository uses JOOQ's multisets for fetching records with related entities, there is never more than a single SQL call to DB on a get-method. MySQL also caches queries, so we sort of have caching already from MySQL. Saving/updating/deletion is all done with batch operations, making it as efficient as theoretically possible.

However, there are some simple cases when caching is simple and could improve performance. For records that don't have a parent, and only has records that belong to itself, caching is trivial. In the case when caching means that parents has to be invalidated etc it is slightly more complicated. Also the case when a record has many children that need to be fetched is more complicated. All of these operations must happen in less than a few ms to be worth it, otherwise main storage is faster. So caching of BOOST.Records shouldn't be a priority right now.

That said, the caching of user permissions and user UUIDs etc should be included in the normal cache and not have different implementations regarding connections etc.

Optimization ​

The new core foundation is already very fast due to great optimizations at macro level. However, we haven't done any micro level optimizations what so ever. This is fair, we aren't ready for that yet. But once we have many customers and many requests per second, a fair bit of performance can probably be squeezed out using profilers etc.

BOOST.Dispatcher - Sending checksums ​

First we need to add the functionality for the middleware to write to DB about all BOOST.Record configs and relations. Once that is done, checksum functionality is rather trivial to add. The BOOST.Dispatcher already listenes for changes on certain records and then sends out MQTT messages. Here we want to extend it so that it also sends out a checksum. Maybe that should happen on a separate thread? I.e first the CRUD information is sent, and then the checksum. This is because the calculation of checksums might take a while, and that is fine. Checksums maybe also should be sent out on regular intervals? That sort of depends on how expensive it is for the frontend to verify its checksums.

BOOST.Dispatcher - Integrating Apache Camel ​

Right now the BOOST.Dispatcher is able to perform jobs that implement the Quartz Job interface. This is a good start, and works well for scheduling things such as sending emails. But it is a bit limited, and we already know that we want to perform other scheduled tasks such as synchronizing with other services such as Fortnox. Thus, the BOOST.Dispatcher should probably switch to performing camel jobs. Then, we will make PDF-Building using BOOST.PDFBuilder a distinct camel job, sending an email another distinct camel job (its just to configure and endpoint), as well as sending MQTT. Quartz scheduling can easily be integrated into camel. Then the user can easily pussle together camel jobs, thus allowing for fetching of data from a source, making a PDF, sending it, scheduling the sending etc.

Design choices made so far: ​

  • We choose to not send null fields on messages to and from the API. This is for several reasons:
    • It makes formatting on the multisets etc much easier and faster.
    • It reduces caching space requirements.
    • This is how JavaScript works anyways so why not?
  • We have choosen to NOT write the relations between BOOST.Records in the database (and letting the middleware read from the database to set up relations on startup). Writing it in the source code allows the Java compiler to catch some errors, making refactoring safer. We have decided to instead make the middleware write to the DB, to ensure that any change only needs changing at one place.
  • We have choosen to ignore any extra props that are sent to the API. This makes life easier for front end devs if they add some prop by accident. On the other hand, if they misspell something, or even use incorrect casing, they won't be notified that what they sent in didn't do anything. For example, sending "itemidentification" instead of "itemIdentification" will still return a response with no itemidentification, which might make them annoyed. But the good thing now is that we have Bob the Builder which hopefully resolves this issue.