DEV Community: George Kwabena Asiedu

🧹 Teardown Logic in Angular: Writing Cleaner, Safer Code with RxJS

George Kwabena Asiedu — Thu, 21 Aug 2025 16:08:01 +0000

Managing subscriptions in Angular applications is crucial for building scalable and leak-free apps. One of the key strategies is implementing proper teardown logic — the process of cleaning up resources when components, services, or observables are no longer needed.

In this post, we’ll break down what teardown logic is, why it matters, and which RxJS operators you can use to keep your Angular apps clean and efficient.

🔎 What is Teardown Logic?

In Angular and reactive programming, teardown logic refers to procedures executed to clean up resources when a component, service, or observable is destroyed.

It prevents:

Memory leaks
Unnecessary background processes
Subscriptions living longer than they should

This can include:

Stopping timers
Cancelling HTTP requests
Cleaning up event listeners
Unsubscribing from observables in ngOnDestroy

⚡ Teardown Operators in Action

takeUntil

Stops an observable stream based on another notifier observable.

Use cases:

Component cleanup (unsubscribe on destroy)
Conditional data fetching
Managing event listeners

⚠️ Limitation: Only supports a single notifier, and if the notifier never emits, the subscription stays active.

import { Component, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-list',
  template: `<p>Check console for user data</p>`
})
export class UserListComponent implements OnDestroy {
  private destroy$ = new Subject<void>();

  constructor(private userService: UserService) {
    this.userService.getUsers()
      .pipe(takeUntil(this.destroy$))
      .subscribe(users => console.log(users));
  }

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

2. takeUntilDestroyed

Automatically cleans up subscriptions when a component or service is destroyed.

Use cases:

Simplifying component lifecycle management
Reactive forms cleanup
Services managing multiple observables

⚠️ Limitation: Can be overused, reducing readability.

import { Component } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-profile',
  template: `<p>Check console for user profile</p>`
})
export class UserProfileComponent {
  constructor(private userService: UserService) {
    this.userService.getProfile()
      .pipe(takeUntilDestroyed())
      .subscribe(profile => console.log(profile));
  }
}

3. finalize

Runs a cleanup function when an observable completes, errors, or unsubscribes.

Use cases:

Freeing resources (file handles, network connections)
Logging and monitoring
Resetting UI state after HTTP requests

⚠️ Limitation: Does not give access to emitted values or errors.

import { Component } from '@angular/core';
import { finalize } from 'rxjs';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-loader',
  template: `<p *ngIf="loading">Loading user...</p>`
})
export class UserLoaderComponent {
  loading = true;

  constructor(private userService: UserService) {
    this.userService.getUser()
      .pipe(
        finalize(() => this.loading = false)
      )
      .subscribe(user => console.log(user));
  }
}

4. take

Completes after a set number of emissions.

Use cases:

Limiting API results
Capturing a fixed number of user events
Batch processing streams

⚠️ Limitation: After the set number is reached, the observable completes — remaining values are ignored.

import { Component } from '@angular/core';
import { interval } from 'rxjs';
import { take } from 'rxjs/operators';

@Component({
  selector: 'app-counter',
  template: `<p>Check console for counter values</p>`
})
export class CounterComponent {
  constructor() {
    interval(1000) // emits every second
      .pipe(take(5)) // ✅ only take first 5 values
      .subscribe(value => console.log(`Counter: ${value}`));
  }
}

💡 Best Practices for Teardown Logic

✅ Always implement teardown logic for observables to prevent memory leaks.
✅ Use operators like takeUntil + catchError for safe cleanup + error handling.
✅ Avoid oversubscribing — manage how many streams your components create.
✅ Be mindful of hot vs cold observables and performance implications.
✅ Use finalize strictly for cleanup, not for business logic.

Conclusion

Effective teardown logic is a must-have for Angular developers. By using RxJS operators like takeUntil, takeUntilDestroyed, finalize, and take, you ensure that your applications are robust, efficient, and free of memory leaks.
Implement these strategies, and your Angular codebase will be cleaner, safer, and easier to maintain.

Understanding Cloud Security with AWS Identity and Access Management (IAM)

George Kwabena Asiedu — Sat, 19 Apr 2025 17:42:53 +0000

In the AWS Shared Responsibility Model, AWS is responsible for the security of the cloud, while customers are responsible for security in the cloud. This means customers are accountable for securing the AWS services they use, such as Amazon EC2, Amazon S3, Amazon VPC, Amazon DynamoDB, Amazon RDS, Amazon IAM, and more.

In this article, we’ll focus on Cloud Security with AWS Identity and Access Management (IAM)—a powerful tool for controlling access to AWS resources.

What is AWS IAM?

AWS Identity and Access Management (IAM) is a web service that allows you to securely manage access to AWS resources. With IAM, you define who can access what and under what conditions. It provides the infrastructure necessary to manage authentication (who can sign in) and authorization (what they can do) across your AWS account.

Identities in IAM

When you first create an AWS account, you start with a root user—the identity that has full access to all AWS services and resources. This root user is tied to the email address used during account creation.

🔐 Security Best Practice: Avoid using the root user for day-to-day tasks. Instead, create an IAM user with administrative privileges and use that for regular operations.

Access Management

Once a user is created in IAM, they can authenticate using their credentials. IAM evaluates whether the user has permission to access specific AWS resources. This is determined by the policies attached to the user or their group or role.

For instance, when a user selects a service in the AWS Console, a request is sent to check:

Is the user authorized?
What policies are in place?
Are there any additional restrictions?

IAM ensures only authorized principals (users, roles, or federated identities) can access resources.

With IAM, you can:

Create users and user groups
Assign fine-grained permissions
Enforce security controls like MFA and password policies
Define who can do what across your AWS account

Key Components of IAM

IAM Users

These represent individuals who need access to your AWS resources—like you or your teammates.

IAM Groups

User groups (e.g., "Admins", "Developers") allow you to manage permissions collectively. Policies attached to a group apply to all its users.

IAM Roles

Roles provide temporary access to AWS resources. They're ideal for:

Applications running on EC2
Users from another AWS account
Federated users from corporate directories

IAM Policies

Policies are JSON or Visual Editor documents that define permissions. A policy specifies:

Effect: Allow or Deny
Action: What the principal can do (e.g., ec2:StartInstances)
Resource: What the action applies to

Example policy:

Allows all actions on a development EC2 instance
Denies tag creation and deletion

Account Alias

An account alias is a friendly name you can assign to your AWS account, making sign-in URLs more memorable than using your 12-digit AWS account ID.

Instead of:

https://88885770278076.signin.aws.amazon.com/console

You can use:

https://your-company.signin.aws.amazon.com/console

IAM Security Best Practices

🔐 Avoid using the root account for regular tasks
✅ Enable Multi-Factor Authentication (MFA) for all users
📉 Follow the principle of least privilege—grant only the permissions necessary
🔁 Rotate access keys and passwords regularly
📊 Use AWS CloudTrail to log and monitor activity
📦 Use IAM roles for applications instead of hardcoding credentials

Common IAM Use Cases

Grant an EC2 instance access to read/write data in S3
Allow developers to deploy to Lambda but not modify billing settings
Share access between AWS accounts using cross-account roles
Integrate with corporate identity providers using SAML or Active Directory

Conclusion

IAM is at the heart of AWS security. By effectively managing identities and access, you can maintain strong security postures, minimize risks, and ensure only the right people (or systems) have access to the right resources at the right time.

Security in the cloud starts with smart IAM practices.

Facade Pattern with NGRx Architecture

George Kwabena Asiedu — Fri, 14 Mar 2025 13:23:14 +0000

The Facade Pattern is a structural design pattern that provides a simplified interface to a complex subsystem. It acts as a "wrapper" or "gateway" that hides the complexities of the underlying system and exposes only the essential functionality to the client.

The Facade pattern is a structural design pattern that introduces a layer of abstraction between your component and the state management logic. Instead of interacting directly with the store, components rely on a Facade service that encupsulates all state-related operations.
Below are some situations where the Facade Pattern can be highly beneficial:

Simplifying Complex Subsystems: Use it when your application has multiple, complex subsystems. The facade hides these complexities by providing a simple interface, making the client code easier to use and understand.
Reducing Dependencies: If components are tightly coupled to multiple services, a facade can decouple them, making the codebase more flexible and easier to maintain.
Improving Code Organization: In large projects, the facade centralizes interactions with subsystems into a cohesive interface, enhancing readability and maintainability.
Enhancing Testability: Facades simplify testing by allowing you to mock a single facade instead of multiple services, making tests more reliable and less complex.
Encapsulating Cross-Cutting Concerns: Use a facade to manage concerns like logging or authentication in one place, ensuring consistent application across subsystems.
Providing a Stable API: If subsystems change over time, a facade offers a stable interface to clients, shielding them from underlying changes.

Why Use the Facade Pattern with NgRx?

NgRx is a powerful state management library for Angular, but it often introduces significant complexity due to the need to manage Actions, Reducers, and Selectors. This can lead to repetitive patterns and boilerplate code, making the architecture harder to understand and maintain, especially in large-scale projects.

The Facade Pattern provides a solution to this challenge by acting as an abstraction layer between components and the NgRx store. It simplifies state management by encapsulating the complexity of dispatching actions and selecting state, thereby reducing boilerplate code and improving code readability.

By using a facade, components can interact with the state more intuitively, leading to cleaner, more maintainable code and a better separation of concerns.

Facade in angular example

In Angular, implementing the Facade Pattern involves creating a service (the facade) that interacts with various other services or state management logic. This facade service acts as the single point of contact for components, providing a clean and simple API that abstracts away the complexities of the underlying system.

In the following example, the CommonFacade service abstracts the complexities of interacting with the NgRx store. It provides methods like loadAll, getGroceries, getBuckets, filterByGroceryType, addToBucket, removeFromBucket which hides the details of dispatching actions and managing state.

Components that need to add groceries to the bucket can do so without any knowledge of the underlying store or the need to dispatch actions directly.

This separation of concerns ensures that components are not only simpler and more focused on their primary roles but also more maintainable and less prone to errors associated with direct state management operations. By using the facade, the details of state management are hidden, allowing component developers to work with a cleaner and more straightforward API that does not expose the complexities of the underlying NgRx architecture. This approach significantly enhances the scalability and maintainability of the application, adhering to the principles of good software architecture by isolating the business logic from the UI components.

DEV Community: George Kwabena Asiedu

🧹 Teardown Logic in Angular: Writing Cleaner, Safer Code with RxJS

Understanding Cloud Security with AWS Identity and Access Management (IAM)

What is AWS IAM?

Identities in IAM

Access Management

Tags

Key Components of IAM

IAM Users

IAM Groups

IAM Roles

IAM Policies

Account Alias

IAM Security Best Practices

Common IAM Use Cases

Conclusion

Facade Pattern with NGRx Architecture

Why Use the Facade Pattern with NgRx?

Facade in angular example