Design decisions
This page contains the current design decisions on different aspects of the application. As an example look at the UserManagement REST Resource class as an example that touches all of the below areas.
Pages are mostly served asynchronous, both for qute, hibernate and RestEasy unless they are very short running operations or responses. Therefore most of the responses should be returned as a Uni<...>.
Language support is using the java-code method @MessageBundle, instead of language properties files. They are located in eu.stenlund.janus.msg. The locale is stored in the JanusSession object, see Session storage. Current support is focusing on english and swedish.
The pattern used here is to create one @MessageBundle for each REST resource class in the application.
The SecurityIdentifier is created during the first login and stored client side as a SameSite cookie janus_credential and is encrypted and rotates. It contains the username, roles, email, user UUID and name. It is available through an injected CurrentIdentityAssociation.
The solution will only have a minimal need for storing session information between requests. The JanusSession object holds all of that information. It is stored as a client side SameSite cookie janus_session and is encrypted using a SHA-256 digest of the keyphrase and AES-256/CBC with random IV for each cookie update. No rotation is implemented for this cookie.
Currently stored data is the users chosen locale.
Reactive Hibernate is used as ORM and every @Entity must inherit from eu.stenlund.janus.model.base.JanusEntity. JanusEntity sets up a UUID as the objects id. Flyway is used for upgrading the database. Hibernate only verifies the database before the application is up and running.
The SessionFactory in the package SmallRye Mutiny is used for reactive programming of the database access and fits nicely into the reactive programming of the REST interface.
The application is divided into a set of REST Resources, each resource class contains a set of endpoints that have a high cohesion. Each resource also defined a @MessageBundle that contains the language support. For example see UserManagement.
All pages are based on base.html or base-simple.html. The general areas on a page is the #navbar-top and the #workarea. Each Template requires at least a eu.stenlund.janus.model.ssr.workarea.Base object as a parameter called base. Usually they also require one more objects based on what your #workarea is going to do, but typically they are sent in as the second parameter called workarea. Each #workarea object is located in the same package as Base and contains one or more factory functions createModel used by the resource for the endpoint.
Each #workarea is written as a fragment_.html in the resource class and included by the .html template.
As an example, the route /user/list is added to the eu.stenlund.janus.UserManagement inner class Template:
@CheckedTemplate
public static class Templates {
public static native TemplateInstance list(Base base, UserManagementList workarea);
}
The Templates name is list.html, that uses the base.html and uses the fragment_list.html to describe the workarea. Both the parameters base and workarea is available in the template. Also the template extension janus is available, see eu.stenlund.janus.base.JanusTemplateExtension
Each route must render a complete page, you can then use unpoly to just use certain specific parts of that page to get a smooth rendering in the browser. Typically just to update the #workarea. In some cases you also want to update the browser URL and can then use up-history="true". Unpoly sends in what area it is requesting as a HTML header and can in that case be used by the server to render only specific parts instead of the whole page.
The templates also have a set of tags defined for common used HTML-constructs, see the tag folder. For example the forms, input items and buttons are located as data models in the eu.stenlund.janus.ssr.ui package and have a set of tags to render them as well.
