Introduction
============

The MOVENS platform is chiefly inspired by the `Twelve-Factor App <https://12factor.net/>`_
methodology, for modern, cloud-centric SaaS apps.

We also decided to include concepts from the Agile methodology, mainly related to
Test-Driven Development, and shaped our CI workflow.

We believe in the principle of the `REUSE Initiative <https://reuse.software/>`_, and
this is at the basis of our decision of open-sourcing the core components of MOVENS,
and in ensuring that licensing tries to keep as open and consistent as possible.

Last but not least, the MOVENS platform is coded with carefully designed-in security
features, and not with security-as-addon. We support the proposal of 
`Security.txt <https://securitytxt.org/>`_, and we have included references to our
security-related contact point in relevant code repositories.


Components
----------
Server-side applications are written in C#, for the 
`.NET Core Framework <https://dotnet.github.io/>`_. They use a variety of libraries,
also striving for the leanest modules and dependencies.

Web clients are written using `the Angular framework <https://angular.io/>`_, at
version 7 (as of this writing), in the typescript language. They are checked
and compiled to javascript by Gitlab's CI system. They try to make use of the leanest
modules and templates.

Both types of components are handled by Gitlab's CI tools, that check them, perform
some testing, and then produce container images for each one.

Server Modules
--------------
Server-side code is divided in modules; an example of a module would be the minimum
required one (Core) or any service-providing one (Vehicle Sharing).

Each module is made up of a dotnet core solution with several application projects
and libraries, as needed, as well as any required Dockerfile and/or start script.

Each application project is expected to be run as one of many Kubernetes pod replicas,
and to be load-balanced and kept running by the infrastructure. Logging is on the
standard output via log4net, while many settings are derived from environment variables.

Inside each module there are some scripts that set up the environment for each app,
designed to be started as container entrypoints.

A typical module will usually have:

 * An Admin web interface, hosted and implemented in a project called `WebAdmin`
 * Ad Agent, hosted in a project called `Agent` and implemented in a library called `LibAgent`
 * A Smartphone web interface, hosted and implemented in a project called `WebMobile`
 * A Statistics web interface, hosted and implemented in a project called `WebStatistics`
 * A library for testing, based off NUnit framework. Despite the name, it is usually kept
   to a minimum of end-to-end tests, even with simulated web interaction.
 * Some business-logic libraries, on which the previous elements depend
 * A Tasks application for one-off or recurring tasks