Simplifying Complex Subsystems: The Facade Design Pattern in Angular

I believe that your frontend app should be seen as an extension of your API. Viewing it this way can help solve many issues that arise later in the development life cycle. As Angular applications grow in complexity, managing interactions between services, components, and APIs becomes more difficult. This often leads to tightly coupled code that is hard to maintain and prone to bugs. The Facade Design Pattern offers a powerful solution by providing a simplified interface that abstracts subsystem complexity, ensuring cleaner, more maintainable architecture.

When Angular Apps Become a Mess

It’s a common scenario: an Angular app starts simple, but as new features are added, it becomes a mess of tightly coupled components and services. Soon, business logic is scattered across components, service calls are made all over the place, and maintaining the app becomes a nightmare.

In such cases, fixing the architecture is not just a technical challenge but also a managerial one. First, management must understand that cleaning up the mess takes time, but it will pay off in the long run. Then, a team lead with a solid grasp of the problem and solutions, like applying design patterns such as the Facade, is crucial. Failing to address the issue will make it worse over time and may lead to the decision to rewrite the app, bringing back the same problems that existed before.

What is the Facade Pattern?

The Facade Design Pattern is a structural pattern that hides the complexity of subsystems by providing a simplified interface. In an Angular application, this means that instead of interacting with multiple services directly, your components can rely on a Facade service to interact with the underlying logic and services. This keeps components clean and focused on their UI logic, while the Facade handles business logic and service interactions.

Why Use the Facade Pattern in Angular?

1. Reduce Component Complexity: Components should focus on presenting data and handling user interactions. The Facade helps by offloading data-fetching logic and service calls into one cohesive service.
2. Encapsulate API or Service Changes: As your app evolves, APIs may change, and new features will be added. If services are directly called by components, updating those services would require changes in many places. The Facade pattern centralizes these updates, so only the Facade needs to be updated, while components remain untouched.
3. Simplified Testing: Components that rely on a Facade are easier to test because their dependencies are centralized. You can mock the Facade in unit tests rather than dealing with multiple services.

Real-World Example 1: User and Product Management

Let’s say your Angular app manages users and products through UserService and ProductService. Components without a Facade directly interact with these services:

this.userService.getUser().subscribe(...);
this.productService.getProducts().subscribe(...);        

Without the Facade, you now have to handle these service interactions in every component that needs this data. As the app grows, this will lead to a lot of duplicated code and logic scattered throughout the app.

Now, let’s introduce a Facade:

@Injectable({
  providedIn: 'root'
})
export class AppFacade {

  constructor(
    private userService: UserService,
    private productService: ProductService
  ) {}

  getUser(): Observable<User> {
    return this.userService.getUser();
  }

  getProducts(): Observable<Product[]> {
    return this.productService.getProducts();
  }
}        

In this scenario, your components no longer need to worry about individual services. Instead, they interact with the Facade:

this.appFacade.getUser().subscribe(...);
this.appFacade.getProducts().subscribe(...);        

By centralizing service interactions in a Facade, you reduce code duplication and make your components cleaner and easier to maintain.

Real-World Example 2: Handling API Changes

Suppose your application initially interacts with API v1, which returns a simple User object:

getUserV1(): Observable<{ id: number; name: string }> {
  return this.http.get<{ id: number; name: string }>('https://api.example.com/v1/user');
}        

Now, API v2 adds a new address field to the User object:

getUserV2(): Observable<{ id: number; name: string; address: { street: string, city: string, zip: string } }> {
  return this.http.get<{ id: number; name: string; address: { street: string, city: string, zip: string } }>('https://api.example.com/v2/user');
}        

If your components directly interact with the UserService, every place in the codebase that uses this service will need to be updated to handle the new API. However, with the Facade pattern, you only need to update the Facade:

getUser(): Observable<{ id: number; name: string }> {
  return this.userService.getUserV2().pipe(
    map(userV2 => ({
      id: userV2.id,
      name: userV2.name
      // Optionally ignore the new address field if it's not required
    }))
  );
}        

This shields your components from needing to know about the API change, preserving the integrity of the application while allowing the backend to evolve.

Real-World Example 3: Decoupling Business Logic

In more complex applications, business logic can be intertwined with component code. By using a Facade, you can centralize business logic in one place, making it easier to manage and adjust over time.

For instance, say your app applies different discount rules depending on user type (e.g., regular user vs. premium user). Instead of scattering this logic across components, you can encapsulate it in the Facade:

@Injectable({
  providedIn: 'root'
})
export class AppFacade {

  constructor(private userService: UserService, private productService: ProductService) {}

  getDiscountedProducts(): Observable<Product[]> {
    return combineLatest([this.userService.getUser(), this.productService.getProducts()]).pipe(
      map(([user, products]) => {
        if (user.isPremium) {
          return products.map(product => ({
            ...product,
            price: product.price * 0.8 // 20% discount for premium users
          }));
        } else {
          return products;
        }
      })
    );
  }
}        

Here, the Facade encapsulates the logic of applying discounts based on the user's type, while components remain clean and focused on rendering data.

Conclusion: Fixing a Messy Angular App with the Facade Pattern

When an Angular app turns into a mess, fixing it requires more than just coding. You need management buy-in to allocate time for the refactor, and a team lead who understands both the problem and the solution. By introducing the Facade Design Pattern, you can centralize complex service interactions and business logic, making the application more modular and easier to maintain.

This pattern not only helps clean up an existing mess but also prevents future issues by decoupling business logic and service interactions from components. However, it’s not just about knowing the pattern—it’s crucial to communicate it to people who can understand and implement it effectively.