Architecture - HSLdevcom/jore4 GitHub Wiki
Architecture
The architecture is in flux as we learn more about the design and requirements.
Microservices
High level microservice and interaction 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.
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.