Architecture - HSLdevcom/jore4 GitHub Wiki

Architecture

The architecture is in flux as we learn more about the design and requirements.

Architecture diagram

Microservices

High level microservice and interaction diagram:

Microservices diagram

Digiroad importer

Downloads and processes Uusimaa's road infrastructure data from Digiroad. Generates the following data:

  • mapbox tiles for the Mapbox Tiles server
  • infrastructure data for map-matching
  • infrastructure data and stops for JORE4 database
  • stops for JORE3 importer

Map-matching database

Hosts a separate PostgreSQL instance with infrastructure data only used for map-matching. This data is generated by the Digiroad importer.

Map-matching server

Given a list of coordinates, provides an optimal path along the infrastructure links. Used by JORE3 importer to fit the JORE3 routes to the JORE4 infrastructure links. Used by the UI to draw new routes.

JORE3 importer

Ingests routes' and stops' data from JORE3. Uses Map-matching server to fit JORE3 routes to JORE4 infrastructure. Uses Digiroad stops' data to fit JORE3 stops to the actual GPS coordinates. Uses a staging database within JORE4 to first import the JORE3 data and then further process it to JORE4 format. This importing from JORE3 is meant to be a one-off, one-way operation, not a continuous synchronization between JORE3 and JORE4.

JORE4 database

The JORE4 database is Azure is implemented as a PostgreSQL flexible server instance. The local development version (with preset logical databases and SQL roles) is found from jore4-postgres repository. The database consists of the following logical databases:

  • auth: stores session data for JORE4 authentication
  • jore3importer: stores staging data for JORE3 importer
  • jore4: stores the infrastructure and route data for JORE4 (to be renamed to networkdb in the future)
  • timetablesdb: stores the timetables data for JORE4

The validation and some more complex mutations and queries are implemented as SQL constraints, functions and triggers.

Auth backend

Authenticates the user against HSL ID, using OpenID Connect. Provides endpoints for the UI to fetch the currently logged in user's information. Provides a hook endpoint for Hasura to check whether the user is authenticated and get its roles. Uses HTTP-only session cookie in the browser and the JORE4 database to store session data.

Hasura

Provides GraphQL endpoint for other microservices and the UI to read and write to the JORE4 database. Also meant to provide a GraphQL endpoint for 3rd party users, e.g. for analytics. Maintains the JORE4 database schema by running SQL migrations. Currently it's a single instance, but might be split to separate instances for networkdb and timetablesdb to further improve the overall system modularity.

Hastus importer-exporter

Provides integration between JORE4 and Hastus, communicates with JORE4 through Hasura. Exports JORE4 route data to a file format recognized by Hastus. Imports timetable data by ingesting the file exported from Hastus. Provides endpoints for the UI to trigger exporting routes and importing timetables

JORE4 UI

Provides user interface for HSL planners to see and modify routes', stops', timetables', etc. data. Gives a transparent view of all the modules which are otherwise logically separated (Routes and Lines, Timetables, Stop Registry, etc).

  • Uses Mapbox tile server to provide tiles for the map views.
  • Uses Map-matching server to draw route geometries on the map.
  • Uses Hastus importer-exporter to export routes and import timetables from Hastus.
  • Uses Auth backend for authenticating the user and retrieving its basic information.
  • Uses Hasura to see and modify see and modify routes', stops', timetables', etc. data.

Mapbox tile server

Hosts the mapbox tiles provided by the Digiroad import service

Cloud infra

This section contains initial documentation about the cloud infra, especially with regards to network layout.

Note that the image below might be re-done completely since plant-uml has not proven to work well for this sort of diagram.

Cloud infra diagram

Environments

The project setup can be run in the following types of environments:

  • Kubernetes (AKS)
  • Docker Compose

The configurations for all environment types are generated from the same input yaml files using gomplate.

Several Kubernetes staging environments have been deployed in the Azure cloud ("playg", "dev", "test") in addition to the production ("prod") environment. The docker compose environment can be used locally when developing individual components and running end-to-end tests.

For more information on the environment types and deployed environments, please see the Jore4 flux repository README.

Routing/Map-matching architecture

Map-matching architecture diagram