Introduction

The MOVENS platform is chiefly inspired by the Twelve-Factor App 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, 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, 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. They use a variety of libraries, also striving for the leanest modules and dependencies.

Web clients are written using the Angular framework, 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