Gutting the Monolith: A Rebuild Log Using an Angular Architecture

It was a miserable Thursday evening, chucking it down with rain outside, and I was staring at a sluggish terminal window, trying to figure out why my database connections were suddenly maxing out. I manage a handful of web properties on a few digital ocean droplets. Most of them are fairly quiet, standard business sites. But the main resource hog is a custom-built entertainment portal where people basically just hang around to play HTML5 arcade games. The frontend of that site is heavily cached and sits behind a CDN, so it handles traffic spikes without breaking a sweat. The problem, as is often the case with legacy setups, was the administrative backend.

My old dashboard was a sprawling, chaotic mess of raw PHP scripts, bolted-on jQuery plugins, and inline SQL queries that I had written years ago when I didn't know any better. Every time one of my moderators clicked a link to ban a spam account or approve a new game upload, the server had to grind through thousands of lines of code, re-render the entire HTML page—including the heavy sidebar and header navigation—and send the whole lot back down the wire. It was horribly inefficient. On that particular Thursday, a few moderators were bulk-processing old comments simultaneously, and the sheer volume of synchronous page reloads caused the PHP worker pool to hit its limit. The server threw a wobbly and stopped responding.

I managed to restart the services and get things stable, but that was the breaking point. I couldn't keep patching this spaghetti code. I needed to fundamentally change how the backend communicated with the server. I needed to stop shipping massive HTML documents on every click and move to a Single Page Application (SPA) architecture, where the browser only fetches raw data and updates the view locally.

This is a log of that refactoring process. It’s not a quick tutorial, but a breakdown of why I chose Angular, how I structured the new application, the headaches I ran into with state management, and the reality of maintaining it from an operations perspective.

The Architectural Decision: Why Angular?

When you decide to build an SPA these days, the default reaction from the developer community is usually to point you toward React or Vue. I looked at both. They are fast, popular, and have massive ecosystems. But from my perspective as a sysadmin and someone who prioritizes long-term stability over the latest coding trends, they felt a bit too loose.

React, for instance, isn't really a framework; it's a library for building user interfaces. If you want routing, you have to pick a third-party router. If you want HTTP calls, you bring in Axios. If you want state management, you wire up Redux or Zustand. You essentially have to build your own framework by stitching together different packages.

I didn't want to make those decisions. I wanted a rigid, opinionated framework that told me exactly where to put my files, how to inject my dependencies, and how to structure my HTTP requests. I wanted something that felt more like a traditional backend MVC framework, just running in the browser.

That led me to Angular.

Angular is heavy. It has a notoriously steep learning curve. It relies heavily on TypeScript and object-oriented programming concepts like classes, interfaces, and decorators. But that strictness is exactly what appealed to me. As a solo maintainer, I wanted the compiler to yell at me if I passed the wrong data type to a component. I wanted the structured predictability of Angular's module system. If I come back to this codebase in two years to fix a bug, I know exactly how the data flow works because Angular forces you to do it the "Angular way."

Finding the Scaffolding

Building an Angular application entirely from scratch is a massive undertaking. Setting up the Angular CLI is easy enough (ng new my-app), but then you have to build out the entire layout shell: the responsive sidebar, the top navigation bar, the grid system, the basic form styling, and the SCSS variables. I am not a designer. My attempts at writing CSS usually end up looking like a spreadsheet from 1998.

I needed a structural foundation to save me a month of frontend styling work. I scoured the web for a clean, professional template that was built natively in Angular (not just a jQuery template with an Angular wrapper thrown over it, which is sadly common).

After evaluating a few options, I decided to use the Zanex - Angular Admin & Dashboard Template as my starting point. I wasn't interested in the dozens of flashy chart demos or the dummy e-commerce pages it came with. I chose it because of its underlying architecture. It was structured using Angular's lazy-loading routing principles, it utilized standard Angular Material concepts, and the SCSS was cleanly separated into variables and mixins. It provided the bare structural shell I needed so I could focus entirely on writing the business logic and wiring up the APIs.

Phase 1: The Great Purge and Restructuring

Whenever you buy or download a pre-built template, the very first thing you have to do is gut it. Templates are designed to show off every possible feature to potential buyers, meaning they are bloated with hundreds of components and third-party libraries you will never use. From an operations standpoint, leaving that bloat in your project increases your build times, swells your final JavaScript bundle size, and creates a massive security surface area with unnecessary node_modules dependencies.

I opened the project in my editor and spent an entire weekend just deleting things.

First, I went straight to the package.json file. I stripped out the calendar plugins, the map libraries, the complex charting tools, and the drag-and-drop file uploaders. I ran npm install to clean up the tree.

Next, I tackled the directory structure. An Angular app needs a logical flow. I reorganized the remaining files into three distinct areas:

1. Core Module (/src/app/core/): This is where I put things that should only be instantiated once in the entire application lifecycle. This included my authentication service, my HTTP interceptors, and the global error handler.
2. Shared Module (/src/app/shared/): This housed the dumb, reusable UI components. My custom data table component, pagination controls, loading spinners, and generic form input wrappers went here. The Shared Module doesn't know anything about the business logic; it just takes inputs (@Input()) and emits events (@Output()).
3. Feature Modules (/src/app/features/): This is where the actual pages lived. I created separate folders for users, games, settings, and logs.

Of course, deleting 80% of a template's files immediately breaks the application. I ran ng serve and watched the terminal spit out hundreds of red compilation errors. It took me about three days of tracing broken import paths and removing orphaned route declarations in the app-routing.module.ts before the terminal finally showed a green "Compiled successfully" message.

What I was left with was a pristine, empty shell. A clean white dashboard with a dark sidebar, a top bar, and a central <router-outlet> waiting for my custom components.

Phase 2: Rethinking the Routing and Lazy Loading

In my old PHP setup, routing was handled by Nginx and a massive .htaccess file that mapped URLs to specific PHP files. If you went to /admin/users, the server parsed users.php.

In Angular, the server just sends down a single index.html file and a bundle of JavaScript. The Angular Router takes over from there, reading the URL in the browser's address bar and swapping out the components dynamically without hitting the server again.

However, if you aren't careful, Angular will bundle your entire application into one massive main.js file. If I put all my user management logic, game upload logic, and server log logic into one module, the user would have to download a 5MB JavaScript file just to view the login screen. That defeats the entire purpose of a fast SPA.

This is where lazy loading comes in, and it was a critical part of my architectural refactoring.

Instead of importing my feature components directly into the main AppModule, I created separate routing modules for each feature. My main app-routing.module.ts ended up looking something like this:

const routes: Routes = [
  { path: '', redirectTo: 'dashboard', pathMatch: 'full' },
  { 
    path: 'login', 
    loadChildren: () => import('./features/auth/auth.module').then(m => m.AuthModule) 
  },
  {
    path: '',
    component: LayoutComponent, // The Zanex shell
    canActivate: [AuthGuard],
    children: [
      { 
        path: 'dashboard', 
        loadChildren: () => import('./features/dashboard/dashboard.module').then(m => m.DashboardModule) 
      },
      { 
        path: 'users', 
        loadChildren: () => import('./features/users/users.module').then(m => m.UsersModule) 
      },
      { 
        path: 'games', 
        loadChildren: () => import('./features/games/games.module').then(m => m.GamesModule) 
      }
    ]
  },
  { path: '**', redirectTo: 'dashboard' }
];

This structural decision is huge for performance. When a moderator navigates to admin.mysite.com, the browser only downloads the core framework, the layout shell, and the Auth module. If they never click on the "Games" tab, they never download the JavaScript required to render the game management views. It keeps the initial memory footprint incredibly low.

Phase 3: The API Shift and HTTP Interceptors

With the frontend shell running locally and the routes lazily loading, I had to figure out how to actually get data into the application.

My old backend relied heavily on server-side PHP sessions. You logged in, PHP created a session file on the server, and stored a cookie in your browser. Every subsequent request checked that session file.

This doesn't work well when you separate the frontend and backend. I was moving to a stateless REST API architecture. I built a new set of API endpoints using an updated PHP framework (running on a separate api. subdomain) that strictly returned JSON.

Instead of sessions, I moved to JSON Web Tokens (JWT). When you log in through the Angular frontend, the PHP API verifies your credentials and returns a signed string (the JWT). The Angular application stores this token in localStorage.

The challenge then becomes: how do I attach this token to every single HTTP request the dashboard makes? I didn't want to manually add an Authorization header to every HttpClient.get() call scattered across fifty different components.

Angular provides a brilliant structural tool for this called an HttpInterceptor. I created a file named jwt.interceptor.ts in my Core module.

@Injectable()
export class JwtInterceptor implements HttpInterceptor {
    constructor(private authService: AuthService) {}

    intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
        const token = this.authService.getToken();

        if (token) {
            request = request.clone({
                setHeaders: {
                    Authorization: `Bearer ${token}`
                }
            });
        }
        return next.handle(request);
    }
}

This single piece of middleware intercepts every outgoing HTTP request, clones it, injects the Bearer token into the headers, and sends it on its way. It is clean, centralized, and highly maintainable.

I also created a second interceptor: the ErrorInterceptor.

In an SPA, if a user's token expires while they are looking at a screen, you need to handle that gracefully. If the Angular app makes a request and the PHP API returns a 401 Unauthorized status, the ErrorInterceptor catches it globally. It instantly wipes the local storage, displays a quick toast notification saying "Session Expired", and uses the Angular Router to boot the user back to the /login route.

Implementing these two interceptors completely stabilized the communication layer between the Angular shell and the new API.

Phase 4: Rethinking Forms with Reactive Forms

One of the most tedious parts of backend administration is data entry and validation. Think about adding a new title to the arcade portal. You need a form for the title, the category dropdown, a description text area, and file inputs for the thumbnail and the game package.

In the old days, I used standard HTML forms. You hit submit, the browser POSTed the data, the server validated it, and if you forgot to fill in the description, the server reloaded the entire page, passing back a red error message.

Angular offers two ways to handle forms: Template-driven forms (which feel similar to old HTML forms) and Reactive Forms. I chose to strictly use Reactive Forms for the refactor.

Reactive Forms move the validation logic out of the HTML template and into the TypeScript component class. You define the form's structure programmatically using a FormBuilder.

For the game upload form, my component code looked something like this:

export class GameAddComponent implements OnInit {
  gameForm: FormGroup;

  constructor(private fb: FormBuilder, private apiService: ApiService) {}

  ngOnInit() {
    this.gameForm = this.fb.group({
      title: ['', [Validators.required, Validators.minLength(3)]],
      category: ['', Validators.required],
      description: [''],
      status: ['draft']
    });
  }

  onSubmit() {
    if (this.gameForm.valid) {
      this.apiService.createGame(this.gameForm.value).subscribe({
        next: (res) => console.log('Saved successfully'),
        error: (err) => console.error('Server error', err)
      });
    }
  }
}

This structure is a lifesaver from a maintenance perspective. The HTML file just binds to these controls. I can test the form validation logic entirely independently of the DOM.

More importantly, it allows for instant, synchronous validation feedback. If a moderator types a title that is only two characters long, the this.gameForm.get('title').invalid state becomes true instantly. I use that state in the HTML template to conditionally render a red border around the input field and display a warning message before they even try to hit the submit button. It eliminates unnecessary API calls and makes the interface feel incredibly snappy.

Phase 5: The RxJS Headache and Memory Management

If you dive into Angular, you inevitably run headfirst into RxJS (Reactive Extensions for JavaScript). Angular uses it for almost everything. HTTP calls return an Observable. Routing events are Observables. Form value changes are Observables.

An Observable is basically a stream of data that you can subscribe to. It is incredibly powerful, but it was the source of my biggest headache during the refactor.

About three weeks into the build, I was testing the live server stats view on my local machine. I had set up an Observable that polled the API every 10 seconds to get the current number of active users playing games on the arcade site.

I clicked onto the stats page, saw the number update, and then clicked away to the user management page. A few minutes later, I noticed my local API server was still getting hit with requests every 10 seconds.

I had created a memory leak.

When you navigate away from a component in an Angular SPA, the component is destroyed from the DOM. However, if you subscribed to an Observable (like a polling timer) inside that component and didn't explicitly tell it to stop, that subscription stays alive in the browser's memory, running silently in the background forever.

If I clicked back and forth between the stats page and the users page twenty times, I created twenty concurrent polling intervals. The browser would eventually choke and crash.

Fixing this required a strict structural rule across the entire application. I had to manage my subscriptions.

There are several ways to do this in Angular, but the cleanest method I found was the takeUntil pattern. I created a base component class that implemented Angular's ngOnDestroy lifecycle hook.

export class BaseComponent implements OnDestroy {
  protected destroy$ = new Subject<void>();

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

Then, I made sure every single component I wrote extended this base class. Whenever I subscribed to a stream of data, I piped it through takeUntil.

export class StatsComponent extends BaseComponent implements OnInit {
  ngOnInit() {
    timer(0, 10000)
      .pipe(takeUntil(this.destroy$))
      .subscribe(() => {
        this.fetchLiveStats();
      });
  }
}

Now, when the router destroys the StatsComponent, the ngOnDestroy method fires, the destroy$ subject emits a value, and the takeUntil operator instantly kills the polling subscription.

It was a harsh lesson in manual garbage collection. In the old PHP days, the server wiped the slate clean on every page load. In a long-running SPA environment, you are responsible for cleaning up your own mess. Once I implemented this teardown pattern globally, the memory footprint of the dashboard flatlined and became rock solid.

Phase 6: Dealing with State Management (Without Redux)

As the application grew, I ran into the classic SPA problem: sharing data between components that aren't directly related.

For instance, the top navigation bar displays the logged-in user's avatar and a notification bell showing unread messages. The user profile page allows the user to upload a new avatar.

If a user uploads a new avatar on the profile page, how does the top navigation bar know to update its image without a full page reload?

The enterprise solution in the Angular world is usually NgRx, a complex state management library based on Redux. I looked at the boilerplate required for NgRx—actions, reducers, selectors, effects—and decided it was absolute overkill for a relatively simple admin dashboard. I didn't want to write fifty lines of code just to update a profile picture.

Instead, I used a simpler architectural pattern using RxJS BehaviorSubjects within an Angular Service.

I created a UserService. A service in Angular is a singleton, meaning only one instance of it exists in memory for the lifetime of the application.

Inside the UserService, I defined a BehaviorSubject that holds the current user's profile data.

@Injectable({ providedIn: 'root' })
export class UserService {
  private currentUserSubject = new BehaviorSubject<UserProfile | null>(null);
  public currentUser$ = this.currentUserSubject.asObservable();

  updateUserProfile(profile: UserProfile) {
    // API call goes here, on success:
    this.currentUserSubject.next(profile);
  }
}

The top navigation component subscribes to currentUser$. The profile editing component injects the same service. When the upload finishes, the profile component calls updateUserProfile(). The BehaviorSubject emits the new data, and the top navigation component instantly reacts and swaps the image.

It achieves the reactive state synchronization of Redux but keeps the mental overhead drastically lower. From an operations perspective, keeping the codebase simple and understandable is far more valuable than implementing complex enterprise patterns just for the sake of it.

Phase 7: Deployment Realities and Nginx Configuration

After a solid month of weekend coding, the Angular dashboard was feature-complete. The routing was lazy, the interceptors were catching errors, and the memory leaks were plugged. It was time to deploy it to the production server.

Deploying an Angular SPA is fundamentally different from deploying a PHP application. You don't upload your source code to the server. Instead, you run a build command locally.

I ran ng build --configuration production. The Angular compiler (Ivy) went to work. It performed Ahead-of-Time (AOT) compilation, turning my HTML templates into optimized JavaScript instructions. It minified the CSS, removed unused code (tree-shaking), and bundled everything into a few highly compressed files inside a dist/ directory.

The total size of the compiled application was surprisingly small—less than 1MB for the initial load.

I uploaded the contents of the dist/ folder to my server's /var/www/admin directory.

However, if you just point a standard web server at an SPA, you run into a major routing problem. If I navigate to admin.mysite.com, Nginx serves index.html. The Angular router starts up and defaults to the /dashboard route. Everything works fine.

But if I manually type admin.mysite.com/users into the address bar and hit enter, the browser asks Nginx for a file named users or a directory named /users/. Nginx looks in /var/www/admin, doesn't find it, and throws a 404 Not Found error. Nginx doesn't know about Angular's internal routing.

I had to modify my Nginx server block to handle this fallback mechanism. The configuration is straightforward but absolutely vital for an SPA:

server {
    listen 80;
    server_name admin.mysite.com;
    root /var/www/admin;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    # Cache static assets aggressively
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, max-age=31536000, immutable";
    }
}

The magic line is try_files $uri $uri/ /index.html;. This tells Nginx: "If someone asks for a URL, first try to find a physical file that matches. If you can't find a file, try to find a directory. If you still can't find anything, don't throw a 404. Instead, serve index.html."

By serving index.html, Angular boots up, reads the /users path from the URL, and dynamically renders the correct view.

I also added aggressive caching headers for the static assets. Because the Angular compiler hashes the filenames on every build (e.g., main.a4b3c2.js), I can tell the browser to cache these files for a year. If I push an update, the filename changes, and the browser automatically fetches the new code, bypassing the cache. It completely eliminates the "please clear your cache" support tickets I used to get from my team.

Post-Launch Observations

It has been several months since I fully transitioned the backend over to the Angular architecture. The difference in daily operations is night and day.

The immediate relief was felt on the server. Because the server is no longer responsible for rendering HTML views on every click, the CPU load dropped dramatically. The API simply queries the database and spits out small JSON strings. The heavy lifting of building the interface has been entirely offloaded to the user's browser.

The workflow for the moderation team has improved significantly. The interface feels snappy and native. They can filter tables, sort columns, and update records without losing their place on the screen. The constant tab-switching has stopped because the application itself is fast enough to handle continuous input.

Using a structural template was definitely the right call. Having the SCSS, grid system, and base Angular layout already wired up saved me from the tedious work of frontend design, allowing me to focus strictly on the data architecture and API integration. It served as a solid scaffolding for the logic.

Was Angular the easiest path? No. The learning curve was steep. Wrapping my head around RxJS streams, BehaviorSubjects, and proper component lifecycle teardown took time and a fair bit of frustration. A simpler library might have gotten me a working prototype faster.

However, from a maintenance and stability perspective, the strictness of Angular has paid off. The TypeScript compiler catches 90% of my errors before I even save the file. The modular structure means I know exactly where a specific piece of logic lives. If the arcade portal gets a new feature, I can easily generate a new lazy-loaded module in the admin panel without worrying about breaking the existing user management routes.

Refactoring a legacy monolith is an exhausting process, but replacing a flaky, server-choking PHP dashboard with a predictable, stateless SPA architecture is one of the best operational decisions I’ve made. It turned an unmaintainable mess into a stable, quiet piece of infrastructure.