Fiji Immigration Internal Management System
The system immigration officers run a country borders on.

- Role
- Frontend Angular Developer
- Year
- 2024
- Company
- ITGalax Solutions Pvt Ltd
- Platform
- Enterprise Web
- Status
- Delivered
Overview
Enterprise immigration management platform for government officers handling applications, documents, assessments and workflow-driven case processing.
The challenge
Immigration operations needed a centralized system where officers could assess applications, verify documents and move cases through complex workflows without losing context.
Every application carries legal and operational importance, while multiple departments may interact with the same record at different stages of the process.
The solution
A workflow-driven Angular platform with role-based access control, structured case management, document verification, automated routing and operational reporting.
Angular with standalone component architecture, RxJS for reactive data flows, Tailwind CSS for the interface layer and a .NET API, with role-based access integrated into routing and UI rendering.
My contribution
- Frontend architecture for the officer-facing application
- Data flow optimisation across the case workflow panels
- Reusable component library shared by the assessment screens
- API integration against the .NET services
- Role-based UI rendering and route guards
- Performance work on rendering and network behaviour
Key features
Application assessment
Document verification
Case workflow management
Role-based access control
Automated case routing
Operational reporting
Engineering decisions
- Problem
- Several panels on a single case screen each requested the same reference data independently, so opening one record produced the same lookup calls repeatedly.
- Decision
- Moved the reference lookups behind a shared RxJS stream with caching, so the panels subscribe to one in-flight request instead of issuing their own.
- Why
- The duplication was structural, not accidental: each panel was written to be self-sufficient. Caching at the data layer fixed every panel at once and left them independent.
- Trade-off
- Cached reference data can go stale within a session, so the cache is invalidated on the workflow events that can change it rather than held for the lifetime of the page.
- Result
- The panels on a case screen now share one in-flight request per reference lookup instead of each issuing its own.
Stack
| Frontend | Angular (standalone components) |
|---|---|
| State | RxJS |
| Styling | Tailwind CSS |
| API | .NET |
| Access | Role-based routing & UI guards |
Results
- Duplicate reference-data requests across the case workflow panels were replaced by a shared, cached RxJS stream.
- Rendering and workflow handling on the case screens were tuned as part of the same data-flow work.
- Designed to support high-volume government workflows across multiple operational teams.
Where to go next
- enterprise Angular development — the service this project is evidence for.
- Angular performance optimization — The service this project is the evidence for.
- The same request, five times — The shared-stream decision above, written out with the code and the trade-off.
- Angular Signals state management — The state-precision argument the same work rests on.
- Performance as a product requirement — Why request volume matters operationally, not just in a lab score.
Related case studies
next up →Fiji Immigration Citizen Portal


