How fascinating it is to start a line of code, and the next line(s) is completed by Artificial Intelligence. How cool does that sound?
<figure><img alt="Github Copilot" src="https://cdn-images-1.medium.com/max/347/1*mxinSu8161nx_pa91uf8_Q.jpeg"><figcaption>GitHub Copilot…</figcaption></figure>Github and Open AI created the Github copilot as a helper and a colleague for every developer. It is powered by GPT-3 and capable of writing code automatically. I discovered Copilot a few months back and it has been wonderful, having it suggest blocks of code has really helped me to speed up the development process. Just write in a descriptive function name or comment and it suggests to you automatically the next block of code(s).
There is this really cool video on youtube by <a href="https://www.youtube.com/watch?v=4duqI8WyfqE">fireship.io</a> that summaries it and also talks about controversies surrounding the copilot.

Github Copilot — Developer's other half.

I recently spent a frustrating afternoon trying to get nginx to round-robin traffic across two backend services. What looked like a five-minute config change turned into a proper rabbit hole — and by the end of it I understood a lot more about which layer of the network stack I was actually working at. This is a write-up of what I learned, because the distinction between proxying at the HTTP layer and load-balancing at the TCP layer is one of those things that's obvious in hindsight but genuinely confusing in the moment.

<h3>The problem</h3>
I had two instances of a service running and I wanted nginx to distribute incoming connections evenly between them — a classic round-robin setup. My first instinct was the thing every nginx tutorial shows you: define an <code>upstream</code> block and <code>proxy_pass</code> to it inside a <code>server</code> block. It seemed right. It wasn't — at least not for what I was doing — and chasing down why sent me back to basics on how a network request is actually layered.
What pushed me into the investigation was TLS. Both backend services terminate their own TLS — each presents its own certificate and completes the handshake itself — and I needed the client's TLS session to reach the backend untouched: end-to-end TLS. My instinct was an HTTP (Layer 7) reverse proxy. To be clear, an HTTP proxy can talk to HTTPS backends — nginx terminates the client's TLS and opens a separate TLS connection to the backend with <code>proxy_pass https://backend</code>. But that's TLS termination and re-encryption at the proxy, not passthrough: nginx becomes the TLS endpoint the client actually talks to, so it needs a certificate for the client-facing name, and the backend's own certificate is no longer what the client sees. For my setup that broke the requirement — I didn't want nginx to be the TLS endpoint at all. The real mismatch wasn't certificates "fighting"; it was that I needed passthrough where an HTTP proxy gives you termination. That's what sent me back to basics on how a request is actually layered.

<h3>A request travels through layers</h3>
When your client talks to a server, the data doesn't go straight across in one piece. It's wrapped and unwrapped through a stack of layers, each responsible for a different concern. The simplified mental model I keep coming back to:
<ul>
<li>Layer 7 — Application: HTTP, gRPC, WebSocket. This is where URLs, headers, methods, cookies, and status codes live. To operate here, something has to actually parse the HTTP protocol.</li>
<li>Layer 4 — Transport: TCP and UDP. This layer only knows about ports, connections, and raw byte streams. It has no idea whether the bytes flowing through are HTTP, a database protocol, or video.</li>
<li>Layer 3 — Network: IP. Routing packets between addresses across networks.</li>
<li>Layers 2 &amp; 1 — Link &amp; Physical: MAC addresses, frames, and the actual wire/radio carrying the bits.</li>
</ul>
The key insight: where you intercept traffic determines what you can see and do with it. A proxy that operates at Layer 7 can read and rewrite headers, route by path, terminate TLS, and inspect the request body — but it pays the cost of fully parsing every request. A load balancer at Layer 4 just shuttles bytes between a client connection and a backend connection. It's faster and protocol-agnostic, but it's blind to anything above TCP.

<h3>nginx works at two different layers</h3>
This is the part that finally made it click for me. nginx has two separate top-level contexts, and they live at different layers of the stack:
<ul>
<li>The <code>http {}</code> context is a Layer 7 reverse proxy. <code>proxy_pass</code> here speaks HTTP — it parses requests, can route by host/path, and manipulate headers.</li>
<li>The <code>stream {}</code> context is a Layer 4 proxy. It load-balances raw TCP/UDP connections without understanding what protocol is inside them.</li>
</ul>

<h4>Round-robin at the HTTP layer (Layer 7)</h4>
<pre><code>http {
 upstream backend {
 server 10.0.0.1:8080;
 server 10.0.0.2:8080;
 }

 server {
 listen 80;
 location / {
 proxy_pass http://backend;
 }
 }
}</code></pre>
Round-robin is the default here, so nginx spreads individual HTTP requests across the servers — even multiple requests sent over the same client connection can land on different backends, because nginx parses each request. This is perfect when your backends speak HTTP and you want HTTP-aware features.

<h4>Round-robin at the TCP layer (Layer 4)</h4>
<pre><code>stream {
 upstream backend {
 server 10.0.0.1:9000;
 server 10.0.0.2:9000;
 }

 server {
 listen 9000;
 proxy_pass backend;
 }
}</code></pre>
Notice there's no <code>location</code> and no <code>http://</code> scheme — at this layer there is no notion of a URL or an HTTP request. nginx accepts a TCP connection and forwards the byte stream to one of the upstreams, round-robin by default. One important nuance: because Layer 4 is connection-oriented, this balances per TCP connection, not per HTTP request. If a client holds a single keep-alive connection open, every request riding that connection goes to the same backend. That's usually fine for connection-level distribution, but it's a genuine difference from Layer 7 — and worth knowing before you reach for it.

<h3>Why I ended up using <code>stream</code> instead of HTTP proxying</h3>
Once I understood the two contexts, the choice was clear. An HTTP-layer proxy would have to terminate the client's TLS and re-encrypt to the backend — perfectly workable in general, but exactly the model I needed to avoid. What I actually wanted was connection-level passthrough: accept each incoming TCP connection and hand the raw bytes to one of the backends, without nginx ever becoming the TLS endpoint.
That's what <code>stream</code> gives you. At Layer 4 nginx forwards the encrypted bytes straight through, so the TLS handshake is end-to-end between the client and whichever backend the connection lands on. Each backend keeps presenting its own certificate directly to the client, and nginx needs no certificate of its own. The tradeoff I accepted in return: balancing is per connection rather than per request, and nginx is blind to everything above TCP — no path routing, no header rewriting, no caching.
By dropping to Layer 4 I got clean per-connection round-robin, lower overhead, and TLS passthrough that matched what the architecture actually required. The lesson wasn't "stream is better than http" — it was that I'd been reaching for the wrong layer for the job.

<h3>How to know which layer you want</h3>
A quick heuristic from this experience:
<ul>
<li>Use the HTTP layer (<code>http {}</code>, Layer 7) when you need per-request balancing, routing by path or host, TLS termination at the proxy, header manipulation, caching, or anything that requires understanding the request.</li>
<li>Use the TCP/stream layer (<code>stream {}</code>, Layer 4) when you need end-to-end TLS passthrough (the backend, not the proxy, is the TLS endpoint), when the protocol isn't HTTP, or when you want minimal overhead and protocol transparency — just remember it balances per connection, not per request.</li>
</ul>
What started as a config headache turned into one of the more useful things I've internalized this year. Network requests are layered for a reason, and a surprising number of "why won't this work" problems are really "I'm operating at the wrong layer" problems in disguise. If you've run into something similar, I'd love to compare notes — reach out through the contact section of this site.

The Layers of a Network Request: nginx stream vs HTTP Proxying

I recently built CaricatureCam, a browser-based app that applies real-time facial caricature effects to your live webcam feed — no installs, no servers, no uploads. Everything runs locally in the browser at 30+ frames per second. In this article I'll walk through how it works, the architecture decisions behind it, and the interesting engineering problems I had to solve along the way.
👉 Try it live: <a href="https://caricaturecam.nwanochie.dev/" target="_blank" rel="noopener">caricaturecam.nwanochie.dev</a> (works best in Chrome or Edge — it needs camera access).

<h3>What CaricatureCam does</h3>
CaricatureCam tracks your face in real time and warps it on the fly: enlarge your nose, give yourself bug eyes, stretch your forehead, or distort your whole face like a funhouse mirror. You can stack multiple effects, tune the intensity of each one with a slider, record the result as a WebM video, snap a PNG photo, and even pipe the processed feed into Zoom or Google Meet through a virtual camera.
<ul>
<li>10 combinable caricature effects, each with its own intensity slider</li>
<li>30+ FPS facial landmark detection on a 468-point face mesh</li>
<li>Recording with pause/resume and one-click download</li>
<li>Photo capture straight from the canvas</li>
<li>Virtual camera output for video calls via OBS</li>
<li>Multi-camera support and a mirrored selfie view by default</li>
</ul>

<h3>The tech stack</h3>
CaricatureCam is built with React 19, TypeScript, Vite, and Tailwind CSS. The magic behind the face tracking is Google's MediaPipe Face Landmarker (<code>@mediapipe/tasks-vision</code>), which gives me a 468-point 3D mesh of the face directly in the browser using WebGL acceleration. The entire pipeline — capture, detect, warp, render — happens client-side, which means the user's video never leaves their machine. That privacy guarantee was a non-negotiable design goal from day one.

<h3>The rendering pipeline</h3>
Every frame goes through the same loop, driven by <code>requestAnimationFrame</code>:
<ol>
<li>Grab the current frame from the <code>&lt;video&gt;</code> element.</li>
<li>Run MediaPipe Face Landmarker to get 468 normalized landmark coordinates.</li>
<li>For each active effect, warp the relevant region of the image on a <code>&lt;canvas&gt;</code>.</li>
<li>Composite and draw the result, then hand it off to the recorder or virtual camera if active.</li>
</ol>
The hard part is doing all of this fast enough that it feels live. Landmark detection is the most expensive step, so the effects themselves have to be cheap. Each warp is implemented as a localized image transform — I sample a region around a set of landmarks and remap pixels outward or inward to exaggerate that feature.

<h3>A pluggable effects architecture</h3>
I didn't want adding a new effect to mean touching the rendering loop, the UI, and the state management. So effects are self-describing modules that conform to a single <code>EffectDescriptor</code> interface:
<pre><code>export const myEffect: EffectDescriptor = {
 id: 'myEffect',
 name: 'My Effect',
 icon: '🎭',
 defaultIntensity: 0.5,
 apply(ctx, landmarks, width, height, intensity, src) {
 // warp the canvas using utility helpers
 },
}</code></pre>
Each effect declares its id, display name, icon, default intensity, and an <code>apply</code> function. A central registry imports them all, and the UI renders controls automatically by iterating over that registry. Adding a new effect is two lines: write the module, add it to the registry. It shows up in the interface with its own slider with zero extra wiring. This kind of registry-driven design keeps the codebase open for extension but closed for modification — new effects never risk breaking existing ones.

<h3>Sharing the warp math</h3>
Most effects boil down to a few primitive operations: warp a circular region around a landmark, stretch a horizontal band of the face, or scale the overall face width. I factored these into reusable helpers (<code>warpRegion</code>, <code>stretchBand</code>, <code>warpFaceWidth</code>) that operate on the mirrored, normalized landmark coordinates. "Big Nose" and "Bug Eyes" are both just <code>warpRegion</code> calls with different landmark sets and signs. That shared foundation is why ten distinct effects amount to surprisingly little code.

<h3>Recording and the virtual camera</h3>
Recording uses the <code>MediaRecorder</code> API pointed at the canvas's <code>captureStream()</code>, writing WebM chunks that get stitched together and offered as a download when the user stops. The virtual camera path leans on OBS: you add the app as a browser source, start OBS's virtual camera, and select it inside Zoom or Meet. It's a pragmatic solution — browsers don't expose a native virtual-camera API yet — but it turns a fun toy into something you can actually show up to a meeting with.

<h3>Lessons learned</h3>
Building CaricatureCam reinforced a few things I keep coming back to as an engineer. First, doing the heavy lifting on the client can be both a performance win and a privacy feature — there's no round trip and no data leaves the device. Second, a good plugin interface pays for itself fast; once the effect contract was stable, experimenting with new distortions became genuinely fun instead of tedious. And third, perceived performance is a feature — keeping the per-frame work lean is what makes the difference between a gimmick and something that feels magical.

CaricatureCam is part of my ongoing exploration of real-time computer vision and creative tooling on the web. If you're curious about on-device ML, MediaPipe, or building extensible front-end architectures, I'd love to chat — try the <a href="https://caricaturecam.nwanochie.dev/" target="_blank" rel="noopener">live demo</a> or reach out through the contact section of this site.

Building CaricatureCam: Real-Time Face Warping in the Browser

<figure><img alt="" src="https://cdn-images-1.medium.com/max/474/1*_z6ZZtYrBvYZ0xtzx5XXaA.jpeg"></figure><h3>Introduction</h3>
Managing users on a Linux system can be a repetitive and error-prone task, especially when dealing with a large number of users. Automating this process with a bash script can save time and reduce the risk of mistakes. In this article, we’ll walk through a bash script that reads a text file containing usernames and group names, creates users and groups, sets up home directories, generates random passwords, logs actions, and stores passwords securely.
Refer to this <a href="https://github.com/nwanoch/Linux-User-Creation-Script">github repository</a> to get a hold of the script and this was inspired by <a href="https://hng.tech/internship">hng intership</a>
Script Breakdown:
<ol><li>Input Validation and Initialization</li></ol>
<pre>#!/bin/bash # Check if the script is executed with a file argument if [ $# -eq 0 ]; then echo "Usage: $0 &lt;filename&gt;" exit 1 fi input_file=$1 log_file="/var/log/user_management.log" password_file="/var/secure/user_passwords.txt"</pre>
Purpose: Validates that the script is called with an input file argument and initializes variables.
Function:
<ul>
<li>Uses #!/bin/bash to indicate this script should be executed using Bash.</li>
<li>Checks if the script is provided with an argument ($# checks the number of arguments).</li>
<li>Prints a usage message and exits if no argument is provided.</li>
<li>Sets input_file, log_file, and password_file variables based on the provided argument and predetermined file paths.</li>
</ul>
2. Password Generation Function
<pre># Function to generate a random password generate_password() { openssl rand -base64 12 | tr -d '/+=' | cut -c1-12 }</pre>
Purpose: Defines a function to generate a random password.
Function:
<ul>
<li>Uses openssl rand -base64 12 to generate a random 12-character base64-encoded string.</li>
<li>tr -d '/+=' removes characters that may not be suitable for passwords.</li>
<li>cut -c1-12 ensures the password length is exactly 12 characters.</li>
</ul>
3. Main Processing Loop
<pre># Loop through each line in the input file while IFS=';' read -r username groups; do # Remove leading/trailing whitespace username=$(echo "$username" | tr -d '[:space:]') groups=$(echo "$groups" | tr -d '[:space:]') # Check if the user already exists if id "$username" &amp;&gt;/dev/null; then echo "User $username already exists. Skipping." echo "$(date) - User $username already exists. Skipping." &gt;&gt; "$log_file" continue fi # Create the user useradd -m -s /bin/bash "$username" # Create groups if they don't exist and add the user to groups IFS=',' read -ra user_groups &lt;&lt;&lt; "$groups" for group in "${user_groups[@]}"; do if ! grep -q "^$group:" /etc/group; then groupadd "$group" fi usermod -aG "$group" "$username" done # Generate a password password=$(generate_password) # Set the password for the user echo "$username:$password" | chpasswd # Log actions echo "$(date) - Created user $username with groups $groups." &gt;&gt; "$log_file" # Store passwords securely echo "$username,$password" &gt;&gt; "$password_file" # Ensure home directory permissions chown -R "$username:$username" "/home/$username" chmod 700 "/home/$username" done &lt; "$input_file"</pre>
Purpose: Processes each line in the input file (users.txt) to create users, assign them to groups, generate passwords, log actions, and store passwords securely.
Function:
<ul>
<li>Uses while IFS=';' read -r username groups; do to read each line, splitting by ; into username and groups.</li>
<li>Removes any leading/trailing whitespace from username and groups.</li>
<li>Checks if the user already exists using id "$username" &amp;&gt;/dev/null.</li>
<li>Creates the user with useradd -m -s /bin/bash "$username".</li>
<li>Creates specified groups if they don’t exist and adds the user to each group.</li>
<li>Generates a password using the generate_password function.</li>
<li>Sets the generated password for the user using echo "$username:$password" | chpasswd.</li>
<li>Logs the creation action with timestamp to $log_file.</li>
<li>Stores the username and password securely in $password_file.</li>
<li>Ensures correct permissions on the user’s home directory (/home/$username)</li>
</ul>
4. Script Completion
<pre>echo "User creation process complete."</pre>
Purpose: Indicates the completion of the script’s execution.
Function: Prints a message to the terminal indicating that the user creation process has finished.
<h3>Summary</h3>
This script automates the creation of user accounts on a Linux system based on input provided in a text file (users.txt). It handles user and group creation, generates secure passwords, logs actions to /var/log/user_management.log, and stores passwords securely in /var/secure/user_passwords.txt. The script ensures correct permissions on user home directories and provides feedback throughout its execution. Adjustments and enhancements can be made based on specific requirements or additional functionality needed.