- Clojure with JDK 1.8
- Leiningen for building
- HTTP Kit server
- RING middleware
- Compojure API for defining API routes, JSON schemas (with validation) and generating swagger documentation
- Flyway for automated database data initialization and migrations
- Postgresql 9.4 database, with support for jsonb type field
- React JSX components for rendering HTML in clientside
- Bacon.js For handling client side state changes and initiating rerendering of React components
- Babel For ES6 javascript support
- Node.js For building JavaScript source and npm packages with webpack
- DBeaver for generating ERD images
- yEd for editing graphs
- IntelliJ IDEA for creating database diagrams
Valtionavustus application is deployed into CSC VMware environment. Environment provisioning is done with Ansible scripts.
Software is deployed as jar. Jar is built and deployed by Jenkins CI server, which also runs in VMware environment.
Environment specific application configurations are in va-hakija/config
General architecture including integrations and data flows (from originator towards receiver) is described in picture below.
Data flow of application (in Finnish, because all terms are in Finnish):
Valtionavustus application is divided to following major parts:
- soresu-form, which is the generic form library (including both React client UI and Clojure server code) and the React client UI and Clojure server code shared between the applications,
- va-virkailija, which contains React client UI and Clojure server for handling the scoring and processing the applications, and
- va-hakija, which has React client UI and Clojure server for submitting the applications and showing the forms
Internal structure of application architecture:
For va-hakija, the API documentation can be viewed via Swagger.
va-virkailija Swagger requires signing in with correct account.
Database is structured as a hybrid of relational database (tabular data and relations) and document database (containing JSON data). The document store uses jsonb fields storing structured JSON documents within normal relational tables.
All data is modified transactionally.
Most of the tables have either a sequential id, or composite key formed using sequential id and version and possibly foreign key references to other tables using the id-version pairs. The currently valid version has version_closed timestamp with value NULL.
Versioning is supported for for several tables, most notably form_submissions and attachments. Versioning uses sequential id with running version index to create unique primary key.
There's also more limited form of versioning in use, called archiving. This is used for forms and avustushaut. In this case the table in question doesn't have versioning machinery, but old data is copied to separate archive-table.
There are two kinds of Flyway migrations in use:
- SQL migration, which are typically located under resources/db/migrations/, and
- Code migrations which are located inside the codebase, typically under src/../migrations.clj
Migrations are automatically performed on server startup for both virkailija and hakija apps, and are forward-only.
