PostgreSQL, commonly known as Postgres, is the chosen database management system for the Registry Building Block within the GovStack framework. It is favored for its robustness, flexibility, and advanced features that support the complex data requirements of digital government services.

#5 Frontend technology of choice: React with Material UI

React, a popular JavaScript library for building user interfaces, is the chosen frontend technology for the demo. When paired with Material UI, a robust component library that implements Google’s Material Design, it provides a powerful framework for creating responsive and visually appealing applications.

Key Features

Component-Based Architecture: React’s component-based structure allows developers to build encapsulated components that manage their own state, promoting reusability and maintainability.
Declarative UI: React enables developers to describe how the UI should look based on the current application state, making it easier to understand and debug.
Virtual DOM: This feature optimizes rendering by updating only the parts of the UI that have changed, enhancing performance and user experience.

Material UI Integration

Pre-Built Components: Material UI offers a wide range of pre-designed components, such as buttons, forms, and navigation elements, which adhere to Material Design principles. This accelerates development and ensures consistency across the application.
Customizability: While providing a solid design foundation, Material UI allows for extensive customization, enabling developers to tailor components to meet specific branding and functional requirements.
Responsive Design: The library supports responsive layouts, ensuring that applications look great on various devices, from desktops to mobile phones.

#6 Backend technology of choice: Java Spring Boot

Java Spring Boot is the selected backend technology for the demo, chosen for its robustness, flexibility, and ability to streamline the development of microservices. It simplifies the process of building production-ready applications by providing a comprehensive framework that integrates various components seamlessly.

Java Spring Boot is an ideal choice for the backend of the GovStack architecture due to its ease of use, scalability, and strong community support. Its capabilities align well with the goals of the initiative, enabling the development of efficient, secure, and maintainable digital government services that can adapt to evolving needs.

Database Schema

Threat Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
threatUUID	UUID	Unique identifier for the threat.
type	VARCHAR(255)	Type of the threat.
severity	VARCHAR(255)	Severity level of the threat.
range	VARCHAR(255)	Range of the threat.
notes	VARCHAR(255)	Additional notes about the threat.
periodStart	TIMESTAMP	Start time of the threat period.
periodEnd	TIMESTAMP	End time of the threat period.
createdAt	TIMESTAMP	Timestamp when the threat was created.

Broadcast Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
broadcastUUID	UUID	Unique identifier for the broadcast.
threat_id	BIGINT	Foreign key referencing the threat table.
title	VARCHAR(255)	Title of the broadcast.
status	VARCHAR(255)	Status of the broadcast. DRAFT, PUBLISHED
notes	VARCHAR(255)	Additional notes about the broadcast.
englishMsg	TEXT	Message in English.
swahiliMsg	TEXT	Message in Swahili.
createdAt	TIMESTAMP	Timestamp when the broadcast was created.
initiated	TIMESTAMP	Timestamp when the broadcast was initiated.

Country Threat Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
threat_id	BIGINT	Foreign key referencing the threat table.
countryId	BIGINT	Identifier for the country.
countryName	VARCHAR(255)	Name of the country.

County Country Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
country_threat_id	BIGINT	Foreign key referencing the country_threat table.
countyId	BIGINT	Identifier for the county.
countyName	VARCHAR(255)	Name of the county.

Flow & Key Functionalities

This section outlines the core user flows and key functional capabilities of the Husika early warning system, as envisioned in the Figma design mockups.

The system is designed to support three primary user flows:

Threat Monitoring
Broadcasting
Feedback Collection

These flows are supported by a set of integrated features and an information architecture that enables users to effectively manage threats, communicate with stakeholders, and collect valuable feedback.

Figma Documentation:

...

Core User Flows

The three core user flows are described in detail below, based on the Figma designs:

Threat Monitoring

Design:

The Threat Monitoring functionality is accessible from multiple entry points in the system:
- The Dashboard provides an overview of active and high-priority threats, which users can click through to access the full Threats view.
- The Threats page serves as the central hub for monitoring and managing threats, offering a comprehensive tabular listing.
On the Threats page, users can view all threats across their jurisdiction but also other areas too, Users can see:
- The threats list based on criteria such as threat status, location, severity, and more.
- Quickly identify high-priority threats through visual cues like color-coded severity indicators.
The threats table includes the location information for each threat, displayed with an icon to indicate whether the threat is within the user's jurisdiction or outside of it.
Clicking on a specific threat in the Threats list opens the Threat Details view, which includes:
- A map-based visualization showing the geographic location of the threat.
- A timeline of events and associated metadata for the threat.
- The ability for users to submit structured feedback to the ICPAC (IGAD Climate Prediction and Applications Centre) through a dedicated feedback form.

Example Flow/Visualization:

...

Implementation Notes:

Info
Will be added

Broadcasting

Design:

The Broadcasting flow enables users to create and send alerts to their stakeholders such as citizens or organizations.
The broadcast creation process is divided into three steps:
1. Configuration: Users select the communication channels (email, SMS, WhatsApp, Telegram), target languages, and recipients.
  1. Recipients can be Whole population within Jurisdiction
  2. Organizations within Jurisdiction
  3. Or custom recipients, such as certain user group that is created beforehand. (pastoralist within certain area)
2. Content Creation: Users craft the broadcast message, optionally select a pre-made template, and configure response options (validation, general feedback or none).
3. Preview & Review: Users review the broadcast details, estimated reach, and content preview before finalizing and sending the broadcast.
The broadcast creation interface supports multi-language editing and file attachments.
Users can track the status of their broadcasts (draft, processing, sent, failed) in the Broadcasts page.

Example Flow/Visualization:

...

Implementation Notes:

Info
Will be added

Feedback Collection

Design:

The Feedback Collection flow supports two main feedback channels:
1. Threat Feedback to ICPAC:
  - From the Threat Details page, users can submit structured feedback to the IGAD Climate Prediction and Applications Centre (ICPAC) regarding a specific threat.
  - This feedback is focused on the threat details, accuracy, and other relevant information.
2. Broadcast Feedback:
  - The Feedback page provides a comprehensive list of all responses and feedback received for the user's broadcasts.
  - There are two types of broadcast feedback: a. Validation Responses: Structured feedback from recipients about the accuracy and relevance of the broadcast content. b. General Responses: Free-form feedback and comments from recipients.
Administrators can view analytics on the validation responses, including visual representations of the feedback data.
Users can also submit their own administrative feedback about a broadcast, which is tracked separately from the recipient responses.

Example Flow/Visualization:

Feedback to Icpac Flow:

Image Removed

Broadcast Feedbacks:

...

Implementation Notes:

Info
Will be added

Key Features

Dashboard

Design:

The Dashboard provides users with a high-level overview of the key metrics and activities within the early warning system.
The dashboard includes the following sections:
- Threats: Displays the number of active threats and high-priority threats across the user's jurisdiction.
- Broadcasts: Shows the number of broadcasts that have been sent and are currently pending.
- Feedbacks: Indicates the total number of received feedbacks and the number of feedbacks received today.
Each of these overview sections can be clicked to navigate to the corresponding detailed view (Threats, Broadcasts, Feedbacks).
The Dashboard also includes a "Recent Threats" section, which lists the most recent threats within the user's jurisdiction. This section provides a quick snapshot of the current threat landscape.
Users can easily access key actions from the Dashboard, such as creating a new broadcast.

Visualization:

...

Implementation Notes:

Info
Will be added

Threat Details

Design:

The Threat Details page provides a comprehensive view of a specific threat, accessible by clicking on a threat from the Threats list.
The page includes the following key elements:
- Location: A map visualization showing the geographic area affected by the threat, with clear indication of the user's jurisdiction.
- Threat Details: Detailed information about the threat, including type, severity, period, and associated metadata.
- History Timeline: A chronological timeline of events related to the threat, from when it was first created to its current status.
- ICPAC Feedback: A dedicated section where users can submit structured feedback to the IGAD Climate Prediction and Applications Centre (ICPAC) regarding the threat.
Broadcast List: A table displaying all broadcasts that have been created in relation to the selected threat. This includes:
- Title of the broadcast
- Language of the broadcast content
- Communication channel used (e.g., Telegram)
- Date the broadcast was sent
- Status indicators (e.g., Sent, Processing)
Users can easily navigate back to the Threats list or access other core functionalities like creating a new broadcast from the Threat Details page.
The page layout and design provide a clear, comprehensive view of the threat and associated broadcasts to support effective monitoring and response.

Visualization:

...

Implementation Notes:

Info
Will be added

Broadcast Creation

Design:

...

The broadcast creation functionality allows users to create, send, and track the feedbacks for their broadcasts.

...

The broadcast creation process is divided into three main steps:

Configuration:
- Users select the communication channels they want to use, such as email, SMS, WhatsApp, and Telegram.
- They can select and edit the target languages.
Content Creation:
- Users craft the broadcast message, with the option to select a pre-made template.
- They can configure the type of response they want to receive, such as validation responses or general feedback.
Preview & Review:
- Users can review the details of the broadcast, including the estimated reach.
- They have the opportunity to preview the content in the selected languages before finalizing and sending the broadcast.

...

Once a broadcast is sent, users can track its status (e.g., draft, processing, sent, failed) on the Broadcasts page.

...

The broadcast creation interface supports features like multi-language editing and file attachments to enhance the communication capabilities.

...

Further information on initial Baserow investigation, conducted by Vuk Damjanovic

Overall findings
Baserow as a standalone database/storage/registry solution is excellent. It provides a package of technologies combined in a way that allows non technical person to manage databases on their own in a, somewhat, intuitive way. The advantage of the Baserow over a traditional database is the UI, and package of technologies ready to cover various data storage scenarios out of the box using Docker or Helm charts.

Mentioning Docker and Helm charts, Docker is a preferred way for deployment. Both official instructions and hands on experience are heavily leaning toward Docker as a preferred deployment approach. Helm charts are an alternative, however, not an easy one. In order to up and run Baserow with Helm charts, official chart and instructions were not sufficient to achieve this. In order to make it up and running we had to resort to a chart made by a different user, on top of that the amount of time and people involved in this process was substantially higher compared to the Docker approach.

Going outside of the scope of the standalone approach makes Baserow quite complicated to work. If the goal of the Baserow is to be used as an alternative to the traditional open-source databases (like PostgreSQL/MySQL), it seems like an over-engineered approach and there's no clear benefit that would cover for the amount of work needed to make Baserow to do what a simple instance of a traditional DB would do. Moreover, mentioned traditional technologies combined with open-source DB UI client (DBeaver Community for example) covers 80% of the Baserow benefits. The only loss is that user isn’t really able to use it as easy as Baserow without having SQL knowledge.

One of technologies within the Baserow is a PostgreSQL instance.
Baserow is adding a lot of abstractions on top of it, and working with it it’s like working with a black box. These are additional hoops needed to be jumped trough in order to make Baserow do what a traditional DB is doing from a development point of view.
For instance, connecting Baserow with a SpringBoot app (or something even more complicated like X-Road) takes massive amount of time, it’s more verbose and it’s quite prone to errors and potential issues which are not the case with conventional DBs. When using Baserow trough UI there's many automated actions that are happening in the background, which are needed to be executed manually in sequence when working with Baserow via APIs.
To wrap up the overall view on the Baserow, it’s excellent as a standalone product, but not that good (over-engineered)as a traditional DB for the same purpose.

Suitable for production Husika?
Suitable for POC demo from GoFore?

I would say no. What Husika is currently using (MySQL) and what is expected from the production DB, traditional DBs are more suitable in this case. We could make Baserow to do what a conventional DB does and make Baserow to be a go-to solution for Husika, but with a massive investment of time and effort which seems unnecessary and could be a potential waste of time which we need in other areas. In terms of POC, still the traditional DB solves all our problems. Of course, if it’s absolutely a must to use Baserow to follow the philosophy of using the mentioned GovStack BBs then we can do it, but with the mentioned costs from above.

Additional note

There’s a possibility to run Baserow in a way that each technology inside of it can be run as a separate container. This opens potential capability of reusing them in a way it would suit us. For example, use the PostgreSQL and Redis directly as a standalone app within the Baserow. However, this is something that has to be tested and confirmed if it works this way.

investigate if running migration scripts is possible → No feasible due to too complex structure of the tables. In order to create one table with three columns and three values using conventional SQL language (which is used in migration files run with liquibase) it’s needed to cover over 15+ tables. Inserting one field in the table requires inserting data into more than 10 tables.

#5 Frontend technology of choice: React with Material UI

React, a popular JavaScript library for building user interfaces, is the chosen frontend technology for the demo. When paired with Material UI, a robust component library that implements Google’s Material Design, it provides a powerful framework for creating responsive and visually appealing applications.

Key Features

Component-Based Architecture: React’s component-based structure allows developers to build encapsulated components that manage their own state, promoting reusability and maintainability.
Declarative UI: React enables developers to describe how the UI should look based on the current application state, making it easier to understand and debug.
Virtual DOM: This feature optimizes rendering by updating only the parts of the UI that have changed, enhancing performance and user experience.

Material UI Integration

Pre-Built Components: Material UI offers a wide range of pre-designed components, such as buttons, forms, and navigation elements, which adhere to Material Design principles. This accelerates development and ensures consistency across the application.
Customizability: While providing a solid design foundation, Material UI allows for extensive customization, enabling developers to tailor components to meet specific branding and functional requirements.
Responsive Design: The library supports responsive layouts, ensuring that applications look great on various devices, from desktops to mobile phones.

#6 Backend technology of choice: Java Spring Boot

Java Spring Boot is the selected backend technology for the demo, chosen for its robustness, flexibility, and ability to streamline the development of microservices. It simplifies the process of building production-ready applications by providing a comprehensive framework that integrates various components seamlessly.

Java Spring Boot is an ideal choice for the backend of the GovStack architecture due to its ease of use, scalability, and strong community support. Its capabilities align well with the goals of the initiative, enabling the development of efficient, secure, and maintainable digital government services that can adapt to evolving needs.

Database Schema

Threat Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
threatUUID	UUID	Unique identifier for the threat.
type	VARCHAR(255)	Type of the threat.
severity	VARCHAR(255)	Severity level of the threat.
range	VARCHAR(255)	Range of the threat.
notes	VARCHAR(255)	Additional notes about the threat.
periodStart	TIMESTAMP	Start time of the threat period.
periodEnd	TIMESTAMP	End time of the threat period.
createdAt	TIMESTAMP	Timestamp when the threat was created.

Broadcast Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
broadcastUUID	UUID	Unique identifier for the broadcast.
threat_id	BIGINT	Foreign key referencing the threat table.
title	VARCHAR(255)	Title of the broadcast.
status	VARCHAR(255)	Status of the broadcast. DRAFT, PUBLISHED
notes	VARCHAR(255)	Additional notes about the broadcast.
englishMsg	TEXT	Message in English.
swahiliMsg	TEXT	Message in Swahili.
createdAt	TIMESTAMP	Timestamp when the broadcast was created.
initiated	TIMESTAMP	Timestamp when the broadcast was initiated.

Country Threat Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
threat_id	BIGINT	Foreign key referencing the threat table.
countryId	BIGINT	Identifier for the country.
countryName	VARCHAR(255)	Name of the country.

County Country Table

Name	Type	Description
id	BIGINT	Primary key, auto-incremented.
country_threat_id	BIGINT	Foreign key referencing the country_threat table.
countyId	BIGINT	Identifier for the county.
countyName	VARCHAR(255)	Name of the county.

Flow & Key Functionalities

This section outlines the core user flows and key functional capabilities of the Husika early warning system, as envisioned in the Figma design mockups.

The system is designed to support three primary user flows:

Threat Monitoring
Broadcasting
Feedback Collection

These flows are supported by a set of integrated features and an information architecture that enables users to effectively manage threats, communicate with stakeholders, and collect valuable feedback.

Figma Documentation:

...

Core User Flows

The three core user flows are described in detail below, based on the Figma designs:

Threat Monitoring

Design:

The Threat Monitoring functionality is accessible from multiple entry points in the system:
- The Dashboard provides an overview of active and high-priority threats, which users can click through to access the full Threats view.
- The Threats page serves as the central hub for monitoring and managing threats, offering a comprehensive tabular listing.
On the Threats page, users can view all threats across their jurisdiction but also other areas too, Users can see:
- The threats list based on criteria such as threat status, location, severity, and more.
- Quickly identify high-priority threats through visual cues like color-coded severity indicators.
The threats table includes the location information for each threat, displayed with an icon to indicate whether the threat is within the user's jurisdiction or outside of it.
Clicking on a specific threat in the Threats list opens the Threat Details view, which includes:
- A map-based visualization showing the geographic location of the threat.
- A timeline of events and associated metadata for the threat.
- The ability for users to submit structured feedback to the ICPAC (IGAD Climate Prediction and Applications Centre) through a dedicated feedback form.

Example Flow/Visualization:

...

Implementation Notes:

Info
Will be added

Broadcasting

Design:

The Broadcasting flow enables users to create and send alerts to their stakeholders such as citizens or organizations.
The broadcast creation process is divided into three steps:
1. Configuration: Users select the communication channels (email, SMS, WhatsApp, Telegram), target languages, and recipients.
  1. Recipients can be Whole population within Jurisdiction
  2. Organizations within Jurisdiction
  3. Or custom recipients, such as certain user group that is created beforehand. (pastoralist within certain area)
2. Content Creation: Users craft the broadcast message, optionally select a pre-made template, and configure response options (validation, general feedback or none).
3. Preview & Review: Users review the broadcast details, estimated reach, and content preview before finalizing and sending the broadcast.
The broadcast creation interface supports multi-language editing and file attachments.
Users can track the status of their broadcasts (draft, processing, sent, failed) in the Broadcasts page.

Example Flow/Visualization:

...

Implementation Notes:

Info
Will be added

Feedback Collection

Design:

The Feedback Collection flow supports two main feedback channels:
1. Threat Feedback to ICPAC:
  - From the Threat Details page, users can submit structured feedback to the IGAD Climate Prediction and Applications Centre (ICPAC) regarding a specific threat.
  - This feedback is focused on the threat details, accuracy, and other relevant information.
2. Broadcast Feedback:
  - The Feedback page provides a comprehensive list of all responses and feedback received for the user's broadcasts.
  - There are two types of broadcast feedback: a. Validation Responses: Structured feedback from recipients about the accuracy and relevance of the broadcast content. b. General Responses: Free-form feedback and comments from recipients.
Administrators can view analytics on the validation responses, including visual representations of the feedback data.
Users can also submit their own administrative feedback about a broadcast, which is tracked separately from the recipient responses.

Example Flow/Visualization:

Feedback to Icpac Flow:

Image Added

Broadcast Feedbacks:

...

Implementation Notes:

Info
Will be added

Key Features

Dashboard

Design:

The Dashboard provides users with a high-level overview of the key metrics and activities within the early warning system.
The dashboard includes the following sections:
- Threats: Displays the number of active threats and high-priority threats across the user's jurisdiction.
- Broadcasts: Shows the number of broadcasts that have been sent and are currently pending.
- Feedbacks: Indicates the total number of received feedbacks and the number of feedbacks received today.
Each of these overview sections can be clicked to navigate to the corresponding detailed view (Threats, Broadcasts, Feedbacks).
The Dashboard also includes a "Recent Threats" section, which lists the most recent threats within the user's jurisdiction. This section provides a quick snapshot of the current threat landscape.
Users can easily access key actions from the Dashboard, such as creating a new broadcast.

Visualization:

...

Implementation Notes:

Info
Will be added

Threat Details

Design:

The Threat Details page provides a comprehensive view of a specific threat, accessible by clicking on a threat from the Threats list.
The page includes the following key elements:
- Location: A map visualization showing the geographic area affected by the threat, with clear indication of the user's jurisdiction.
- Threat Details: Detailed information about the threat, including type, severity, period, and associated metadata.
- History Timeline: A chronological timeline of events related to the threat, from when it was first created to its current status.
- ICPAC Feedback: A dedicated section where users can submit structured feedback to the IGAD Climate Prediction and Applications Centre (ICPAC) regarding the threat.
Broadcast List: A table displaying all broadcasts that have been created in relation to the selected threat. This includes:
- Title of the broadcast
- Language of the broadcast content
- Communication channel used (e.g., Telegram)
- Date the broadcast was sent
- Status indicators (e.g., Sent, Processing)
Users can easily navigate back to the Threats list or access other core functionalities like creating a new broadcast from the Threat Details page.
The page layout and design provide a clear, comprehensive view of the threat and associated broadcasts to support effective monitoring and response.

Visualization:

...

Implementation Notes:

Info
Will be added

Broadcast Creation

Design:

The broadcast creation functionality allows users to create, send, and track the feedbacks for their broadcasts.
The broadcast creation process is divided into three main steps:
1. Configuration:
  - Users select the communication channels they want to use, such as email, SMS, WhatsApp, and Telegram.
  - They can select and edit the target languages.
2. Content Creation:
  - Users craft the broadcast message, with the option to select a pre-made template.
  - They can configure the type of response they want to receive, such as validation responses or general feedback.
3. Preview & Review:
  - Users can review the details of the broadcast, including the estimated reach.
  - They have the opportunity to preview the content in the selected languages before finalizing and sending the broadcast.
Once a broadcast is sent, users can track its status (e.g., draft, processing, sent, failed) on the Broadcasts page.
The broadcast creation interface supports features like multi-language editing and file attachments to enhance the communication capabilities.
User can also track Feedbacks related to the broadcast through here.

Expand

title	Example Templates

Template name: [Validation] Urgent Flood Alert - Short (WhatsApp or Telegram)

Content:

English:

🚨 FLOOD ALERT STATUS CHECK Is your area experiencing flooding?

Rising water level
Flooded roads or buildings
Overflow from rivers

Please respond: YES - if you observe any of these conditions NO - if your area is currently unaffected

(Google Translate)Swahili:

🚨 TAARIFA YA HALI YA MAFURIKO

Je, eneo lako linaathiriwa na mafuriko?

Kiwango cha maji kinapanda
Barabara au majengo yamefurika
Mafuriko kutoka kwenye mito

Tafadhali jibu: YES - ikiwa unaona mojawapo ya hali hizi NO - ikiwa eneo lako halijaathirika kwa sasa

Template name: [Validation] Urgent Drought Alert - Short (WhatsApp or Telegram)

Content:

English:

🚨 DROUGHT STATUS CHECK

Is your area experiencing water shortage?

Dry water sources
Limited drinking water
Non-functioning water points

Please respond: YES - if your area is affected NO - if your area has water supply

Swahili version:

🚨 TAARIFA YA HALI YA UKAME

Je, eneo lako lina uhaba wa maji?

Vyanzo vya maji vimekauka
Maji ya kunywa ni haba
Vituo vya maji havifanyi kazi

Tafadhali jibu: YES - ikiwa eneo lako limeathirika NO - ikiwa eneo lako lina maji

Template name: [General Response] Urgent Flood Alert - Short (WhatsApp or Telegram)

Content:

English:

Due to rising water levels, immediate action required:

SAFETY INSTRUCTIONS:

Move to higher ground
Avoid crossing flooded areas
Stay away from rivers and streams
Use designated evacuation routes

EVACUATION CENTERS: [Location 1] [Location 2] [Location 3]

📞 Emergency Contact: [NUMBER]

Please reply with your current situation or any urgent needs.

Swahili version:

🚨 TAADHARI YA MAFURIKO - [ENEO]

Kutokana na kupanda kwa kiwango cha maji, hatua za haraka zinahitajika:

MAAGIZO YA USALAMA:

Nenda maeneo ya juu
Epuka kuvuka maeneo yaliyofurika
Kaa mbali na mito na vijito
Tumia njia zilizotengwa za kuondoka

VITUO VYA KIMBILIO: [Eneo la 1] [Eneo la 2] [Eneo la 3]

📞 Nambari ya Dharura: [NAMBARI]

Tafadhali tuma ujumbe kuhusu hali yako ya sasa au mahitaji yoyote ya dharura.

...

Feedbacks

Design:

The system provides comprehensive feedback management capabilities, supporting two distinct feedback channels:

...

Versions Compared

Old Version 3

New Version 4

Key

#5 Frontend technology of choice: React with Material UI

#6 Backend technology of choice: Java Spring Boot

Database Schema

Threat Table

Broadcast Table

Country Threat Table

County Country Table

Flow & Key Functionalities

Core User Flows

Threat Monitoring

Broadcasting

Feedback Collection

Key Features

Dashboard

Threat Details

Broadcast Creation

Further information on initial Baserow investigation, conducted by Vuk Damjanovic

#5 Frontend technology of choice: React with Material UI

#6 Backend technology of choice: Java Spring Boot

Database Schema

Threat Table

Broadcast Table

Country Threat Table

County Country Table

Flow & Key Functionalities

Core User Flows

Threat Monitoring

Broadcasting

Feedback Collection

Key Features

Dashboard

Threat Details

Broadcast Creation

Feedbacks

Page Comparison

Versions Compared

Old Version 3

New Version 4

Key

#5 Frontend technology of choice: React with Material UI

#6 Backend technology of choice: Java Spring Boot

Database Schema

Threat Table

Broadcast Table

Country Threat Table

County Country Table

Flow & Key Functionalities

Core User Flows

Threat Monitoring

Broadcasting

Feedback Collection

Key Features

Dashboard

Threat Details

Broadcast Creation

Further information on initial Baserow investigation, conducted by Vuk Damjanovic

#5 Frontend technology of choice: React with Material UI

#6 Backend technology of choice: Java Spring Boot

Database Schema

Threat Table

Broadcast Table

Country Threat Table

County Country Table

Flow & Key Functionalities

Core User Flows

Threat Monitoring

Broadcasting

Feedback Collection

Key Features

Dashboard

Threat Details

Broadcast Creation

Feedbacks