<p>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?</p>
<figure><img alt="Github Copilot" src="https://cdn-images-1.medium.com/max/347/1*mxinSu8161nx_pa91uf8_Q.jpeg"><figcaption>GitHub Copilot…</figcaption></figure><p>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).</p>
<p>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.</p>

Github Copilot — Developer's other half.

<p>I'm currently building <strong>SelloHQ</strong> (<a href="https://sellohq.com" target="_blank" rel="noopener">sellohq.com</a>), a business management platform that lets a business owner run their whole operation — catalog, inventory, and orders — from one dashboard. The idea came from watching how small businesses across Africa actually sell: not through a storefront, but through a flood of WhatsApp messages, SMS, and phone calls that someone has to manually turn into an order, a stock deduction, and eventually a payment. SelloHQ's bet is that this conversion — <strong>conversation to order</strong> — is exactly the kind of repetitive, structured task an AI agent should be doing, not a person.</p>

<h3>The core loop</h3>
<p>A business connects a WhatsApp Business number and/or an SMS or voice line to their SelloHQ account. From that point on, every inbound message is a potential order. An AI agent sits on that channel, reads the conversation, matches it against the business's actual product catalog, and drafts a structured order directly onto the owner's dashboard — items, quantities, customer details — without the owner touching a spreadsheet or a notebook. Once the order is confirmed, SelloHQ generates a <strong>Paystack virtual account</strong> for that specific order, and when the webhook fires, the payment is marked paid automatically. The owner's job shrinks to reviewing what the agent drafted and fulfilling it.</p>

<h3>Why multi-tenancy shapes almost every decision</h3>
<p>SelloHQ is multi-tenant from the schema up: every row that belongs to a business — products, inventory movements, customers, orders, channel connections, conversations — carries a <code>businessId</code>, and the service layer scopes every query to the authenticated tenant. That sounds obvious written down, but it has real consequences once an AI agent is in the loop: the agent's tool calls (look up a product, check stock, create an order) have to be scoped exactly the same way a human request would be, or you risk one business's agent drafting orders against another business's catalog. Tenant isolation isn't just a database concern here, it's a constraint on how the agent's tools are designed.</p>

<h3>Modeling a conversation as a first-class thing</h3>
<p>Orders carry a <code>source</code> — <code>DASHBOARD</code>, <code>WHATSAPP</code>, <code>SMS</code>, or <code>VOICE</code> — so the business owner can always see where a sale actually came from, and the underlying <code>Conversation</code> and <code>Message</code> models keep the full channel thread the order was drafted from. That thread does double duty: it's the audit trail an owner can check if an order looks wrong, and it's the session/context store the agent reads from on every new inbound message so it isn't reasoning from scratch each time. That context lives in <strong>Redis</strong>, separate from Postgres, which is the source of truth for the business data itself — a split that keeps the fast-changing, ephemeral conversation state out of the durable domain tables.</p>

<pre><code>Business        — tenant root (currency, country, Paystack config)
User            — owner / admin / staff per business
Product         + InventoryMovement — catalog & stock ledger
Customer
Order           + OrderItem — source: DASHBOARD | WHATSAPP | SMS | VOICE
Payment         — Paystack virtual account + status
ChannelConnection — WhatsApp / SMS / Voice config per business
Conversation    + Message — channel threads the AI agent reads/writes</code></pre>

<h3>Payments as a natural extension of the conversation</h3>
<p>The payment model follows the same philosophy as the ordering model: don't make the customer do anything unfamiliar. Instead of pushing a customer to a checkout page, SelloHQ generates a dedicated <strong>Paystack virtual account</strong> per order — the customer just transfers to it the way they'd pay anyone else. When <code>paymentEnabled</code> is on for a business, the Paystack webhook flips the order's payment status to paid with no manual reconciliation. It's a small design choice, but it matters: everything in the flow, from placing the order over WhatsApp to paying for it, stays inside channels the customer already trusts.</p>

<h3>The stack</h3>
<p>The dashboard is <strong>Next.js 16</strong> (App Router, Turbopack) with <strong>React 19</strong> and Tailwind CSS 4, using brand design tokens rather than default utility colors so the product has a consistent visual identity from day one. The API is <strong>NestJS 11</strong> on TypeScript 5.7, with <strong>Prisma 6</strong> over <strong>PostgreSQL 17</strong> as the domain source of truth, <strong>Redis</strong> for session and conversation context, and MinIO/S3-compatible object storage for product and order images — the same API surface local Docker MinIO exposes in dev is what production talks to, so there's no storage-layer surprise between environments. A React Native mobile app rounds out the picture for owners who want to manage orders on the move. Swagger docs, Helmet, global validation, and rate limiting are baked into the API from the start rather than bolted on later.</p>

<h3>What I've learned so far</h3>
<p>The most interesting engineering problem in SelloHQ hasn't been the AI integration itself — it's been treating the <strong>conversation as domain data</strong> with the same rigor as an order or a product, instead of as a transient log line. Once a thread is a real, tenant-scoped, queryable entity, both the agent and the human owner can reason about it, audit it, and recover from it when something goes wrong. That's the piece I'd tell anyone building an AI-agent-backed product to get right early — it's much harder to retrofit than to design in from the schema up.</p>
<p>SelloHQ is still pre-launch at <a href="https://sellohq.com" target="_blank" rel="noopener">sellohq.com</a>. If you're building something in the AI-agent-meets-commerce space, or run a business that lives in WhatsApp and SMS threads, I'd love to compare notes — reach out through the contact section of this site.</p>

Building SelloHQ: Letting an AI Agent Draft Orders from WhatsApp, SMS & Voice

<p>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 <strong>which layer of the network stack I was actually working at</strong>. 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.</p>

<h3>The problem</h3>
<p>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 <em>why</em> sent me back to basics on how a network request is actually layered.</p>
<p>What pushed me into the investigation was TLS. Both backend services <strong>terminate their own TLS</strong> — each presents its own certificate and completes the handshake itself — and I needed the client's TLS session to reach the backend untouched: <strong>end-to-end TLS</strong>. My instinct was an HTTP (Layer 7) reverse proxy. To be clear, an HTTP proxy <em>can</em> talk to HTTPS backends — nginx terminates the client's TLS and opens a <em>separate</em> TLS connection to the backend with <code>proxy_pass https://backend</code>. But that's TLS <strong>termination and re-encryption at the proxy</strong>, 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 <strong>passthrough where an HTTP proxy gives you termination</strong>. That's what sent me back to basics on how a request is actually layered.</p>

<h3>A request travels through layers</h3>
<p>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:</p>
<ul>
<li><strong>Layer 7 — Application:</strong> HTTP, gRPC, WebSocket. This is where URLs, headers, methods, cookies, and status codes live. To operate here, something has to actually <em>parse the HTTP protocol</em>.</li>
<li><strong>Layer 4 — Transport:</strong> 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><strong>Layer 3 — Network:</strong> IP. Routing packets between addresses across networks.</li>
<li><strong>Layers 2 &amp; 1 — Link &amp; Physical:</strong> MAC addresses, frames, and the actual wire/radio carrying the bits.</li>
</ul>
<p>The key insight: <strong>where you intercept traffic determines what you can see and do with it.</strong> 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.</p>

<h3>nginx works at two different layers</h3>
<p>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:</p>
<ul>
<li>The <code>http {}</code> context is a <strong>Layer 7</strong> 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 <strong>Layer 4</strong> 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>
<p>Round-robin is the default here, so nginx spreads <strong>individual HTTP requests</strong> 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.</p>

<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>
<p>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 <strong>per TCP connection, not per HTTP request</strong>. 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.</p>

<h3>Why I ended up using <code>stream</code> instead of HTTP proxying</h3>
<p>Once I understood the two contexts, the choice was clear. An HTTP-layer proxy would have to <strong>terminate</strong> 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 <strong>connection-level passthrough</strong>: accept each incoming TCP connection and hand the raw bytes to one of the backends, without nginx ever becoming the TLS endpoint.</p>
<p>That's what <code>stream</code> gives you. At Layer 4 nginx forwards the encrypted bytes straight through, so the <strong>TLS handshake is end-to-end between the client and whichever backend the connection lands on</strong>. 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 <strong>per connection rather than per request</strong>, and nginx is blind to everything above TCP — no path routing, no header rewriting, no caching.</p>
<p>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 <strong>I'd been reaching for the wrong layer for the job.</strong></p>

<h3>How to know which layer you want</h3>
<p>A quick heuristic from this experience:</p>
<ul>
<li><strong>Use the HTTP layer (<code>http {}</code>, Layer 7)</strong> 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><strong>Use the TCP/stream layer (<code>stream {}</code>, Layer 4)</strong> 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>
<p>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.</p>

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

<p>I recently built <strong>CaricatureCam</strong>, 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.</p>
<p><strong>👉 Try it live:</strong> <a href="https://caricaturecam.nwanochie.dev/" target="_blank" rel="noopener">caricaturecam.nwanochie.dev</a> (works best in Chrome or Edge — it needs camera access).</p>

<h3>What CaricatureCam does</h3>
<p>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.</p>
<ul>
<li><strong>10 combinable caricature effects</strong>, each with its own intensity slider</li>
<li><strong>30+ FPS</strong> facial landmark detection on a 468-point face mesh</li>
<li><strong>Recording</strong> with pause/resume and one-click download</li>
<li><strong>Photo capture</strong> straight from the canvas</li>
<li><strong>Virtual camera</strong> 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>
<p>CaricatureCam is built with <strong>React 19</strong>, <strong>TypeScript</strong>, <strong>Vite</strong>, and <strong>Tailwind CSS</strong>. The magic behind the face tracking is Google's <strong>MediaPipe Face Landmarker</strong> (<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.</p>

<h3>The rendering pipeline</h3>
<p>Every frame goes through the same loop, driven by <code>requestAnimationFrame</code>:</p>
<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>
<p>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.</p>

<h3>A pluggable effects architecture</h3>
<p>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:</p>
<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>
<p>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.</p>

<h3>Sharing the warp math</h3>
<p>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.</p>

<h3>Recording and the virtual camera</h3>
<p>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.</p>

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

<p>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.</p>