Skip to main content

System Overview

Antrix currently appears to be a multi-application platform made up of one frontend portal and multiple backend services.

Main components​

  • intt-mobile: Flutter mobile field support app for Antrix workflows
  • intt-portal: Angular frontend used by end users
  • mvp1-authentication-service: authentication and access-related backend
  • mvp1-setting-service: settings and configuration backend
  • mvp2-data-service: dashboard, reporting, and analytics backend
  • mvp3-ngoss-service: NGOSS-related backend
  • mvp3-nocgrid-service: NOC Grid-related backend
  • mvp3-nocpro-service: NOCPro-related backend
  • mvp3-gsb-service: GSB-related backend workflows
  • mvp3-ticket-service: ticket management backend workflows
  • mvp3-tmf-service: TMF-related backend workflows
  • mvp6-vital-service: Vital-related backend workflows
  • queue worker services: async and message-driven processing across several domains

High-level shape​

Users
  -> intt-portal
  -> intt-mobile
      -> core and domain API services
          -> authentication-service
          -> setting-service
          -> data-service
          -> ticket-service
          -> gsb-service
          -> ngoss-service
          -> nocgrid-service
          -> nocpro-service
          -> tmf-service
          -> vital-service
      -> queue workers
          -> caution-report queue
          -> changedp queue
          -> ctt queue
          -> gsb queue
          -> kci queue
          -> tass queue
          -> vital queue

Frontend summary​

Based on the current project docs, intt-portal:

  • is an Angular single-page application
  • uses lazy-loaded feature modules
  • uses OIDC and SSO redirect handling
  • exchanges SSO identity for application tokens through backend APIs
  • routes business flows through pages such as CR, NTT, RNTT, CTT, and GSB

Mobile summary​

Based on the current intt-mobile README, the mobile app:

  • is a Flutter field support application
  • supports operational modules such as GSB actions, Create NTT, Caution Report, and History
  • handles login and TMSSO callback or deep-link style flows
  • uses provider and Riverpod state management
  • stores mobile context locally and launches modules from a shared shell

Backend summary​

The backend services are mostly NestJS applications with similar operational commands and patterns. Several services share a share-entity module, which suggests common entities, models, or utilities are reused across service boundaries.

Queue layer​

The current workspace also includes multiple queue-focused services. These should be treated as part of the architecture, not as optional repo noise, because they likely own:

  • background job processing
  • integration handoffs
  • async workflow stages
  • message consumption and publishing

Architecture characteristics​

  • multiple independently run repositories
  • shared backend conventions
  • shared submodule usage
  • multiple client apps across web and mobile
  • frontend-to-service integration rather than one single backend
  • synchronous API services plus asynchronous queue workers
  • likely external infrastructure dependencies such as DB, Redis, and message brokers

Documentation goal​

This documentation site should answer three architecture questions clearly:

  1. what each service owns
  2. how services interact
  3. what a developer must run to work on a given feature

Use Architecture Diagrams for the visual version of this page.