DEV Community: Tesleem Amuda

Understanding Subjects in RxSwift: The Day Everything Clicked

Tesleem Amuda — Thu, 06 Aug 2026 13:32:00 +0000

I remember the exact moment Subjects stopped feeling like magic and started feeling like tools I could actually control.

I had been using RxSwift for a while. Observables made sense. Operators were powerful. Binding worked. But every time I needed to push values into a stream myself — from a network callback, a button action, or some internal state change — I just reached for PublishSubject and moved on. It worked… until it didn’t.

Then one day I sat down and actually looked at the different types of Subjects. That was the turning point. Suddenly a lot of the weird behaviour I’d been fighting made sense, and I started writing cleaner reactive code.

This article is the deep-dive I wish I had back then.

Quick Refresher: What Even Is a Subject?

A Subject is both an Observable and an Observer.

That means:

You can subscribe to it (like a normal Observable)

You can also call .onNext(), .onError(), and .onCompleted() on it yourself

This dual nature is extremely useful, but it’s also where a lot of the confusion (and bugs) come from.

There are four main types in RxSwift:

PublishSubject
BehaviorSubject
ReplaySubject
AsyncSubject

Let’s go through each one properly.

1. PublishSubject – The Event Bus

let publishSubject = PublishSubject<String>()

publishSubject.onNext("A") // Nobody is listening yet → gone forever

let subscription = publishSubject.subscribe(onNext: { print($0) })

publishSubject.onNext("B") // prints "B"

publishSubject.onNext("C") // prints "C"

Key behaviour:

Starts empty
Only emits values to subscribers after they subscribe
Does not keep any history
Perfect for discrete events (button taps, notifications, “something just happened”)

When I reach for it:

UI events that shouldn’t replay
One-shot signals between layers
Any time I truly don’t care about past values

Common pitfall:
People sometimes use PublishSubject for state. Then a late subscriber gets nothing and the UI stays blank. That’s usually a sign you needed a BehaviorSubject instead.

2. BehaviorSubject – State That Always Has a Current Value

let behaviorSubject = BehaviorSubject(value: "Initial")

behaviorSubject.subscribe(onNext: { print("Subscriber 1:", $0) })

// Immediately prints: Subscriber 1: Initial

behaviorSubject.onNext("Updated")

behaviorSubject.subscribe(onNext: { print("Subscriber 2:", $0) })

// Immediately prints: Subscriber 2: Updated

Key behaviour:

Requires an initial value
Always holds the latest value
New subscribers get that latest value immediately
After that, they get new values as they arrive
This is the Subject I use the most in real apps.

Typical use cases:

Current user profile
Selected tab or filter
Loading / error / success state of a screen
Any piece of state that the UI needs right now

Important notes:
Calling .onCompleted() or .onError() terminates it permanently. After that, new subscribers only get the terminal event.

If you need something that never completes and is easier to work with from the UI side, many people prefer BehaviorRelay (from RxRelay). But under the hood it’s still built on BehaviorSubject.

Common pitfall:
Creating a BehaviorSubject with a dummy initial value just to satisfy the compiler, then immediately overwriting it. That dummy value often leaks into the UI for a brief moment.

3. ReplaySubject – “Here’s What You Missed”

let replaySubject = ReplaySubject<String>.create(bufferSize: 2)

replaySubject.onNext("A")

replaySubject.onNext("B")

replaySubject.onNext("C")

replaySubject.subscribe(onNext: { print($0) })

// prints:

// B

// C

Key behaviour:

Keeps a buffer of the last N values
New subscribers receive those buffered values first, then live values
You can also create an unbounded version with .createUnbounded(), but be careful with memory

When it’s useful:

You need a short history (last few locations, last few search results, etc.)
Multiple subscribers joining at different times should all see recent activity
Debugging or logging streams where context matters

Common pitfall:

Using a large or unbounded buffer without thinking. It’s easy to accidentally keep a lot of objects alive and create memory pressure.

4. AsyncSubject – The Final Result Only

let asyncSubject = AsyncSubject<String>()

asyncSubject.subscribe(onNext: { print($0) })

asyncSubject.onNext("A")

asyncSubject.onNext("B")

asyncSubject.onNext("C")

asyncSubject.onCompleted()

// Only now does it print: C

Key behaviour:

Ignores everything until the sequence completes
Then emits only the last value (if any) and completes
If it errors, subscribers get the error instead

This one is the least used in day-to-day iOS work, but it’s perfect for “I only care about the final answer” scenarios — like a long-running calculation or a multi-step process that should only notify when fully done.

Common pitfall:

Forgetting to call .onCompleted(). Without it, nothing ever emits.
Side-by-Side Comparison

Real-World Pitfalls I’ve Hit (and How to Avoid Them)

1. Subjects and Memory Leaks
Subjects themselves don’t cause retain cycles, but the way we hold them does.

class ViewModel {

    let events = PublishSubject<Void>()



    func setup() {

        events

            .subscribe(onNext: { [weak self] in   // ← easy to forget

                self?.doSomething()

            })

            .disposed(by: disposeBag)

    }

}

Always capture self weakly inside the subscription if the subject lives on self.

2. Completing a Subject Too Early
Once a Subject receives .onCompleted() or .onError(), it’s done. Forever. New subscribers only get the terminal event.

If you need a long-lived stream of events, never complete the Subject unless you’re intentionally shutting it down.

3. Using the Wrong Subject for State
This is the most common intermediate mistake.

Need the current value right away when someone subscribes? → BehaviorSubject
Pure event that shouldn’t replay? → PublishSubject
Need a few recent values? → ReplaySubject

Choosing wrong usually shows up as “the second screen that opens doesn’t have the data” or “old events keep firing when they shouldn’t.”

4. Threading Surprises
Subjects are not magically thread-safe in the way some people expect. If you call .onNext from multiple threads without care, you can get race conditions.

In practice I usually make sure all emissions happen on a known scheduler (often MainScheduler for UI-related subjects).

5. Over-using Subjects
Subjects are convenient, but they make your code more imperative. Whenever possible, prefer pure Observables that are created from existing sources (network, notifications, UI controls, etc.). Reach for a Subject only when you genuinely need to push values from outside the reactive chain.

A Practical Pattern I Use Often

final class SomeViewModel {

    // Private so only the ViewModel can emit

    private let _state = BehaviorSubject<ViewState>(value: .loading)



    // Public read-only version

    var state: Observable<ViewState> {

        _state.asObservable()

    }

    func loadData() {

        // ... network call

        _state.onNext(.loaded(data))

        // or

        _state.onNext(.error(error))

    }

}

This pattern keeps the mutability private while still giving the UI a clean Observable to bind to.

Final Thoughts

The day I properly understood the difference between PublishSubject, BehaviorSubject, ReplaySubject and AsyncSubject was the day my RxSwift code got noticeably cleaner. I stopped fighting the library and started choosing the right tool for the job.

You don’t need to memorise every edge case. Just remember the core idea:

Publish → pure events
Behavior → current state
Replay → recent history
Async → final result only

Once that clicks, the rest becomes muscle memory.

If you’ve been using mostly PublishSubject for everything (like I did for a long time), try rewriting one of your ViewModels with the more appropriate Subject types. You’ll feel the difference quickly.

How I Automated Ubuntu Server Hardening with One Script

Tesleem Amuda — Fri, 31 Jul 2026 00:51:54 +0000

Securing and Automating a Cloud Server

The first time I spun up a cloud server, I thought the hard part was over. It wasn't. The server was open to the world: root login enabled, port 22 broadcasting itself to every scanner on the internet, no firewall, and no certificate.

I checked /var/log/auth.log a few hours later and found hundreds of failed login attempts. That was the moment I understood why SSH hardening isn't optional.

Why SSH Hardening Matters

SSH is the front door to your server. By default, that door is wide open: port 22, password authentication allowed, and root login permitted. Automated bots scan millions of IP addresses every hour looking for exactly this.

Hardening SSH means closing that gap before anything else touches the server:

Disable root login: PermitRootLogin no
Disable password authentication and use keys only: PasswordAuthentication no
Move SSH off port 22—I use port 2247
Restrict login to one user: AllowUsers deploy
Disconnect idle sessions after 10 minutes:
- ClientAliveInterval 300
- ClientAliveCountMax 2

These five changes eliminate the vast majority of automated attacks. You're not invisible, but you're no longer an easy target.

What UFW Does

UFW—Uncomplicated Firewall—is Ubuntu's approachable interface to iptables. Rather than writing low-level rules, you express intent:

ufw default deny incoming
ufw default allow outgoing

ufw allow 2247/tcp   # SSH on custom port
ufw allow 80/tcp     # HTTP
ufw allow 443/tcp    # HTTPS

ufw --force enable

Everything not explicitly allowed is blocked. That's the principle of least privilege applied to networking, and it's the same principle that governs good Kubernetes NetworkPolicies, IAM roles, and RBAC.

Start learning it here.

How Let's Encrypt Works

Let's Encrypt is a free, automated Certificate Authority trusted by major browsers. The flow is straightforward:

You point a domain at your server's IP address.
Certbot serves a challenge file over HTTP to prove that you control the domain.
Let's Encrypt issues a certificate valid for 90 days.
Certbot rewrites your Nginx configuration to serve HTTPS and redirect HTTP automatically.
A scheduled task renews the certificate before it expires—no manual work needed.

The result is a free, automatically maintained HTTPS website.

The following command confirms that the renewal pipeline works without modifying your live certificate:

certbot renew --dry-run

What Idempotency Means—and Why It Matters

Idempotent means that running the same operation twice produces the same result as running it once.

It sounds academic. It isn't.

In practice, it means:

If deploy already exists, skip it instead of returning an error.
If the certificate already exists, skip it instead of requesting a duplicate.
If packages are already installed, apt-get handles them gracefully.

Without idempotency, rerunning a setup script after a partial failure could lock you out of your own server. With it, you can run the script confidently after any interruption.

This habit carries forward into Ansible, Terraform, and every automation tool you'll use at a professional level.

The Script

The complete script is available here:

github.com/tesddev/server-bootstrap

On a fresh Ubuntu 22.04 server, one command does everything:

sudo bash setup.sh

In order, the script:

Updates the system and installs essential packages.
Creates a non-root deploy user and copies in the SSH key.
Hardens SSH by changing the port, disabling root login and password authentication, and setting an idle timeout.
Configures UFW with an explicit allowlist.
Installs Nginx and serves a custom page.
Obtains a Let's Encrypt certificate using Certbot.

What You Get at the End

SSH restricted to key authentication on a non-standard port
A firewall permitting only necessary traffic
A live website at https://tes-devops.duckdns.org with a valid, automatically renewing certificate
A script you can run on any new server today or six months from now

The Real Lesson

Manual server setup doesn't scale, and more importantly, it doesn't reproduce reliably. The same steps performed by two different people on two different days will produce two subtly different servers.

Scripts don't have that problem.

Writing small, idempotent automation scripts is one of the most transferable habits in DevOps. Everything that follows—Ansible playbooks, Terraform modules, and Kubernetes manifests—is this same idea applied at a larger scale.

➡️ View the server-bootstrap repository on GitHub

Automated User Management with Bash Script

Tesleem Amuda — Mon, 01 Jul 2024 15:36:41 +0000

Managing user accounts in a Linux environment can be tedious, especially when dealing with a large number of new employees. To simplify this process, we can use a Bash script to automate user and group creation, ensuring appropriate permissions and logging. Below is a detailed breakdown of a Bash script that accomplishes this.

Script Overview

The script reads a text file containing usernames and group names, creates users and groups as specified, sets up home directories with appropriate permissions and ownership, generates random passwords for the users, and logs all actions to /var/log/user_management.log. It also securely stores the generated passwords in /var/secure/user_passwords.txt.

Script Breakdown

#!/bin/bash

# Check if the input file is provided
if [ $# -eq 0 ]; then
    echo "Usage: $0 <user_list_file>"
    exit 1
fi

user_list_file="$1"

# Log and password file paths
log_file="/var/log/user_management.log"
password_file="/var/secure/user_passwords.txt"

# Create the necessary directories and set permissions
mkdir -p /var/log
mkdir -p /var/secure
touch "$log_file"
touch "$password_file"
chmod 600 "$password_file"

Input File Check: The script starts by ensuring that an input file is provided. This file should contain the list of users to be managed.
Directory and File Setup: It creates directories and files necessary for logging and storing passwords. Permissions are set to ensure security.

# Function to log actions
log_action() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> "$log_file"
}

Logging Function: A function log_action is defined to log each action taken by the script. This helps in auditing and troubleshooting.

# Read the user list file
while IFS=';' read -r username groups; do
    # Remove whitespace
    username=$(echo "$username" | xargs)
    groups=$(echo "$groups" | xargs)

Reading the User List: The script reads each line from the input file, expecting a username and groups separated by a semicolon. Whitespace is trimmed to ensure clean data.

    # Ensure all specified groups exist
    for group in $(echo "$groups" | tr ',' ' '); do
        if ! getent group "$group" >/dev/null; then
            groupadd "$group"
            if [ $? -eq 0 ]; then
                log_action "Created group $group"
            else
                log_action "Failed to create group $group"
                continue
            fi
        else
            log_action "Group $group already exists"
        fi
    done

Group Management: The script checks if each specified group exists and creates it if it doesn't. Actions are logged accordingly.

    # Create the personal group
    if ! getent group "$username" >/dev/null; then
        groupadd "$username"
        if [ $? -eq 0 ]; then
            log_action "Created group $username"
        else
            log_action "Failed to create group $username"
            continue
        fi
    else
        log_action "Group $username already exists"
    fi

Personal Group Creation: For each user, a personal group with the same name is created if it doesn't already exist.

    # Create the user with the personal group
    if ! id -u "$username" >/dev/null 2>&1; then
        useradd -m -g "$username" -s /bin/bash "$username"
        if [ $? -eq 0 ]; then
            log_action "Created user $username with personal group $username"

User Creation: If the user doesn't already exist, the script creates the user account, assigns the personal group, and sets the default shell to bash.

            # Set the user's additional groups
            if [ -n "$groups" ]; then
                usermod -aG "$groups" "$username"
                if [ $? -eq 0 ]; then
                    log_action "Added user $username to groups $groups"
                else
                    log_action "Failed to add user $username to groups $groups"
                fi
            fi

            # Generate a random password
            password=$(openssl rand -base64 12)
            echo "$username:$password" | chpasswd
            if [ $? -eq 0 ]; then
                log_action "Set password for user $username"
            else
                log_action "Failed to set password for user $username"
            fi

            # Save the password securely
            echo "$username,$password" >> "$password_file"
        else
            log_action "Failed to create user $username"
        fi
    else
        log_action "User $username already exists"
    fi

Additional Group Assignment: If additional groups are specified, the user is added to these groups.
Password Management: A random password is generated and set for the user. The password is stored securely in a file with restricted permissions.

    # Set home directory permissions
    chmod 700 "/home/$username"
    chown "$username:$username" "/home/$username"
    log_action "Set permissions for /home/$username"
done < "$user_list_file"

log_action "Script execution completed."

Home Directory Permissions: The script sets strict permissions on the user's home directory to ensure privacy and security.

Key Features

Group Creation: Ensures all specified groups exist before assigning users to them, preventing errors and ensuring proper group membership.
User Creation: Creates users with personal groups and sets up their home directories with appropriate permissions.
Password Generation: Generates random, secure passwords for new users and stores them securely.
Logging: Logs all actions to a log file for audit purposes and troubleshooting.

Conclusion

This script is a robust solution for managing user accounts in a Linux environment. By automating the creation and management of users and groups, it saves time and reduces the potential for errors.