ITR Design

The ITR is designed from the ground up as a secure multi-tenant system for high system loads.

This has lead to the following choices :

• every customer has their own database. This will increase performance and most importantly security
• central information is placed and maintained in the master database which is a central database. Some information like tests, reports et cetera can be place in this central database so that all tenants/customers can potentially make use of it
• processing is taken away from the central server as much as possible. The central server is responsible for : serving the website, storing and retrieving data, providing central server functions which cannot be executed from the browser (like sending mails). The central server is also responsible for serving ONLY the proper data to the webbrowser. This means for example that a test taking user can NOT access all information in the system. And as another example an office user can read and use test definitions but ONLY a test author can update the test defitions
• The API is split into TWO APIs. The internal API which is for usage only by the ITR webbrowsers and the external API which can be used by basically any calling system. If you do not want external API functionality then simply do not install it.
• All API calls are made to do whatever they need to do, but they are designed for short run times and high concurrency. THis means that a webbrowser potentailly will have to make many calls to complete a function, but this does NOT block all the other web browsers

The website, internal API and external API can be placed on the same server or computer in its most simple form. They can also be installed and used in for example docker containers, in a docker swarm or kubernetes cluster, or in a load balanced server cluster. The conditions are the following.

• THe instance folder needs to be shared between all API containers (both internal and external)
• The database needs to be accessible for all API containers
• The internal API container needs to be on the same domain name for CORS checks by the browser.

The database back end is postgres. You can setup a read only postgres copy on each API server if required for scaling out. Please note that test run users mostly write to the database while taking tests. Office users tend to have a higher read behaviour.

Usage of postgres connections is limited to 1 or 2 connections per API instance, or at least as much as possible (in some cases more connections are needed), which means that a single database server can server many API instances.

All information exchanged between browser and server is compressed. The javascript in the ITR site is not minified to allow for easier debugging and understanding of what is going on, you can do this if you want or need that for faster site loading times.

To facilitate for slow connections the ITR site is a single page application where all code is fully loaded while the user is logging on. There is a multi stage load approach for the login screen with the option to load only the code required for test taking. All codes is placed on the central server as much as possible. Fonts from google are for example loaded from the google site itself.