Forem: Sitota Alemu

Using dev-notify-bridge to Get Desktop Notifications from Docker or Remote Environments

Sitota Alemu — Mon, 13 Oct 2025 12:08:57 +0000

Using dev-notify-bridge to Get Desktop Notifications from Docker, WSL, or Remote Environments

Instantly see OTPs, build results, and app notifications — even from inside Docker or WSL.

When running Node.js apps in Docker, WSL, or remote environments, desktop notifications simply don’t work. Your app can’t access the host system’s notification center — meaning no popups for build completions, test results, or verification codes.

This is especially frustrating during local authentication testing, when you need to check OTPs or verification codes sent by their app. Instead of instantly seeing the code, you often switch between tools like Mailtrap or database viewers — an unnecessary delay that breaks development flow.

dev-notify-bridge solves this problem by acting as a local HTTP listener on your host machine. Any containerized or remote app can send a POST request to it, and the bridge instantly triggers a native desktop notification on your computer.

It’s lightweight, cross-platform, and designed purely for local development, making it perfect for things like:

OTP and verification code previews
Build complete or test result notifications
Background job or deployment status updates

Install

Install globally:

npm install -g dev-notify-bridge

Or just run it on the fly:

npx dev-notify-bridge

By default, it listens on port 6789.

Run the bridge

Start the bridge on your host machine:

npx dev-notify-bridge

To change the port:

npx dev-notify-bridge --port 5454

You’ll see a message like:

 [ dev-notify-bridge ] running at http://localhost:5454

That means it’s ready to receive notification requests.

Sending notifications from a container or remote app

Once the bridge is running locally, your Docker container or remote service can send a POST request to it.

When using a single container

If you’re running your app using docker run, add the following flag so your container can reach the host machine:

--add-host=host.docker.internal:host-gateway

Then send a POST request from inside your container:

curl -X POST http://host.docker.internal:5454/notify \
  -H "Content-Type: application/json" \
  -d '{"title": "Build Complete", "message": "Your backend is ready", "sound": true}'

You should instantly see a desktop notification pop up.

When using Docker Compose

If you’re running multiple services through docker-compose, make sure each service that needs to send notifications includes an extra_hosts entry:

services:
  my-api:
    build: .
    extra_hosts:
      - "host.docker.internal:host-gateway"

This ensures the container can resolve host.docker.internal correctly, especially on Linux systems.

On macOS and Windows, Docker Desktop already provides host.docker.internal by default,
but keeping this config ensures your setup stays portable across all platforms.

So whether your team is using Linux, macOS, or Windows — notifications will just work.

Example with JavaScript

Here’s how you can trigger a notification from your app code:

import axios from 'axios';

await axios.post('http://host.docker.internal:5454/notify', {
  title: 'Server Started',
  message: 'API is running on port 3000',
  sound: true
});

Common issues

No notification appears
Check that notifications are enabled on your system and that you’re not in “Do Not Disturb” mode.
On Linux, make sure the notify-send utility is installed.

DNS not resolving (Linux users)
If you get ENOTFOUND host.docker.internal, add the flag
--add-host=host.docker.internal:host-gateway (for single containers)
or use the extra_hosts section (for Docker Compose).

Port already in use
You can change the port using --port, e.g. npx dev-notify-bridge --port 6000.

Why use it

dev-notify-bridge exists to make your development flow smoother.
No need to tail logs or wait for builds — get instant, native desktop notifications from apps running anywhere, even in isolated environments.

It’s tiny, fast, cross-platform, and takes just one command to start.

Quick Docker Setup Examples

Below are minimal examples to get you started, whether you’re using a single container or a multi-service setup.

Single Container (e.g. development API)

docker run -d \
  --name my-api \
  --add-host=host.docker.internal:host-gateway \
  -e NODE_ENV=development \
  -p 3000:3000 \
  my-api-image

Then, inside your app:

await axios.post('http://host.docker.internal:5454/notify', {
  title: 'Build Complete',
  message: 'API container is up',
});

Multi-Service (docker-compose.yml)

version: '3.9'
services:
  service-name:
    build: .
    volumes:
      - .:/usr/src/app
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      NODE_ENV: development
    command: npm run dev

Once your services are running, any container can send notifications to the bridge running on your host system.

That’s all it takes.

Run dev-notify-bridge once on your host machine, and your Docker or remote apps can instantly trigger native desktop notifications — no extra setup, no manual checking.

No more switching to Mailtrap or database tools just to read an OTP.
No more tailing logs to see if a build finished.
Just instant feedback, right where you need it — on your desktop.

It’s small, fast, and made to keep developers in flow, even when code runs in isolated environments.

The Right Way to Handle 404s in Angular SPAs with Nginx

Sitota Alemu — Thu, 09 Oct 2025 19:39:46 +0000

Modern Angular and other single-page applications (SPAs) often break one of the web’s oldest conventions — returning the correct HTTP status code.

When every route, valid or not, serves index.html, even a nonexistent page returns 200 OK.

This confuses search engines and creates “soft 404” issues that hurt your site’s SEO.

This article walks through how to correctly configure Nginx to serve Angular SPAs with real 404 responses, without breaking client-side routing.

You’ll learn how to map valid routes, handle unknown paths gracefully, and still show Angular’s 404 component — all while keeping accurate HTTP responses for crawlers and analytics tools.

By the end, you’ll have a clean, production-ready setup where /nonexistent returns a true 404 Not Found, and Angular displays its own custom 404 view.

The Problem

By default, SPAs rely on client-side routing.
That means the web server always serves index.html, regardless of the URL.

For example:

/ → Home page ✅
/about → About page ✅
/random-nonexistent-page → Angular’s 404 component ✅

It works fine for users, but there’s a hidden issue — the HTTP response is always 200 OK, even for routes that don’t exist.

GET /random-nonexistent-page
HTTP/1.1 200 OK

Search engines interpret this as a soft 404, meaning the page doesn’t exist but the server claims it does.
This can confuse crawlers, waste crawl budget, and reduce your site’s ranking quality.

The Goal

We want Nginx to handle SPAs correctly by:

Serving Angular normally for valid routes with HTTP 200.
Returning HTTP 404 for invalid routes, while still showing Angular’s 404 component.
Keeping static assets and caching behavior unchanged.

Step 1: Define Valid Routes in Nginx

We can define which routes are valid using Nginx’s map directive.
This creates a variable that indicates whether a request path is known or not.

map $request_uri $is_valid_route {
    default 0;
    / 1;
    /products 1;
    /profile 1;
    ~^/orders/[0-9]+$ 1; # Dynamic route
}

1 → valid route (serve SPA and return 200)
0 → invalid route (return 404)

Every time you add a new route to Angular, update this list to match.
For dynamic routes, you can use regular expressions.

Step 2: Use `$is_valid_route` in the Main Location Block

Next, we use that variable to control how requests are handled:

location / {
    if ($is_valid_route = 0) {
        return 404;
    }
    try_files $uri $uri/ /index.html;
}

This tells Nginx:

If the route isn’t valid, return 404 immediately.
Otherwise, serve the requested file or fall back to index.html for Angular routing.

This ensures that only valid routes return 200 OK.

Step 3: Serve Angular’s 404 Component with a Real 404 Status

The challenge is that we don’t want to show Nginx’s default “Not Found” page.
We still want Angular’s 404 component to appear — but the HTTP response must stay 404.

To do this, use the following configuration:

error_page 404 /index.html;

location = /index.html {
    root /usr/share/nginx/html/customer;
    expires -1;
    add_header Pragma "no-cache";
    add_header Cache-Control "no-store, no-cache, must-revalidate";
}

Here’s what happens:

When Nginx encounters a 404, it internally rewrites the request to index.html.
Angular bootstraps as usual and uses the current URL to decide which route to show.
The server response remains HTTP 404, not 200. This is the key: Angular still renders the 404 page, but Nginx reports the truth.

This way, users see your app’s 404 view, and crawlers see the correct status code.

Step 4: The Final Result

URL	HTTP Status	Angular View
`/`	200	Home
`/products`	200	Products
`/orders/123`	200	Order details
`/nonexistent`	404	Angular 404 page

The routing experience remains seamless for users, and your SEO health stays intact.

Step 5: Practical Tips

Always update the Nginx route map when you introduce new Angular routes.
Use regex for dynamic paths (e.g., /orders/:id).
Test responses locally before deploying:

  curl -I http://localhost/nonexistent

You should see:

  HTTP/1.1 404 Not Found

Confirm that your app’s 404 component is configured for Angular’s wildcard route (path: '**').

Conclusion

This setup provides a clean balance between user experience and technical correctness.

You get:

Accurate HTTP responses for crawlers and analytics
Consistent routing behavior for users
Full control over caching and assets

With $is_valid_route and error_page 404 /index.html, your Angular SPA stays SEO-friendly, predictable, and production-ready — all without the complexity of SSR.

Have you handled SPA 404s differently?

Share your setup or tweaks in the comments — I’d love to compare notes!

Understanding Asynchronous I/O Operations in Node.js

Sitota Alemu — Mon, 27 Jan 2025 11:22:52 +0000

Understanding how Node.js handles asynchronous I/O operations is vital for anyone interested in building applications with Node.js. Often, this concept is raised in interviews. So, in this post, I’ll be sharing an overview of how Node.js handles asynchronous tasks.
Before reading this post, it’s assumed that you have a basic understanding of event loops and other fundamental Node.js concepts.

Overview of Asynchronous I/O Process
Asynchronous Function ➔ Call Stack ➔ Delegating I/O to
System APIs ➔ Callback Queue ➔ Event Loop ➔ Call Stack

When asynchronous code is encountered (e.g., fetching data from a database, reading files, etc.), the call stack, event loop, and Node.js’s underlying APIs (like Libuv ) work together to handle it. The process involves delegating the asynchronous task to the appropriate background thread or system API. Let’s explore this in detail.

Here's a Breakdown
1. Asynchronous Function Call When an asynchronous function (e.g., a database query) is called, it is pushed onto the call stack like any other function.
2. Delegation to Background APIs If the function involves I/O (e.g., querying a database, reading a file, or making a network request), Node.js delegates this task to the appropriate system-level API or thread in the background (e.g., Libuv thread pool or database driver). The function is immediately popped off the call stack once the task is delegated, allowing the stack to continue processing other code.
3. Background Processing The actual I/O operation (e.g., querying the database) happens in the background. This is managed outside the JavaScript runtime by the underlying Libuv library, which handles threads and system resources.
4. Callback Queuing Once the asynchronous task completes (e.g., the database query finishes), the result is passed to the callback associated with the operation. The callback is placed into an appropriate queue (e.g., the I/O callback queue) for the event loop to process.
5. Event Loop Execution The event loop continuously checks if the call stack is empty. If it is, it takes the next task from the queue (i.e., the callback) and pushes it onto the call stack for execution.

In a nutshell, an asynchronous I/O operation can be summarized in the following steps:
1. Asynchronous Function Call:
◦ When an asynchronous function (e.g., a database query) is called, it is pushed onto the call stack like any other function.
2. Delegation to Background APIs:
◦ Since the function involves I/O (e.g., querying a database, reading a file, or making a network request), Node.js delegates this task to the appropriate system-level API or thread in the background (e.g., Libuv thread pool or database driver).
◦ The function is immediately popped off the call stack once the task is delegated, allowing the stack to continue processing other code.
3. Background Processing:
◦ The actual I/O operation happens in the background, managed by Libuv or other underlying libraries.
4. Callback Queuing:
◦ Once the asynchronous task completes, the callback is placed into the appropriate queue for the event loop to process.
5. Event Loop Execution:
◦ The event loop checks if the call stack is empty. If it is, it picks the next callback from the queue and pushes it onto the call stack for execution.

Thanks for reading! I’ll be writing about the event loop and its phases in an upcoming post. If you have any thoughts, questions, or feedback, don’t hesitate to leave them in the comments. I’d love to hear from you!

What the Heck is Docker?

Sitota Alemu — Mon, 02 Dec 2024 08:26:12 +0000

"What's Docker? What's a container? What's an image? Bla bla bla..." These are the questions my colleagues always ask me when they start learning Docker. And, to be honest, I asked the same questions when I was first introduced to it.

But you know what? Answers like, "Docker is a platform where..." didn’t really satisfy me. Sure, those answers are correct, but they didn't help me understand Docker. I had deeper questions like:

Why should I use Docker?
What’s containerization exactly?
How is it different from virtualization?

If you’re like me, these are the questions that matter. So, let’s break it down together.

Is "What’s Docker?" the Right Question?

Yes, it’s a valid question. But here’s the catch: the answer to "What’s Docker?" is just the tip of the iceberg. If you ask someone this, they’ll probably say:

"Docker is a platform for developing, shipping, and running applications in containers."

Cool, but... what does that even mean?

To really understand Docker, you need to ask a better question: "What is containerization?"

What’s Containerization?

Here’s a textbook definition:

"Containerization is the process of packaging an application, along with its dependencies (libraries, configuration files, and binaries), into a lightweight, portable, and consistent unit called a container."

Sounds fancy, right? But does it really help you visualize what containerization is? Probably not. Let’s dig deeper.

Concepts You Need to Know to Understand Containerization

Before approaching containerization, you need to understand some core concepts. Without these, Docker and containers might feel like magic. Here’s what you should explore first:

The Software Deployment Process Think about how applications are traditionally deployed. In the "pre-container" world:
- You write code on your local machine.
- Then, you configure it to work on a server.
- But wait! The server needs specific versions of libraries, dependencies, and tools to run your app.
- Uh-oh, it works on your local machine but crashes in production because the environments aren’t identical.

This is the classic "It works on my machine!" problem. Containerization solves this by ensuring that your application and its dependencies are bundled into a single, portable unit (the container) that can run anywhere.

Virtualization

To understand containers, you need to understand how virtualization works:
- Virtual Machines (VMs): These are like mini-computers running inside your actual computer. They emulate an entire operating system (OS) and are great for isolating applications.
- Containers: Unlike VMs, containers don’t emulate an entire OS. Instead, they share the host OS's kernel while isolating your application and its dependencies. This makes containers much lighter and faster than VMs.
Containerization

Now that you understand virtualization( of course just a tip of it, dig deep into it for more understanding), you can appreciate what containerization does:
- It isolates your application, just like a VM.
- It’s lightweight and portable, unlike a VM.
- It ensures consistency across development, staging, and production environments.

How Docker Fits Into the Picture

Docker is the tool that makes containerization easy. It provides:

A way to create containers (using Docker images).
A way to share containers (via Docker Hub or private registries).
A way to run containers (on your local machine, servers, or even in the cloud).

So in simple terms: Docker makes containerization accessible to everyone.

If you want to understand Docker, start by understanding containerization. And if you want to understand containerization, take some time to learn about software deployment and virtualization first. Once you’ve got the basics down, Docker (and all its buzzwords like "containers" and "images") will start to make sense.

Resources that helped me

I couldn't remember all the resources that helped me, but here are some of them(None of the links are affiliated):

A course on Edx: Introduction to containers, Kubernets and OpenShift
Fireship (YouTube) - Docker 101

Thanks for reading!

Next.js with Docker setup error fixed

Sitota Alemu — Mon, 07 Oct 2024 06:34:01 +0000

What I faced

Hey guys, I was Setting up Next.js with Docker and I had faced several issues. One of the errors was docker couldn't able to load ld-linux-x86-64.so.2.

⚠ Attempted to load @next/swc-linux-x64-gnu, but an error occurred: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /src/node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node)

Solution

The missing file ld-linux-x86-64.so.2 is part of glibc and some base images like alpine based one's doesn't include. This is a simplest error which is related to the docker image I was using. So I switched to Debian based Image and it worked.

Sources

The following youtube video helped me in the process of setting up.
link

That's it, thank you guys. Since I am in a hurry, I haven't articulated it well, might edit later.