Tech Stack & Architecture
The DiCRA architecture utilizes a modular stack designed for efficient geospatial processing and interactive data visualization. The frontend is built on ReactJS with Vite for optimized build times, utilizing MaplibreGL and PMTiles to handle massive vector and raster datasets efficiently in the browser. State management and fluid UI interactions are powered by Redux Toolkit, Framer Motion, and Tailwind CSS. On the backend, a Python-based ecosystem anchored by FastAPI and PostgreSQL/PostGIS manages data transactions and API requests. The detailed stack used for each portal is given below:
| Frontend | Backend & Utilities | GIS/Data Visualisation | AI/ML Modelling |
|---|---|---|---|
| ReactJS with Vite | Python | MaplibreGL | QGIS integration |
| Redux Toolkit | FastAPI | PMTiles, | Rasterio |
| Lucide | Pydantic | Recharts & Apexcharts | Xarray |
| ShadCN. | PostgreSQL | geomatico/maplibre-cog-protocol. | Cdsapi Rioxarray |
| Tailwind | Alembic | Matplotlib | Sklearn (Linear Models) |
| Tqdm/Dask | Seaborn | Scipy | |
| Pathlib | Folium | Geopandas | |
| Glob | Shapely |
Architecture
The architecture operates across three layers. The frontend layer handles user access via a browser with authentication, routing traffic through DNS and a load balancer to web services, with static assets served via a CDN. The backend layer sits behind a WAF, distributing API requests across multiple application servers (App Server 1 through n) for scalability and fault tolerance; these servers interact with a PostgreSQL database and a storage account for data persistence. The data-pipeline layer operates independently, comprising a Data Processing Engine, Scheduler, and ML Engine. This pipeline reads from and writes to a data repository, PostgreSQL, and the storage account, enabling automated data ingestion, processing, and model execution that feeds the platform's analytical outputs.
Cloud Architecture
The core application deployment follows a secure, tiered architecture designed to isolate public-facing entry points from critical data processing and storage layers. Traffic enters through a firewall enforced with WAF rules. The load balancer routes traffic to the app server via standard ports. Internal communication is strictly isolated within a private network; the app server interacts with workflow runners and workflow app services/automations via private IPs.
The persistence layer consists of a managed PostgreSQL database (port 5432) and object storage, both accessible to internal workflow services through secure role/secret-key protocols. Frontend UI files are served directly to the user via a CDN integrated with the object storage. Continuous integration and deployment are handled by a dedicated CI-CD worker with controlled inbound/outbound access to GitHub IP ranges, ensuring secure automated updates to the infrastructure.
Notebook Access
For Jupyter notebook access, see Notebook Access.