Angular Migration of the KomMonitor Web Client
GSoC mid-term blog post
When I started working on the KomMonitor project, I inherited a partially migrated codebase from a previous GSoC attempt. The goal was ambitious: migrate the entire KomMonitor Web Client application from AngularJS to Angular while maintaining functionality and improving the overall architecture. The existing codebase presented a complex web of tightly coupled services and components that had grown organically over time.
Strategic Decision: Components First, Services Later
After analyzing the codebase architecture, my mentor and I made a crucial strategic decision to migrate components first, then tackle services. This approach made sense because services in the AngularJS codebase were tightly interwoven with components, making it nearly impossible to test newly migrated Angular services with old AngularJS components. Starting with independent components provided visible, testable progress that could be validated immediately while reducing the risk of breaking existing functionality.
We discovered this when we tried to migrate independent services such as the Keycloak helper service using Angular version 14 of the Keycloak Angular library. While the service itself was easy to port, we quickly discovered a major limitation: the new Angular service couldn’t be reliably tested or used within existing AngularJS components. Attempting to bridge the two using Angular’s downgradeModule resulted in unreadable console errors and unstable behavior.
The root issue was an authentication state being managed simultaneously in both AngularJS and Angular, which led to complexity, potential conflicts, and an impractical setup. This made it clear that even independent services—especially ones dealing with authentication—should only be migrated after all related components have transitioned to Angular.
As an interim step, we chose to upgrade the Keycloak JavaScript adapter within the AngularJS codebase, which wasn’t a full migration but still provided valuable benefits like improved stability and compatibility.
Focus Area: AdminView Migration
My primary focus has been migrating the AdminView section of the KomMonitor client. Each week, my mentors and I tackle one specific part of the admin view during our meetings. These sessions involve technical review of the migrated components, discussion of UX/UI improvements, and identifying opportunities for modernization. This is a list of some components that I have successfully migrated so far
- adminConfig
- Migrated 4 legacy code editors using deprecated CSS syntax highlighting to CodeMirror read-only editors.
- Created a custom Auth Interceptor for “POST”requests to handle secure config updates.
- Ensured structure consistency with legacy folder hierarchy
- adminDashboardManagement
- First view shown when Admin View is toggled.
- Added responsive layout using “flex-wrap” for better mobile support.
- Updated pie chart color scheme to match design system.
- All original functionality, including broadcast event handling
- adminRoleExplanation
- Rebuilt using Angular Bootstrap Accordion component.
- Fixed UX issue: Only one accordion opens at a time, unlike the AngularJS version where multiple would expand.
- Implemented structured functions to simplify creation of future accordion-based topics.
- adminSpatialUnitsManagement
- Migrated as part of a large, complex component.
- Included multiple modals:
- Edit Metadata, Edit Feature, Edit User Role, Add, and Delete
- Utilized Ag-Grid for rendering tabular data.
- Follows a lean migration approach, covered later in the blog.
- adminTopicsManagement
- Migrated a hierarchical component with deeply nested child components.
- Aligned edit and delete modals for better UI readability.
- Maintained logic flow while improving visual consistency.
- adminViewModal
- Displays the user’s current state, including roles assigned and the group they belong to.
- Includes “Relogin” and “Logout” buttons for session control.
- Logs the duration of the user’s session time for monitoring purposes.



During the migration process, I discovered that many AngularJS services relied on deprecated libraries. For modal management, I replaced deprecated Bootstrap modal methods with NgbModal from NG Bootstrap. Similarly, while migrating KomMonitorKeycloakService, I used the new Angular-supported version called keycloak-angular that’s compatible with Angular 14. Step by step, my mentors and I are working on not only to make the UI clean but also to replace deprecated, unsupported libraries with stable ones.
The Major Roadblock: Monolithic Services
The project’s biggest challenge emerged when we encountered massive services like KomMonitorDataExchangeService and KomMonitorDataGridHelperService, both containing over 4000 lines of code and tightly interwoven into various components throughout the KomMonitor client.
Our initial strategy was to create a comprehensive roadmap for migrating these monolithic services entirely. However, this approach quickly revealed critical issues. I couldn’t test the new Angular services with existing AngularJS components, and when I tried the official Angular downgrade method, it produced errors due to complex dependencies. With so many dependent services, fixing specific errors couldn’t guarantee that the service was completely migrated and would work perfectly.
We then considered creating a code sandbox component to test newly migrated services in isolation. However, this approach had a fundamental flaw: it deviated from our goal of creating services that could actually be used within the existing component ecosystem.
The Breakthrough: Lean Migration Strategy
After facing challenges with the monolithic migration approach, we developed what I call the “Lean Migration Strategy.” This method emphasizes migrating AngularJS components incrementally, along with only the necessary service logic, to ensure modularity and testability.
- Select a target component: Identify a specific AngularJS component to migrate, ideally one with minimal dependencies.
- Trace service usage: Pinpoint exactly which methods from existing services are used by that component.
- Migrate only relevant service parts: Port just those service methods required by the component into the new Angular service structure.
- Test component + service in isolation: Validate functionality in a controlled environment, ensuring component and migrated service logic work together seamlessly.
- Integrate into the main codebase: Once tested, merge the migrated component and service into the broader application without affecting unrelated areas.
This step-by-step, component-centric approach enabled faster, safer migrations, minimized regressions, and provided a clear sense of progress during each iteration. This approach offers several advantages.
- Isolated Testing of New Services: Migrating services together with their related components allows us to test them in isolation, without interference from legacy AngularJS code.
- Tangible, Functional Progress with Each Component: Every component migrated using this strategy represents a fully functional and testable part of the application. This creates visible momentum and allows for incremental deployment.
- Reduced Risk of Bugs Through Smaller Units: By focusing on smaller, self-contained migration tasks, we minimize the surface area for errors.
I’m currently applying the Lean Migration Strategy to the adminRoleManagement component, which handles user role assignments and permissions, and the adminSpatialUnit component, which manages spatial data units and their relationships. Both components heavily utilize komMonitorGridHelperService, making them perfect candidates for testing our new migration approach.
Reflection: A Journey of Growth and Innovation
So far the GSoC experience has been transformative in more ways than I initially anticipated. Each merged Pull Request brings not just technical progress, but also intense pride and satisfaction. The journey from struggling with monolithic service migrations to developing the Lean Migration Strategy has taught me valuable lessons about adaptive problem-solving in complex software projects.
The collaboration with my mentor has been instrumental in navigating these challenges. Our weekly discussions have not only kept the project on track but have also fostered an environment of continuous learning and innovation. With half the journey complete, I’m excited about the remaining work and confident that the foundation we’ve built will enable us to deliver a fully migrated, modern, and maintainable KomMonitor application.
Leave a Reply