Performance proposal

Current architecture deficiencies

Though WebSocket-based solution seems interesting, current usage mode does not allow use it fully:

• Frontend mode requires from us to create a full proxy solution to allow communication from UI to backend server to pass active connection through.
• Service level which operates with entities now is unaware of controller level, so it does not propagate changes to it.

Same considerations relate to long-polling solution too.

Controller cache

We can introduce a new cache on controller level to store often requested data. As long as there is no direct access from service level to controller level, I'd propose to do cache invalidation asynchronously with Akka-based message bus.

In this scheme every change on project, environment and environment history entities will broadcast a typed message. Newly introduced cache layer will invalidate and possibly store new version in cache. Controllers will request cache for entities, and cache level will be responsible to retrieve data from database or other backend.

Conditionals

I'd proposed also change communication between UI and REST in critical areas with conditional requests. It should be much cheaper to get modification date only rather than full entity. So, in some cases (environment history, at first) UI should get modification date first, and only it's changed perform a full data request. This approach can be combined with previous proposal, so controller cache may store typed object and it's modification date. In this case request for modification date will use the cache mostly, so it should be maximally fast.