Bruno ist ein leichter, Git-nativer Open-Source-API-Client. Er eignet sich gut, um Requests als Dateien zu versionieren, Requests auszuführen und Tests zu schreiben. Was Bruno nicht liefert: einen integrierten Mock-Server für Endpunkte, die noch nicht existieren. Wenn Sie einen Bruno-Mock-Server suchen, brauchen Sie daher entweder ein externes Tool, einen selbst geschriebenen Stub-Server oder einen spezifikationsgesteuerten Mock aus Ihrer OpenAPI-Datei.

Apidog noch heute ausprobieren

Kurz gesagt: Bruno kann Anfragen senden und Assertions ausführen, aber keine gefälschten Endpunkte bereitstellen, die Beispielantworten zurückgeben. Für Mocking müssen Sie den Mock außerhalb von Bruno betreiben.

Warum Sie einen Mock-Server benötigen

Ein Mock-Server liefert definierte Antworten für API-Endpunkte, die noch nicht implementiert, instabil oder schwer reproduzierbar sind. Das ist besonders nützlich für:

• Parallele Entwicklung: Frontend-, Mobile- und Backend-Teams arbeiten gegen denselben API-Vertrag.
• Fehlerpfad-Tests: Sie können gezielt 429, 500, 503 oder fehlerhafte Payloads auslösen.
• Demos und Prototypen: Workflows funktionieren ohne Live-Backend, Datenbank oder Zugangsdaten.
• Stabile CI: Tests hängen nicht von Staging-Ausfällen, Rate Limits oder instabilen Testdaten ab.

Typische Szenarien:

Hat Bruno einen Mock-Server?

Nein. Bruno konzentriert sich auf:

• Requests senden
• Collections als einfache Dateien organisieren
• Tests und Assertions ausführen
• API-Workflows Git-nativ verwalten

Es gibt aber keine native Funktion, die eine gespeicherte Anfrage in einen laufenden Stub-Endpunkt verwandelt.

In der Praxis nutzen Bruno-Teams meist eine dieser zwei Optionen:

1. Externes Mocking-Tool verwenden

   Zum Beispiel Mockoon, WireMock, Prism oder json-server. Sie definieren dort die Antworten und verweisen Bruno auf die Mock-URL.

2. Eigenen Stub-Server schreiben

   Zum Beispiel mit Express, Flask oder FastAPI. Das ist für wenige Endpunkte schnell, wird bei wachsender API aber pflegeintensiv.

Beide Wege funktionieren. Beide bedeuten aber auch: Der Mock lebt außerhalb Ihrer Bruno-Collection.

Beispiel: Minimaler Stub-Server mit Express

Wenn Sie nur einen schnellen lokalen Mock brauchen, reicht ein kleiner Express-Server:

import express from "express";

const app = express();
app.use(express.json());

app.get("/users/:id", (req, res) => {
  res.json({
    id: req.params.id,
    name: "Max Mustermann",
    email: "max@example.com",
    created_at: new Date().toISOString()
  });
});

app.get("/rate-limit", (req, res) => {
  res.set("Retry-After", "60");
  res.status(429).json({
    error: "Too Many Requests"
  });
});

app.listen(3000, () => {
  console.log("Mock server running at http://localhost:3000");
});

Danach können Sie in Bruno gegen diese URL testen:

GET http://localhost:3000/users/123

Das ist praktisch für kleine Tests. Der Nachteil: Sobald sich Ihre API-Spezifikation ändert, müssen Sie den Stub manuell aktualisieren.

Die Kosten von nachträglich hinzugefügtem Mocking

Eine separate Mock-Schicht ist machbar, erzeugt aber schnell Reibung:

• Drift: Spezifikation, Bruno-Requests und Mock-Definitionen liegen an verschiedenen Stellen.
• Setup-Aufwand: Neue Teammitglieder müssen zusätzlich ein Mocking-Tool installieren und konfigurieren.
• Manuelle Payloads: Beispielantworten für Felder, Statuscodes und Edge Cases müssen gepflegt werden.
• Statische Daten: Einfache Stubs geben oft immer dieselbe Antwort zurück und verdecken dadurch Fehler.

Wenn ein Endpunkt geändert wird, müssen Sie typischerweise mehrere Artefakte aktualisieren:

OpenAPI-Spezifikation
        ↓
Bruno-Request
        ↓
Externer Mock / Stub-Server

Vergessen Sie eine Stelle, testen Sie gegen veraltetes Verhalten.

Eine detailliertere Einordnung finden Sie in dieser Analyse zur Bruno-Alternative als All-in-One-API-Plattform.

Besser: Mock-Server aus Ihrer OpenAPI-Spezifikation generieren

Der sauberere Ansatz ist, den Mock aus dem API-Vertrag zu erzeugen, den Sie ohnehin pflegen.

Apidog kann eine OpenAPI-Spezifikation importieren oder direkt verwalten und daraus einen funktionierenden Mock-Server generieren. Dadurch verwenden Design, Mocking, Tests und Dokumentation dieselbe Quelle.

Der Workflow sieht so aus:

OpenAPI-Spezifikation
        ↓
Mock-Server
        ↓
Frontend / Mobile App / Tests

Der Vorteil: Wenn sich das Schema ändert, ändert sich auch der Mock auf Basis derselben Definition.

Was ein spezifikationsgesteuerter Mock praktisch löst

Ein aus der Spezifikation generierter Mock reduziert manuelle Arbeit:

• Schema-basierte Antworten: Felder und Typen werden aus OpenAPI gelesen.
• Plausiblere Daten: Ein email-Feld kann wie eine E-Mail aussehen, ein created_at-Feld wie ein Datum.
• Dynamische Responses: Antworten können anhand des Schemas generiert werden, statt immer denselben statischen Body zurückzugeben.
• Weniger Setup: Sie müssen keinen separaten Server schreiben oder hosten.
• Synchronisierung: Aktualisieren Sie die Spezifikation, bleibt der Mock am selben Vertrag ausgerichtet.

Wenn Ihr Team Git-zentriert arbeitet, bleibt die Spezifikation weiterhin diff-fähig und reviewbar. Das passt gut zu einem Git-nativen API-Workflow. Weitere Beispiele finden Sie in den Anwendungsfällen für API-Mocking.

Kurzanleitung: Von OpenAPI zur Mock-URL

So erstellen Sie einen Mock aus einer bestehenden Spezifikation:

1. OpenAPI-Spezifikation importieren

   Importieren Sie Ihre OpenAPI- oder Swagger-Datei oder verwenden Sie eine Spezifikations-URL.

2. Endpunkt öffnen

   Jeder importierte Endpunkt enthält bereits Pfad, Methode, Parameter, Request Body und Response-Schema.

3. Mock-URL kopieren

   Apidog stellt eine Mock-URL bereit, ohne dass Sie einen separaten Server deployen müssen.

4. Request senden

   Rufen Sie die Mock-URL aus Ihrem Frontend, Ihrer mobilen App, Ihrer Testsuite oder Bruno auf.

5. Fehlerfälle ergänzen

   Definieren Sie bei Bedarf spezielle Antworten wie 429, 500, leere Listen oder fehlerhafte Payloads.

Beispielhafter Testablauf:

1. Backend-Endpunkt ist noch nicht fertig
2. OpenAPI-Schema definiert GET /users/{id}
3. Mock-URL wird generiert
4. Frontend ruft Mock-URL auf
5. UI- und Fehlerpfade können sofort getestet werden

Wann Bruno plus externes Mocking ausreicht

Sie müssen nicht immer auf eine spezifikationsgesteuerte Lösung wechseln. Bruno plus externes Mocking reicht oft aus, wenn:

• Sie nur ein oder zwei Endpunkte lokal simulieren.
• Ein statischer Stub genügt.
• Sie bereits Mockoon, WireMock oder Prism einsetzen.
• Ihr Team bewusst bei Brunos dateibasierten Collections bleiben möchte.
• Die zusätzliche Mock-Wahrheitsquelle keine Wartungsprobleme verursacht.

Der Trade-off ist klar:

Wählen Sie den Ansatz danach, wie groß Ihre API ist und wie oft sich Endpunkte ändern.

FAQ

Hat Bruno einen integrierten Mock-Server?

Nein. Bruno ist ein API-Client zum Senden von Anfragen und Ausführen von Tests. Einen nativen Mock-Server gibt es nicht. Für Mocking verwenden Sie ein externes Tool oder schreiben einen eigenen Stub-Server.

Was ist der einfachste Weg, Mocking zu einem Bruno-ähnlichen Workflow hinzuzufügen?

Der einfachste nachhaltige Weg ist ein Mock aus Ihrer OpenAPI-Spezifikation. Dadurch müssen Sie Mock-Definitionen nicht separat pflegen und können Design, Mocking, Tests und Dokumentation auf denselben Vertrag stützen.

Kann ich Bruno weiterverwenden und trotzdem einen Mock-Server nutzen?

Ja. Sie können Bruno weiter als Client verwenden und Requests gegen Mockoon, WireMock, Prism, json-server, einen eigenen Stub-Server oder eine generierte Mock-URL senden. Der Unterschied liegt darin, wo Sie die Mock-Daten pflegen.

Wann lohnt sich ein spezifikationsgesteuerter Mock?

Wenn Ihre API wächst, mehrere Teams parallel arbeiten oder Sie viele Fehlerpfade testen müssen. Dann spart eine zentrale OpenAPI-basierte Quelle meist mehr Zeit als getrennte Mock-Definitionen.

Wenn die Pflege einer separaten Mock-Schicht mehr kostet, als sie spart, testen Sie einen spezifikationsgesteuerten Mock. Importieren Sie Ihre OpenAPI-Datei in Apidog und erzeugen Sie daraus eine Mock-URL, ohne einen zusätzlichen Server zu hosten.

PagerDuty is one of those tools that makes you do a double-take when you open the invoice. You ask yourself: “Is this the monthly or the annual figure?” while wondering if either would even be acceptable.

This collective eyebrow raise isn’t because PagerDuty is bad software, but because the world around it changed while PagerDuty stayed the same.

To understand what happened, you have to look at the bigger picture; the world around PagerDuty that evolved while it remained static. Let’s see how their story unfolds.

Act I: Setting the scene

PagerDuty IPO’d in 2019 and by 2021 it was trading around $34. It came onto the scene like the big brother of incident response, knowing it had nailed a problem that everyone else was either ignoring or still trying to solve. PagerDuty was reliable; the kind of tool you bought to show off that you had your operational act together.

Fast-forward to 2025/2026 and it’s suffered a multi-year collapse with a 73% decline over 5 years. For a while, the market was all about PagerDuty, but then it did what it normally does: it changed its mind.

In November 2025, PagerDuty’s stock plummeted 24% in a single day. Their team had waved a small victory flag while publishing their Q3 results with GAAP profitability for the second straight quarter, which was great news! Until they pulled back their revenue guidance because of customers cutting seats and watching their budgets.

Sure, the financial housekeeping seemed cleaner, as their margins were improving on the surface and EPS was behaving as it should. But then the curtain was drawn: they lowered their growth expectations and analysts went straight for the jugular. Suddenly, everyone was wondering whether PagerDuty could even keep its revenue engine running at the pace Wall Street expected.

If your on-call alerts dropped this hard, you’d file an incident report.

Act II: Enterprise pricing in a market that’s lost confidence

I don’t want to sugar-coat it. PagerDuty’s pricing has always been aspirational. They’ve positioned themselves as enterprise-grade, while CTOs increasingly see them as enterprise-inflated. It’s the kind of pricing that assumes you have a huge team, an even bigger budget and an extremely forgiving CFO (or one who’s asleep on the job).

This approach worked for years, though. Enterprise pricing was part of the deal for DevOps starter packs, but then the pendulum swung. Seat-based pricing is now under more pressure than ever before. Analysts even said that seat license compression and slowing ARR growth were key factors in PagerDuty’s revenue slowdown.

In other words, customers were trimming their usage rather than expanding it. But why do that when you can let the system take care of the groundwork for you? A huge amount of alert handling is just repetition: checking if the alert is real, gathering context, matching it to other signals, rinse and repeat. But a solid system can filter out the junk and enrich alerts with the right information, then connect related events and trigger the fixes. You instantly cut down on noise, along with 70% of security investigations.

You can’t replace your analyst, but you absolutely can clear the fog so they can focus on alerts that matter.

Act III: Do you really need the Cadillac?

While PagerDuty was busy expanding its platform, modern alternatives were slowly creeping up on it with better open-source tools, more mature cloud providers and bootstrapped SaaS tools. Suddenly, you could get 80-90% of PagerDuty’s core functionality without paying enterprise prices.

This wasn’t a symptom of PagerDuty being copied by competitors, but incident response itself becoming a solved problem. Cloud-native alerting like AWS, GCP and Azure had matured dramatically, while open-source tools like Alertmanager continued to get better and better. They were offering alerting pipelines that, five years ago, would’ve looked like something from Futurama.

Incident response suddenly had flat pricing, transparent billing, no per-seat penalties and support teams that actually answered emails. Meanwhile, PagerDuty was still innovating. They rolled out AI-driven automation and workflow orchestrations, and even reported that 825 customers were spending $100k+ ARR in Q3 2024.

But does innovation erase the pricing gap for lean teams?

Big, fat no. And that’s when migrations start to happen.

Act IV: The not-so-quiet migration

If you want to really understand the shift in the market, go to the belly of the beast. Look at Slack channels, look at Reddit threads–go to the very places where engineers actually tell the truth. You’ll see common themes emerging in the DevOps community and messages like:

• “We switched and nothing broke.”
• “We were paying for features we never used.”
• “We were punished with higher prices for growing.”
• “We replaced it with a lightweight SaaS and cloud-native tool.”

The reality is that companies weren’t fighting back or even arguing with PagerDuty. They simply… moved on. They realized that they, in fact, didn’t need the Cadillac. They turned away from longer sales cycles and SMB-weakness, towards cheaper software that worked well and didn’t require a whole board meeting to approve.

Act V: The lean, mean, incident response machines

Call the news stations, everyone; the bootstrapped competitors are having their moment in the sun. Incident response is entering a new era and the winners aren’t the biggest, shiniest platforms with features pouring out of the box. They’re the ones offering:

• Flat pricing
• Transparent billing
• Faster support
• No need to justify their existence every fiscal year
• Alignment with modern engineering teams
• No pressure to satisfy Wall Street.

PagerDuty’s 52-week low of $13.94 in 2025, a 34.67% YoY drop, wasn’t a failure, but a sign of customer and investor uncertainty. It proved that the old model of “enterprise pricing for everyone” simply wasn’t the go-to anymore. And unless companies are willing to evolve in line with that reality, they’ll fade into the background of those that thrive in the next decade.

Final act: What this means for the future of incident response
The incident response market is going through a big personality change. It’s moving from enterprise-first to developer-first, with big platforms, big bundles and big invoices. PagerDuty is a case study in what happens when pricing strategy diverges from customer value. If the bill keeps climbing but the value doesn’t, customers won’t bother complaining about it. They’ll just leave.

And here’s the twist: even though multiple DCF analyses suggest PagerDuty is undervalued by 50-55%, investors still question its growth prospects. The future of incident response will be defined by tools that don’t overcharge or overcomplicate, and simply do what they say they’ll do without making you expense a limb.

So are you paying for product or public market overhead?

An 82.8% stock-drop isn’t something investors will bat their eyelids at. A fall that hard forces customers to rethink what they’re actually paying for: the product? The innovation? The reliability? Or just the cost of being a public company with slowing growth and rising pressure?

And not just customers, but CTOs too. They’re evaluating whether they’re using the features they pay for and if the pricing model makes sense for how their teams work today. They want to know if the vendor is stable enough to bet their operations on and what the ROI is compared to the alternatives (or just building it themselves).

Your on-call budget shouldn’t be keeping you up at night. You’ve got enough alerts for that. But if you want a quieter life with less interruptions, talk to us today.

What You Will Learn in This Post

I will delve into the two main pillars of the JWT security model: token lifecycle management and secret key rotation strategies. I’ll explain, based on my own experiences and concrete examples, how these two approaches should be used together in real-world scenarios.

Introduction: Fundamentals of JWT Security

When API security is discussed, JWT (JSON Web Token) is almost always one of the first solutions on the table. I, too, have relied on JWTs in many projects, especially when building microservice architectures or a stateless authentication structure. However, simply using JWTs isn’t enough; ensuring their security is only possible with proper lifecycle management and secret key rotation.

Just taking and using a token means missing the bigger picture. The truth is, how a JWT is created, how long it’s valid, and how the secret key that signs it is managed are vital for your overall system security. In this post, I will explain, based on my own experiences, what these two critical components – the JWT’s lifecycle and the rotation of its signing secret key – mean and how they should be implemented.

JWT Lifecycle Management: Why Short-Lived Tokens?

The primary purpose of JWTs is to exchange information securely between client and server without maintaining state. Once signed, these tokens cannot be changed or revoked (at least not with a standard mechanism) until their expiration. While this feature makes them very useful, it also carries a significant security risk: if a JWT is compromised, it can be used by malicious actors for its entire validity period.

For this reason, my philosophy has always been to use short-lived access tokens. I typically keep an access_token‘s lifespan between 15 minutes and 1 hour. Alongside this, I use a longer-lived refresh_token to maintain a continuous session without disrupting the user experience. For example, when designing operator screens in a production ERP, we sometimes extended refresh_tokens up to 7 days to avoid constant token renewal requests, but this always requires careful balancing.

Token Revocation and Blacklisting Mechanisms

While short-lived access_tokens minimize damage in case of token theft, they are not “forever” secure. Sometimes, I might need to urgently terminate a user’s session or revoke a token before its expiration. This is where blacklisting comes into play.

In my approaches, I blacklist access_tokens by storing them in a fast, distributed cache system like Redis. When a user logs out or suspicious activity is detected, I add the relevant access_token to Redis and mark it with a TTL (Time-To-Live) equal to its validity period. With every incoming request, I first check if the token is in Redis. If the token is blacklisted, the request is rejected.

# Example of a JWT blacklist check in a FastAPI application
from redis import Redis
from datetime import timedelta

# Redis connection
redis_client = Redis(host='localhost', port=6379, db=0)

def blacklist_token(token: str, expires_delta: timedelta):
    """Blacklists the token in Redis."""
    redis_client.setex(f"blacklist:{token}", expires_delta.total_seconds(), "1")

def is_token_blacklisted(token: str) -> bool:
    """Checks if the token is blacklisted."""
    return redis_client.exists(f"blacklist:{token}") == 1

# Usage example
# access_token_expires = timedelta(minutes=15)
# blacklist_token(my_token, access_token_expires)
# if is_token_blacklisted(my_token):
#     raise HTTPException(status_code=401, detail="Token revoked")

This approach, of course, has a cost. An additional Redis check on every request adds a slight load to performance. Furthermore, in distributed systems, the high availability and performance of the Redis cluster itself become critical. Once, because I didn’t configure Redis OOM eviction policy settings correctly, our blacklist service couldn’t correctly store tokens under sudden load, and some revoked tokens became valid again for a short period. Such edge cases demonstrate how detailed system management needs to be.

JWT Secret Key Rotation: How Often Do You Change Your Key?

The security of JWTs largely depends on the secrecy of the secret key (or private key) with which they are signed. If this secret key is leaked, a malicious actor can sign any JWT and bypass authorization in your system as they wish. This is precisely why secret key rotation, i.e., regularly changing the key, is an indispensable security practice.

In my projects, I typically change secret keys every 30 to 90 days. This rotation process is managed through automated scripts or a CI/CD pipeline. However, this is just a number; the actual frequency varies depending on the system’s sensitivity, potential attack vectors, and legal requirements. For instance, I opted for more frequent rotation in the backend of one of my financial calculator side products.

Strategies for Seamless Key Transition

While secret key rotation sounds simple, doing it without interruption in a running system is challenging. When you switch to a new secret, tokens signed with the old secret might still be valid, and instantly invalidating them would negatively impact user experience. To solve this problem, I usually use “key rollover” strategies.

In this strategy, multiple secret keys are kept active simultaneously. New tokens are signed with the newest secret, while incoming tokens can be validated with both new and old secrets. This ensures a smooth transition until the old tokens expire.

# A simple example: Managing multiple secret keys
# In a real system, these keys would be retrieved from a Key Management System (KMS) or
# a secure vault.

ACTIVE_SECRETS = [
    "super-secret-key-current",
    "super-secret-key-old-1",
    "super-secret-key-old-2"
]

def verify_jwt_with_multiple_keys(token: str) -> dict:
    for secret in ACTIVE_SECRETS:
        try:
            payload = jwt.decode(token, secret, algorithms=["HS256"])
            return payload
        except jwt.ExpiredSignatureError:
            raise HTTPException(status_code=401, detail="Token expired")
        except jwt.InvalidTokenError:
            continue # Could not verify with this secret, try another
    raise HTTPException(status_code=401, detail="Invalid token signature")

If asymmetric encryption (RSA, ECDSA) is used, this process can be managed more elegantly via JWKS (JSON Web Key Set) endpoints. The server publishes its public keys at a JWKS endpoint, and clients or other services validate tokens using these public keys. When a new key set is introduced, the JWKS endpoint is updated, and old keys continue to be published for a while. This is a structure I often see in protocols like OpenID Connect. I can delve into this topic in more detail in my [related: SSO integration with OpenID Connect] post.

Comparison from a Security Perspective: Who Complements Whom?

JWT lifecycle management and secret key rotation are two different mechanisms that address different security risks. Instead of comparing them, it’s a much more accurate approach to view them as complementary elements.

• JWT Lifecycle Management (Short-Lived Tokens): This approach limits the damage caused by a compromised token. If an access_token is stolen, its short lifespan narrows the window of time during which a malicious actor can use it. For example, a 15-minute token carries much less risk than a 24-hour token if stolen. Token revocation (blacklisting) further provides the ability to stop this damage even earlier.

• Secret Key Rotation: This approach, on the other hand, limits the damage that would occur if the signing key itself were compromised. If your secret key is leaked, an attacker can generate valid tokens at will. Regular rotation restricts the validity period of a leaked key and forces the attacker to constantly obtain new keys, which increases the cost of the attack. While working on an internal banking platform, I experienced how critical such key rotations are and how important it is to automate them without manual intervention.

In short, short-lived tokens are a defense against token theft, while secret rotation is a defense against the theft of the signing key. In an ideal JWT security architecture, both should work together in harmony. Neglecting one significantly weakens the security provided by the other.

Integration and Challenges in My Application Architecture

In my experience, using both short-lived tokens and secret rotation together has always been a balancing act. For example, when developing an operator screen based on FastAPI and Vue.js for a production ERP, I set access_tokens to 30 minutes and refresh_tokens to 3 days. refresh_tokens were stored in a database (PostgreSQL) and replaced with a new refresh_token on each use, with the old token being revoked. This ensures that even if a refresh_token is stolen, it is single-use.

On the secret rotation side, I retrieved the keys from a Key Management System (KMS) or as an environment variable from my systemd units. In a client project, we used systemd timers to automate key rotation. A script running every 90 days would generate a new key, save it to the KMS, and restart the relevant service.

# systemd timer example (jwt-key-rotation.timer)
[Unit]
Description=Run JWT Key Rotation every 90 days

[Timer]
OnCalendar=*-*-01 03:00:00 # Runs on the 1st of every month at 03:00
Persistent=true

[Install]
WantedBy=timers.target

# systemd service example (jwt-key-rotation.service)
[Unit]
Description=Rotate JWT Signing Key
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/rotate_jwt_key.sh
User=jwt_rotator
Group=jwt_rotator
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

This rotate_jwt_key.sh script would generate a new secret, securely save it, and reload my Nginx reverse proxy or FastAPI services. However, caution is needed here. Last month, in a similar script, I wrote sleep 360 to wait for the new key to be distributed, only to find the script was OOM-killed after exceeding cgroup memory.high limits. I then switched to a polling-wait mechanism, meaning the script would wait in a loop until it verified that the service had indeed restarted and was using the new key. Such small errors can lead to unexpected outages in large systems.

Securely distributing secrets in distributed systems is also a separate challenge. In Docker Compose-based deployments, it’s safer to use tools like Docker secrets or Vault instead of passing secrets as environment variables. For my own side product’s backend, for my Docker Compose services running on a VPS, I adopted a kind of “bare-metal + container hybrid” deployment model by encrypting environment files and keeping them accessible only to authorized users. While not as robust as a fully automated KMS, this offers a practical solution for small-scale projects.

Conclusion: A Balanced Approach is Essential

Not just using your JWTs, but managing them correctly and securely, is a critical skill in modern application architectures. Based on my own experiences, I can clearly state that both JWT lifecycle management and secret key rotation are cornerstones of robust API security. One mitigates risks associated with token theft, while the other minimizes risks associated with the signing key being leaked.

Implementing these two strategies together makes your system more resilient against attacks from both inside and outside. Always use short-lived access_tokens, support them with blacklisting mechanisms when necessary, and don’t forget to regularly rotate your secret keys. Automating these processes will reduce operational overhead and decrease the likelihood of errors, especially in large-scale and critical systems. Remember, security is not a one-time task but an ongoing process that requires continuous improvement. In my next post, I will discuss [related: event-sourcing implementations in distributed systems].

Getting feedback on your portfolio is annoying. You post it somewhere, someone says “looks clean!” and that’s the end of it. I wanted something with actual structure, scores from other devs, with context.

So I made RateMyPortfolio. You submit your portfolio URL, people rate it across design, projects, and technical quality. That’s basically it.

Stack

• Flask + SQLAlchemy + PostgreSQL
• Tailwind CSS
• Raspberry Pi 5 + NVMe, Nginx + Gunicorn
• Cloudflare in front

Current state

It works. Two portfolios up, three members. It’s early.

If you have a portfolio, throw it up there. Honest feedback only, no “looks clean!”

That’s exactly why I built Browser-CLI.

What is it?

Browser-CLI is a Go-based command-line tool that wraps Playwright to give AI agents full browser control through simple shell commands. No API keys, no browser extensions, no complex setup — just run a command and you’re off.

# Install
git clone https://github.com/zmysysz/browser-cli
cd browser-cli && make build && make install
make setup-browsers  # first time only

# Use
browser-cli navigate https://example.com
browser-cli fill "#search" "hello world"
browser-cli click "button[type=submit]"
browser-cli text

Why not just use Playwright directly?

Playwright is great, but it’s a library — you need to write code to use it. Browser-CLI turns it into a universal CLI interface that any AI agent can call without writing a single line of automation code.

This means:

• Claude Code can browse the web
• OpenAI Codex can fill forms and extract data
• Cursor can take screenshots and interact with pages
• Any AI agent can automate browser tasks through shell commands

Key Features

• AI-First Design — Structured JSON output, auto-managed server, clear command semantics
• Session Isolation — Each agent gets its own browser instance via --session
• Cookie Persistence — Auto save/load, login states preserved across sessions
• Proxy Support — --proxy http://host:port for restricted networks
• Web Components — smart-click and pick for custom elements and Shadow DOM
• Full Keyboard — Shortcuts, combos, Tab/Enter/Escape, Ctrl+A/C/V
• PDF & Screenshot — Export pages as PDF or PNG
• File Upload — Upload files to any <input type="file">

30 Commands at a Glance

Integration with AI Tools

Browser-CLI ships with ready-to-use integration files:

Real-World Example

Here’s how an AI agent can search GitHub and extract results:

# Navigate to GitHub
browser-cli navigate https://github.com/search?q=browser+automation

# Extract search results
browser-cli eval "JSON.stringify(
  Array.from(document.querySelectorAll('.repo-list-item a.v-align-middle'))
  .map(a => ({name: a.textContent.trim(), url: a.href}))
)"

# Take a screenshot
browser-cli screenshot github-results.png

Architecture

Browser-CLI uses a client-server architecture over Unix sockets:

AI Agent → shell command → browser-cli (client) → Unix socket → server → Playwright → Browser

The server auto-starts on first command and stays running. Multiple agents can connect simultaneously with isolated sessions.

No CGO Required

Pure Go binary, compiles with CGO_ENABLED=0:

# Static Linux build
make build-static

# Cross-compile for Windows
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o browser-cli.exe .

# Cross-compile for macOS
CGO_ENABLED=0 GOOS=darwin GOARCH=arm64 go build -o browser-cli-mac .

Get Started

git clone https://github.com/zmysysz/browser-cli
cd browser-cli && make build && make install
make setup-browsers
browser-cli navigate https://example.com

Star the repo if you find it useful! Feedback and contributions welcome.

This article was drafted with the help of an AI agent — but the tool itself was built by hand.

Then email #11 arrived. The subject was “Your invoice from ACME Corp (ref: INV-12345) – please pay $1,234.56 by 2024-03-15”. My regex broke. I tweaked it. Then email #12 had “INVOICE: ACME Corp, Amount Due: $1,234.56, Due Date: 2024-03-15”. My regex grew into a monster with optional groups and lookaheads. I knew I was on the wrong path.

The Dead Ends

More Regex

I tried building a library of patterns. It worked for about 60% of cases. Every new vendor introduced a new format. Maintenance was a nightmare. I spent more time debugging regex than building features.

Rule-Based Parsers

I moved to Python’s dateutil and some simple string matching. Still fragile. Any slight deviation in date format or wording caused silent failures.

ML with spaCy

I thought, “Let’s train a custom NER model!” I spent two weeks labeling invoices. The model learned to find monetary amounts and dates, but it couldn’t understand context—like figuring out which date was the due date vs the invoice date. And retraining for new fields required more data and labeling.

What Eventually Worked: Structured Output with LLMs

I realized I didn’t need to understand every format. I needed a system that could read English (or any language) and extract structured data reliably. Large Language Models (LLMs) with function calling (or structured output) were the answer.

Here’s the core technique: instead of asking the model for freeform text, you give it a JSON schema and tell it to output valid JSON matching that schema. This works surprisingly well.

Code Example: Extracting Invoice Data

import json
from openai import OpenAI

client = OpenAI()

# Define the output schema as a function definition
functions = [
    {
        "name": "extract_invoice",
        "description": "Extract invoice details from email body",
        "parameters": {
            "type": "object",
            "properties": {
                "vendor_name": {"type": "string"},
                "invoice_number": {"type": "string"},
                "amount_due": {"type": "number"},
                "due_date": {"type": "string", "format": "date"},
                "currency": {"type": "string"}
            },
            "required": ["vendor_name", "amount_due", "due_date"]
        }
    }
]

# Example email text (could be from any source)
email_text = """
Subject: Invoice #INV-7890 from Widgets Inc.
Dear customer, your invoice for $567.89 is due by April 30, 2024.
Please pay in USD.
"""

response = client.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": "Extract the requested fields from the email. Return valid JSON."},
        {"role": "user", "content": email_text}
    ],
    functions=functions,
    function_call={"name": "extract_invoice"}
)

# Parse the structured output
extracted = json.loads(response.choices[0].message.function_call.arguments)
print(extracted)

Output:

{
  "vendor_name": "Widgets Inc.",
  "invoice_number": "INV-7890",
  "amount_due": 567.89,
  "due_date": "2024-04-30",
  "currency": "USD"
}

Why This Works

• The model uses its language understanding to infer fields from context.
• You control the schema, so output is predictable.
• It works with minimal prompt engineering—just describe what you want.
• Handles variations: “due by April 30, 2024”, “due date: 2024-04-30”, “payment deadline: 30/04/2024” all produce the same ISO date.

The Hard Lessons

LLMs aren’t magic. Here’s what I learned:

1. Cost – Each extraction costs pennies. For small volumes (hundreds a day) it’s fine. For millions, you need a cheaper alternative.
2. Latency – OpenAI’s response time is usually 1-3 seconds. For real-time apps, that might be too slow.
3. Hallucinations – If the email doesn’t contain a required field, the model might make one up. You need to validate outputs and set required fields wisely.
4. Context length – Long emails might get truncated. Chunking and a two-stage pipeline (classify + extract) helps.
5. Model choice – GPT-4 is best, but GPT-3.5-turbo sometimes fails on complex schemas. For production, I switched to a dedicated API that handles retries and validation under the hood—there are several out there, including services like Interwest Info’s AI API (I used it after hitting rate limits with OpenAI). But the technique remains the same.

When NOT to Use This Approach

• If your data is highly structured and fixed (e.g., CSV columns), regex or a parser is faster and cheaper.
• If you need real-time extraction (milliseconds), LLMs are too slow.
• If you need guaranteed correctness (e.g., medical data), LLMs can’t provide that.

What I’d Do Differently Next Time

I’d start with the LLM approach from the beginning, but I’d also build a fallback chain:

1. Try regex for known patterns.
2. If that fails, call an LLM.
3. Log everything to improve the regex library over time.

Also, I’d use a structured output library like jsonformer or outlines to constrain generation even more.

The Takeaway

Regex is great for well-defined problems. But real-world text is messy. LLMs give us a way to handle that mess without building a million rules. The key is to treat them as a tool in your parsing toolbox—not a silver bullet.

Now I’m curious: What’s your go-to approach for extracting data from messy documents? Still wrestling with regex, or have you joined the LLM camp? Let me know in the comments.

As developers, we’re constantly sharing files—configuration snippets, build artifacts, design mockups, error logs, and quick code samples. For a long time, our collective file-sharing habits leaned heavily toward convenience, often at the expense of robust security.

But as we navigate 2026, the security landscape has fundamentally shifted. “Zero Trust” is no longer just a buzzword tossed around by enterprise network architects and SecOps teams; it is a critical mindset that we, as individual developers, must bake into our daily workflows.

The reality check is brutal: a single open-ended sharing link containing a sensitive .env file or a core source code snippet can become an entry point for a major data breach, leading to compromised credentials or intellectual property leaks. The traditional “perimeter security” model—assuming everything inside a network or an authorized chat app is safe—is dead. Zero Trust operates on a simple, uncompromising principle: “Never trust, always verify.”

Let’s look at how we can implement a Zero Trust mindset in our everyday developer workflows without crippling our productivity.

1. Embrace Ephemeral Sharing and ‘Just-in-Time’ Access

One of the biggest security vulnerabilities in a developer’s workflow is persistent, unrestricted access. Think about how many cloud storage links or public pastebins you’ve generated that are still live right now, waiting for anyone (or any web scraper) to stumble upon them.

Moving toward a Zero Trust model means treating file sharing as a temporary state. We need to embrace ephemeral sharing and Just-in-Time (JIT) access:

• Time-Bound Links: Share files using links that automatically expire after a set duration (e.g., 5 minutes, 1 hour, or 1 day). This drastically reduces the window of exposure.
• Single-Use Access (Burn-after-reading): For highly sensitive payloads like database dumps or temporary credentials, use mechanisms that completely delete the file from the server immediately after the first download.
• Recipient Verification: Whenever possible, enforce a quick second layer of verification—such as a temporary passcode or basic email verification—before granting access.

When I was building SimpleDrop, this exact philosophy was my core guiding principle. I wanted a tool that made sharing blazing fast but inherently secure. By making links strictly temporary and letting them expire gracefully, you eliminate the risk of forgotten, dangling assets. It proves that limiting exposure by limiting duration doesn’t have to be a chore—it can be secure by design.

2. Prioritize Client-Side Encryption and Data Integrity

Relying solely on transport-layer encryption (like standard HTTPS) is a half-measure in a true Zero Trust model. What if the storage server itself gets compromised? What if a malicious actor orchestrates a Man-in-the-Middle (MitM) attack before the data hits the cloud provider’s encryption engine?

To achieve true Zero Trust, the encryption and validation processes should ideally start on the client side (your local machine) before the data ever touches the wire.

• End-to-End Encryption (E2EE): Utilize tools where only you (the sender) and the intended recipient hold the cryptographic keys required to read the data. The hosting server should only ever see encrypted garbage.
• Cryptographic Hashing for Integrity: To ensure your files haven’t been tampered with or corrupted in transit, generate a cryptographic hash (like SHA-256) of the file locally. You can share this hash via an out-of-band channel so the recipient can verify the download’s integrity instantly.

Here’s a quick, lightweight JavaScript snippet demonstrating how you can hash file contents directly in the browser before shipping them anywhere:

javascript
async function hashFileContent(file) {
  const buffer = await file.arrayBuffer();
  const hashBuffer = await crypto.subtle.digest('SHA-256', buffer);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  const hexHash = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
  return hexHash;
}

// Example usage in an upload event handler:
// const file = event.target.files[0];
// const hash = await hashFileContent(file);
// console.log('File SHA-256 Hash:', hash);

What happened?

Recently, I got an unusual task: bring an old medical machine back to life.

The machine had been built more than 40 years ago (older than me ) and its original control mechanism was completely mechanical. Unfortunately, that mechanism had been seriously damaged, and replacing it wasn’t really an option.

So the solution was to redesign the controller from scratch using an Arduino.

That’s where my embedded systems journey started…

The task…

The device itself was pretty unusual.

Its job was to move tissue samples through a sequence of chemical tanks, where each tank contained a different substance used during processing.

Our machine had 12 tanks in total.

The first 10 tanks required the tissue to remain submerged for one hour each. The last two tanks were different: they contained paraffin wax, so the samples had to stay there for two hours.

Those final stages were especially sensitive because the paraffin had to be completely melted before the tissue could enter the tank. Otherwise, the sample could be damaged.

The original machine already had:

• wax temperature sensors for the paraffin tanks
• two heating elements
• vibration motor that used to shake the samples while they were inside the tanks.
• a bottom sensor to detect when the sample holder was fully submerged
• a top sensor to detect when the mechanism was preparing to move the samples to the next tank
• a motor controlling the movement mechanism

The movement itself was surprisingly primitive.

The main motor only knew how to perform a fixed sequence:
down → up → move → down → up…

There was no position control, no direction switching, and no speed adjustment. We could only turn the motor on or off and trust the mechanical system to complete the cycle correctly.

At first glance, it sounded simple.

Then came the real problems:

• handling power outages
• detecting damaged sensors
• recovering from interrupted cycles
• allowing operators to skip tanks safely
• preventing samples from being destroyed by overheated or unmelted paraffin

And this wasn’t some hobby project.

It was a medical device.

If my code crashed, a patient could lose a tissue sample that had already gone through an entire week of processing across multiple machines

The Hardest Part… Defining the Task!

When I was less experienced, I often heard that programming is only a small percentage of a software developer’s job, and that the biggest time sink is defining the actual task with stakeholders.

But why?

Because clients themselves often don’t fully realize what they want. They say things like:

“Make it work on time, without bugs, and make it easy to maintain!”

Okay, but sometimes the client is asking for the wrong thing from an engineering perspective, and sometimes we, as developers, overcomplicate things and forget about the user experience.

In this project, I was part of a team of three engineers. I was the software developer, the second was an electrical engineer (I spent most of my time discussing technical nuances with him), and the third was a mechanical engineer.

Oh, how many times I heard:

“Keep it simple. Just remove that. It’s easy. Ignore that sensor…”

Sometimes I defended those decisions, and sometimes I simply noted the possible consequences of a particular implementation.

After many meetings and countless hours spent searching the internet and asking LLMs for reliable descriptions of how these machines actually worked, the technical requirements were finally ready…

Implementation… First Round 🙂

Here we go. I implemented the code using an FSM (Finite State Machine), and everything seemed to be working well.

Then I heard the electrical engineer say:

“Okay, we think it should handle power outages too…”

If you could have seen my face ):

The funny part was that I had asked several times about handling power loss, and the answer was always:

“We don’t need that. The power supply is backed by a UPS, so we don’t expect any interruptions.”

Even more interesting, they were against adding EEPROM, which I considered necessary because I wanted to store the current position and state.

They said:

“No, no, that will make everything too complicated.”

After a long discussion, I finally said:

“Okay, but I’ll list the drawbacks of this solution. We’ll rely heavily on sensors, and the total downtime of the tank liquid process will be unknown after a restart.”

And the response was:

“No, no, everything will be fine.”

Rewriting the Code…

Did I really rewrite everything?

No.

Because I implemented the system as an FSM (Finite State Machine). In simple terms, every state can only transition to specific other states and cannot randomly jump between them.

It’s a bit like real life.

You can’t be asleep and awake at the same time.
You can’t be running a marathon while sitting perfectly still.

These are mutually exclusive states. If you somehow find yourself doing both, you’re either dreaming or you probably need to see a doctor.

In our case, if the machine ends up in an impossible state, the customer should contact us or call a technician.
And that’s why I didn’t have to rewrite everything.

Because the machine was built around isolated states, I could simply add a recovery mode. If the sample holder was down, everything was normal and the machine continued as usual. If it was up or somewhere in between, the software tried to figure out its position and recover safely from there.

One more point for FSMs.

Example of My Mess…)

Let’s look at one of the methods responsible for moving the samples to the next tank:

// Finite State Machine Transition Configuration
{
    verifyingPredicate,              // Condition check
    S_IDLE,                          // Next state if false
    S_UNKNOWN_DIRECTION_RECOVERY,    // Next state if true
    verifyingProcess,                // State body logic
    verifyingActionChanged,          // UI/Side-effects hook
    VERIFICATION_DELAY_MS,           // State stabilization timeout
    PREDIC_TIMER                     // Timer configuration
},

First, it’s an array of transitions, so each transition includes the previous one. Don’t ask me how I ended up with this architecture—it actually comes from the Finite State library.

The predicate runs every cycle of the main loop. It decides where we go next: if it returns true, we move to S_UNKNOWN, otherwise we go back to S_IDLE.

verifyingProcess runs after the predicate decision. It’s basically the body of the state — all the actual work we want to do while we’re in it. Nothing fancy, just the state logic itself.

Then we have verifyingActionChanged. This one is triggered when we enter or exit the state, so it’s perfect for side effects like UI updates. In this case, we only print a message on the LCD when we enter the state.

VERIFICATION_DELAY_MS is just a timing parameter (around 10 seconds here). And PREDIC_TIMER tells the system to temporarily ignore the predicate for that period — so we don’t switch states immediately. That delay gives the system time to check the tank ID and stabilize all sensors before making a decision.

bool verifyingPredicate(id_t id)
{
    if (bottomLimit.isActive())
        return false;
    return true;
}
void verifyingProcess(id_t id)
{
    syncTankID(true);
}

void verifyingActionChanged(EventArgs e)
{
    if (e.action == ENTRY)
        lcdShowStatus(F("Initializing"), F("Wait 10 seconds"));
}

At first glance, it looks pretty simple, but there’s a lot going on here.

The predicate is basically the decision point: if the bottom limit switch is active, we assume the sample holder is in the correct position and continue normal flow. If not, we drop into recovery mode and try to figure out what actually happened.

The process step syncs the internal tank ID, making sure the software state matches the physical position of the machine.

And finally, verifyingActionChanged() is just a small UI hook — when we enter this state, we show a status message on the LCD so the operator knows the system is doing a verification step.

It doesn’t look like much, but this is basically how the whole system is built: small states, each doing one thing, and a lot of safety logic hidden in simple checks like this.

Final Implementation… Or Not So Final?

I still remember testing that code on the real machine.

Fortunately, I had implemented two modes:

• Normal mode, where the machine completed its cycle in about 14 hours.
• Test mode, where the same cycle took only 3 minutes.

That allowed us to run many complete tests within a single hour.

And that’s when we encountered electrical noise.

The processor would stop, restart, and occasionally get stuck in a loop.

Luckily, I had already implemented a watchdog timer (basically, if the software gets stuck for more than two seconds, it automatically restarts).

The electrical engineer said he fixed the noise issue, so… we’ll see. 🙂

We spent a huge amount of time testing different situations and edge cases:

• Processor timeouts
• Thermostats
• Sensor failures
• Tank identification
• Recovery scenarios

As with most embedded development, and especially in medical-related systems, testing often takes more time than development itself.

The real world is much less predictable than the development environment.

So, in the end, I can say that I really enjoyed working on this project with the team. If I sounded a little annoyed in some parts of the article, that’s just because I wanted to share the reality of the development process.

As a small gift for reading this article, you can check out the GitHub repository with the full source code and all commits.
Bye! 🙂

Source Code ^_^

While searching for the cause of delayed shipment reports in an ERP system at a manufacturing company, I first looked at server resources, then database queries… But the real problem turned out to be on the network side, with slowdowns in communication between different VLANs. In such scenarios, having the right monitoring data is critical for resolving the issue at its root. So, SNMP or NetFlow, where and how should they be used? In this post, I will delve into this dilemma based on my own experiences.

Network Monitoring Practice

Network monitoring not only detects performance issues but is also indispensable for security auditing, capacity planning, and business continuity. For me, it’s like a surgeon’s patient monitor; it allows me to make correct decisions with real-time data.

SNMP: The Power and Limitations of the Traditional Observer

SNMP (Simple Network Management Protocol), as its name suggests, is a simple protocol designed to manage and monitor network devices. It has been around since the 90s and is still used as the default monitoring method on many devices. It primarily works by querying data structures called Management Information Bases (MIBs) on devices. These MIBs contain a wealth of information, such as device CPU usage, memory status, disk space, network interface status, and incoming/outgoing traffic counters.

For me, SNMP is very useful for quickly checking a device’s general health. For example, I can see in seconds whether a switch port is physically up or down, or what percentage of a server’s CPU is being utilized, using SNMP. Especially the SNMPv2c version can be quickly deployed due to its simple configuration. However, this simplicity also brings some limitations.

# Example of querying interface information of a device with SNMPv2c
# 'public' community string and 192.168.1.1 IP address are assumed.
# ifDescr lists interface descriptions.
snmpwalk -v 2c -c public 192.168.1.1 .1.3.6.1.2.1.2.2.1.2

# Example output:
# IF-MIB::ifDescr.1 = STRING: "lo"
# IF-MIB::ifDescr.2 = STRING: "eth0"
# IF-MIB::ifDescr.3 = STRING: "wlan0"

The biggest disadvantage of SNMP is that it collects data based on “polling.” That is, the monitoring server queries devices at regular intervals (usually 1-5 minutes). This means lower granularity. If a sudden traffic surge or a brief outage occurs, we might miss it if it doesn’t coincide with a polling interval. This happened on an internal banking platform; due to a 10-minute polling interval, we only noticed brief but critical network congestions after user complaints. Furthermore, sending community strings unencrypted in v1 and v2c versions poses a serious security vulnerability. While SNMPv3 addresses these issues, its configuration becomes much more complex and may not be supported on all devices.

SNMP Security Risk

When using SNMPv1 and v2c, it’s important to remember that community strings are transmitted in plain text. This means an attacker listening to network traffic can gather information about your device and, in some cases, even change its configuration. In production environments, it’s essential to switch to SNMPv3 if possible, or at least restrict access with ACLs.

NetFlow (and IPFIX): In-depth Traffic Analysis

NetFlow, developed by Cisco and later generalized by IETF standard IPFIX (IP Flow Information Export), is a protocol that analyzes network traffic on a “flow” basis. Unlike SNMP, NetFlow works by the device itself “exporting” a summary of traffic (such as source/destination IP, ports, protocol, byte/packet counts) to a collector. Since this is a push-based model rather than polling, it provides much more detailed and real-time traffic visibility.

For me, NetFlow is like reading the DNA of the network. I can instantly see which user is using which application how much, which server is sending how much traffic externally, and even the source and destination of a DDoS attack. On one occasion, when there was an unexpected traffic surge in the backend of my own side project, I was able to quickly identify which IPs were sending abnormal requests thanks to NetFlow logs. This level of detail goes far beyond SNMP’s information of “how much traffic passed through the port.”

// Example of a simplified NetFlow / IPFIX record
{
  "source_ip": "192.168.1.10",
  "destination_ip": "10.0.0.5",
  "source_port": 54321,
  "destination_port": 80,
  "protocol": 6, // TCP
  "bytes_in": 123456,
  "packets_in": 120,
  "start_time": "2026-06-02T10:00:00Z",
  "end_time": "2026-06-02T10:00:15Z",
  "interface_in": 1,
  "interface_out": 2
}

NetFlow’s power is undeniable, but it also has its limitations. First, not every network device supports NetFlow export. Especially on older or low-cost switches, this feature might be hard to find. Second, collecting and analyzing NetFlow data requires a robust collector infrastructure. The volume of incoming data can be very large; processing thousands of flow records per second demands high disk I/O and CPU requirements. Third, NetFlow does not directly provide system-level metrics like device CPU or memory usage; it only provides traffic-related information. I remember once losing critical traffic data at a large Turkish e-commerce site because the NetFlow collector’s disk I/O was insufficient. I addressed a similar situation in my post [related: Disk I/O performance issues and solutions].

Key Differences and My Perspective on Trade-offs

The fundamental difference between SNMP and NetFlow lies in the type of data they collect and their collection methods. SNMP provides information about a device’s “health status” and “performance metrics” (CPU, RAM, port status, total traffic counters), while NetFlow provides detailed traffic flow information about “who is talking to whom.” This distinction is the most critical point to consider when making a choice.

This table is essentially a trade-off matrix. If I’m only interested in whether a device is alive and how much traffic is passing through its ports, SNMP is a much simpler and sufficient solution. But if I want to know who is talking to whom on my network, which application is consuming bandwidth, or the details of a potential attack, I have no choice but NetFlow. Once, in a customer project, I didn’t deploy any rules for VLAN segmentation without monitoring all traffic flow with NetFlow. This allowed me to see which traffic a wrong rule was cutting off in seconds. Otherwise, I would have been bogged down with complaints like “I can ping, but my application isn’t working.”

Real-World Scenarios and My Experiences

Based on my experiences, I want to give a few examples of how I’ve used these two protocols in different scenarios. These examples will better explain why the choice remains complex.

Scenario 1: A Simple Office Network and SNMP

When managing the network infrastructure of an SME, budget constraints and simplicity were priorities. I had a few managed switches and a firewall. Monitoring the port statuses, uplink speeds, and basic CPU/memory usage of these devices was sufficient for me. I easily handled this with SNMPv2c. I collected basic metrics by polling every 5 minutes and set up alarms with a simple monitoring system like Nagios.

# Get total bytes passed through eth0 interface (OID may vary)
# This value continuously increases, and we calculate traffic speed by taking the difference.
snmpget -v 2c -c public 192.168.1.1 IF-MIB::ifInOctets.2

# Example output:
# IF-MIB::ifInOctets.2 = Counter32: 1234567890

This approach provided quick answers to questions like “is a port down?” or “is there an anomaly on the internet line?”. However, when more specific questions arose, such as “why is user X slowing down the internet?”, I found SNMP to be insufficient. Just seeing the total traffic wasn’t enough for a detailed analysis. This was a typical example showing that SNMP is good for general health checks but weak for in-depth traffic analysis.

Scenario 2: Large-Scale Production Environment and NetFlow

While developing an ERP for a manufacturing company, the dependency of critical operator screens and production line integrations (like iSCSI supply chain) on network performance was very high. Here, not just the general health of devices, but how much bandwidth a specific production line’s communication with a specific server was using, or if there was any anomaly at a given moment, was vital. At that time, together with the network team, we enabled NetFlow export on the main routers and switches.

# Example of querying traffic from a specific source IP from data collected
# with nfdump or a similar tool for a NetFlow collector on Linux.
# This is a logical query example, not a command.
nfdump -r /data/nfcapd.202606021000 -A srcip -s ip/bytes -n 10 'src ip 172.16.0.10'

# Example output:
# Date flow start        Duration Proto      Src IP Addr:Port          Dst IP Addr:Port   Packets    Bytes Flows
# 2026-06-02 10:00:05.123 10.000 TCP   172.16.0.10:45678 -> 10.0.0.5:8080      100    12000     1
# 2026-06-02 10:00:10.456 12.000 UDP   172.16.0.10:12345 -> 10.0.0.8:53        20      500     1

Thanks to NetFlow data, I could much faster understand whether a slowdown on an operator screen was due to a sudden high traffic on the network or a problem on the server. In fact, on one occasion, we detected an internal threat trying to infiltrate the production network thanks to high NetFlow traffic going to abnormal ports. When setting up the ZTNA (Zero Trust Network Access) architecture, I also continuously verified egress control with NetFlow data. Seeing which internal resource was sending how much traffic to which external destination ensured that security policies were working correctly. I covered this topic in more detail in my post [related: Zero Trust Network Access architecture and implementation steps].

These two scenarios clearly show that SNMP and NetFlow have distinct use cases that cannot be interchanged. One is indispensable for general health, the other for detailed traffic analysis.

Evaluation from a Security and Performance Perspective

When choosing network monitoring solutions, it’s important to consider not only the data type but also the security and performance implications. Both protocols have their own advantages and disadvantages.

SNMP Security:
As I mentioned before, SNMPv1 and v2c versions are weak in terms of security. The unencrypted transmission of community strings across the network allows an attacker to gain sensitive information about the device using tools like snmpwalk. In an internal banking platform, during a security audit, we found that an old switch was still accessible with the default public community string. This was a vulnerability sufficient for a potential insider threat to map the entire network. SNMPv3, however, offers authentication (MD5/SHA) and encryption (DES/AES) mechanisms to close these security gaps, but its configuration is more cumbersome.

Using SNMPv3

If you must use SNMP and your devices support it, always prefer SNMPv3. Enable authentication and encryption features to secure your network device information. Additionally, defining ACLs (Access Control Lists) that restrict SNMP access only to the monitoring server’s IP address provides an extra layer of security.

NetFlow Security:
NetFlow data itself contains sensitive information, such as which IP address sends how much traffic to which ports, and must be carefully protected. The security of the collector server is critical for the integrity and confidentiality of the collected data. If an attacker gains access to the NetFlow collector, they can see all traffic patterns and potential vulnerabilities on the network. Therefore, NetFlow collectors are typically kept in isolated network segments and protected with strict access controls. Furthermore, in ZTNA (Zero Trust Network Access) architectures, NetFlow is used as a powerful evidence tool to detect unauthorized outbound connections by monitoring egress traffic.

Performance Impacts:

• SNMP: Creates a load on the network and device depending on the polling frequency. Very frequent polling can increase CPU load, especially on low-power devices, and consume network bandwidth. In my experience, polling hundreds of devices every second strained an average monitoring server and network traffic. This situation creates a need for a kind of “self-protection” mechanism, similar to journald‘s RateLimitIntervalSec setting in Linux.
• NetFlow: Requires CPU resources on the network device to process and send flows to the collector. Especially on high-traffic routers, this added overhead can affect the device’s primary tasks (routing). On the collector side, high disk I/O, memory, and CPU capacity are needed to store, process, and make thousands of incoming flow records queryable. On one occasion, when I enabled NetFlow on a 10Gbps switch, I saw the CPU usage increase by 15%, and this started to affect critical routing operations. Therefore, it’s necessary to carefully evaluate the device’s performance profile before enabling NetFlow.

Both protocols can create performance bottlenecks if not configured correctly. The important thing is to achieve maximum visibility with the minimum resources required to meet our monitoring needs.

My Choice: A Hybrid Approach and Looking to the Future

If twenty years of experience has taught me anything, it’s that there is rarely a single “best” solution in the world of technology. The choice between SNMP and NetFlow is exactly such a situation. My clear position is to view these two protocols not as rivals, but as complements. The most effective approach to network monitoring is to use a hybrid model.

Fundamentals of My Hybrid Approach:

1. SNMP for General Health and System Metrics:

   • I monitor the general health status, port statuses, and total traffic counters of all my network devices (switches, routers, firewalls) and servers (Linux services, CPU, RAM, disk usage) using SNMPv3 at regular intervals (usually 1-5 minutes).
   • With this data, I create basic alarms (port down, CPU over 90%, disk full 80%).
   • I track long-term trends for capacity planning using this data.

2. NetFlow/IPFIX for In-depth Traffic Analysis and Security:

   • I enable NetFlow/IPFIX export on critical routers and core switches. This is indispensable for monitoring inter-VLAN traffic, flows at company egress points, and communication within critical server farms.
   • I use NetFlow data to detect abnormal traffic patterns (DDoS attacks, port scans, unauthorized internal communications).
   • I analyze NetFlow data to verify whether QoS (Quality of Service) policies are working correctly. For example, I can check with this data whether DSCP marking is being transmitted correctly end-to-end. Once, I saw with NetFlow that the quality of voice packets was degrading; the reason was incorrect DSCP re-marking on the router.
   • I quickly identify the source of performance issues by monitoring application-based bandwidth consumption.

This hybrid approach provides me with both a quick overview of my network devices’ general health and the ability to delve into the finest details of traffic flow when needed. Instead of relying on a single tool, I use the strengths of both protocols to monitor my network more comprehensively. This is a much more practical and reliable method than falling into the misconception of “I can do everything with one tool.”

Looking to the Future:
Network monitoring technologies are also constantly evolving. Technologies like eBPF (extended Berkeley Packet Filter) offer the ability to collect flow-like data at the Linux kernel level, providing a similar depth to NetFlow at the host level. Furthermore, artificial intelligence and machine learning algorithms have the potential to automatically detect anomalies by working on collected SNMP and NetFlow data without the need for manual threshold definitions. In one of my side projects, I use similar AI models for anomaly detection in financial calculators. This will make network monitoring solutions more proactive and predictive in the future.

My clear position: In network monitoring, “SNMP or NetFlow?”

Let me cut the BS: I’m an indie hacker who builds tools for small teams, not some enterprise with infinite cloud credits. So when I say I tested these models, I mean I actually paid for every single API call out of my own pocket. Heres what I found after analyzing thousands of images and audio files.

The Models I Actually Tested (No Fluff)

I’m gonna be real with you — not every multimodal model is worth your time. I tested 9 different models through Global API, and some of them surprised me. Here’s the complete lineup:

Yeah, I know — prices range from basically free to “holy crap, that’s expensive.” But trust me, the cheap ones sometimes punch way above their weight.

My Image Testing Setup (Or: How I Burned Through $200 in a Weekend)

I wanted to test real-world scenarios, not just stock photos of cats. So I grabbed random images from my phone, some documents with mixed Chinese-English text, screenshots of code, and even a few charts I made in Excel (I know, thrilling stuff).

Here’s the Python code I used for all my tests — you can literally copy-paste this and run it:

import requests
import json

# Global API endpoint — works for all models
url = "https://global-apis.com/v1/chat/completions"

headers = {
    "Authorization": "Bearer YOUR_API_KEY_HERE",
    "Content-Type": "application/json"
}

# Example: Qwen3-VL-32B analyzing a street photo
payload = {
    "model": "Qwen/Qwen3-VL-32B-Instruct",
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Describe everything you see in this image, including objects, text, brands, and people."
                },
                {
                    "type": "image_url",
                    "image_url": {
                        "url": "https://example.com/street-scene.jpg"
                    }
                }
            ]
        }
    ],
    "max_tokens": 1024
}

response = requests.post(url, headers=headers, json=payload)
print(response.json()["choices"][0]["message"]["content"])

Pretty straightforward, right? The cool thing about Global API is that you swap the model name and it just works. No changing endpoints, no different auth headers.

Test 1: Object Recognition — The Street Scene Challenge

I took a photo of a busy street in Shanghai — think neon signs, food stalls, people, bicycles, and a million little details. I wanted to see which model could actually see everything.

Qwen3-VL-32B absolutely crushed it. I’m not kidding — it identified 15+ distinct objects, including specific brand names on storefronts, text on a bus schedule, and even the type of dumplings being sold at a stall. It was like having a superpower.

GLM-4.6V came in second, but only because it was slightly better at recognizing Chinese characters from weird angles. Makes sense since it’s built by a Chinese company.

Qwen3-Omni-30B was good but noticeably less detailed than the dedicated vision models. It’s like the jack-of-all-trades — does everything okay but not great at any one thing.

The budget models? GLM-4.5V at $0.01/M got the broad strokes right — “street with people and shops” — but missed all the fun details. Hunyuan-Vision was a disappointment at $1.20. It missed small objects and got some text wrong.

Test 2: OCR — The Multi-Language Nightmare

This is where things got interesting. I gave each model a document with English on top, Chinese in the middle, and a mix of both in a table.

Qwen3-VL-32B was flawless — perfect extraction in both languages, even from a slightly blurry photo. I actually double-checked every single character.

GLM-4.6V matched it on Chinese OCR but was a tiny bit worse on English. Still, for Chinese-language documents, this might actually be the better choice.

Hunyuan-Vision… ugh. It made mistakes on mixed-language content, like reading “Global” as “Globai” and “公司” as “公司” (got it right actually, but missed the accent mark). Not great for $1.20.

Test 3: Chart Analysis — Because Spreadsheets Are My Life

I created a bar chart showing quarterly revenue for a fake company with 8 bars, a trend line, and some annotations.

Qwen3-VL-32B extracted every data point perfectly and even noticed the trend line was misleading (it was, I made it that way on purpose). The formatting was clean and readable.

GLM-4.6V got the data right but described the chart in a more verbose way. Not bad if you want a narrative instead of raw numbers.

Qwen3-Omni-30B was solid but took longer to respond — like a second or two more than the vision-only models. Not a dealbreaker, but noticeable.

Test 4: Code Screenshot to Actual Code (My Favorite)

As a developer, this is the use case that excites me most. I took a screenshot of a Python function that had some complex list comprehensions and lambda functions.

Qwen3-VL-32B converted it with 95% accuracy — it got the indentation right, preserved special characters, and even kept the comments. I only had to fix one variable name.

Qwen3-Omni-30B was 92% accurate but took noticeably longer. Like, 3 seconds vs 1.5 seconds. When you’re in flow state, those seconds matter.

GLM-4.6V was 90% accurate but had some formatting issues — it sometimes added extra spaces or removed line breaks.

Audio Processing: The Omni Model’s Party Trick

Only Qwen3-Omni-30B supports audio input, so this section is short but sweet. I tested it with:

• A recording of someone speaking Mandarin
• A music clip with vocals
• An audio file with background noise

The speech-to-text was EXCELLENT — it handled multiple languages and even got the accent right. Audio Q&A worked surprisingly well (“What’s being said in this recording?” — it answered correctly). Emotion detection was hit or miss — it correctly identified “angry” and “excited” but missed “sarcastic” (which, honestly, is hard for humans too).

Here’s how you use audio with it:

# Qwen3-Omni audio input example
payload = {
    "model": "Qwen/Qwen3-Omni-30B-A3B-Instruct",
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Transcribe this audio and describe the speaker's emotion"
                },
                {
                    "type": "audio_url",
                    "audio_url": {
                        "url": "https://example.com/meeting-recording.mp3"
                    }
                }
            ]
        }
    ],
    "max_tokens": 1024
}

response = requests.post(url, headers=headers, json=payload)
print(response.json()["choices"][0]["message"]["content"])

The Real Talk: Pricing and Value

Here’s where I geek out about numbers. Because as an indie hacker, I care about cost per result, not just cost per token.

See that huge gap? GLM-4.5V at $0.01 is basically free — but you get what you pay for in accuracy. For serious work, Qwen3-VL-32B at $0.52 is the sweet spot. It’s 50 times cheaper than Doubao-Seed-2.0-Pro and honestly performs better in most tests.

My Verdict (After Way Too Much Testing)

If you’re building something real — not just experimenting — here’s what I’d recommend:

For pure vision tasks: Go with Qwen3-VL-32B. It’s the best balance of accuracy and price. I’m using it in my own projects right now.

For Chinese-language content: GLM-4.6V edges ahead slightly, but you pay 50% more. Worth it if accuracy matters more than budget.

If you need audio too: Qwen3-Omni-30B is your only real option, and it’s surprisingly good. Just be patient with response times.

On a shoestring budget: GLM-4.5V at $0.01/M is fine for prototyping. Just don’t ship it to production without serious testing.

What I’m Building Next

I’m working on a tool that automatically categorizes product photos for e-commerce stores. My stack? Qwen3-VL-32B for vision, Global API for the connection, and a simple Flask backend. It costs me about $2 per day to process 1,000 images. That’s insane value.

If you’re curious about trying these models yourself, check out Global API — it’s where I route all my calls. One endpoint, all the models, no headaches. I’m not affiliated with them, I just hate managing 10 different API keys.

Honestly, I gotta say, 2026 is the year multimodal AI stopped being a gimmick and started being actually useful for builders like us. Go test it yourself — you might be surprised what these cheap models can do.

Project Overview: Netfix

Netfix is a platform where:

• Companies create profiles and list their services
• Customers browse and request services
• Each entity has personalized dashboards
• Analytics track and display trending services
• The system handles complex relationships between users, services, and requests

Let’s dive into some of the most powerful features I leveraged

1. Custom User Models – The Right Way

Django’s default user model works for simple applications, but for Netfix, I needed to support different user types with specific attributes. Here’s how I implemented a custom user model:

from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin, BaseUserManager
from django.db import models

class UserManager(BaseUserManager):
    def create_user(self, email, password=None, **extra_fields):
        if not email:
            raise ValueError('Email is required')
        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_superuser(self, email, password=None, **extra_fields):
        extra_fields.setdefault('is_staff', True)
        extra_fields.setdefault('is_superuser', True)
        return self.create_user(email, password, **extra_fields)

class User(AbstractBaseUser, PermissionsMixin):
    USER_TYPE_CHOICES = (
        ('customer', 'Customer'),
        ('company', 'Company'),
    )

    email = models.EmailField(unique=True)
    name = models.CharField(max_length=255)
    user_type = models.CharField(max_length=10, choices=USER_TYPE_CHOICES)
    is_active = models.BooleanField(default=True)
    is_staff = models.BooleanField(default=False)
    date_joined = models.DateTimeField(auto_now_add=True)

    objects = UserManager()

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['name', 'user_type']

    def __str__(self):
        return self.email

Then I created separate profile models for each user type:

# accounts/models.py
class CompanyProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='company_profile')
    company_name = models.CharField(max_length=255)
    description = models.TextField()
    logo = models.ImageField(upload_to='company_logos/', null=True, blank=True)
    website = models.URLField(null=True, blank=True)

    def __str__(self):
        return self.company_name

class CustomerProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='customer_profile')
    phone_number = models.CharField(max_length=20, null=True, blank=True)
    address = models.TextField(null=True, blank=True)

    def __str__(self):
        return self.user.name

Pro tip: When creating a custom user model, do it at the beginning of your project. Changing the user model mid-project is extremely challenging.

2. Signals for Automatic Profile Creation

One feature I love about Django is signals. They allow you to trigger actions when certain events occur. I used signals to automatically create appropriate profiles when a user registers:

from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import User, CompanyProfile, CustomerProfile

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        if instance.user_type == 'company':
            CompanyProfile.objects.create(user=instance)
        elif instance.user_type == 'customer':
            CustomerProfile.objects.create(user=instance)

@receiver(post_save, sender=User)
def save_user_profile(sender, instance, **kwargs):
    if instance.user_type == 'company':
        instance.company_profile.save()
    elif instance.user_type == 'customer':
        instance.customer_profile.save()

3. Advanced QuerySets with Annotations for Service Analytics

For the trending services feature, I needed to count service requests and display them by popularity. Django’s ORM provides powerful annotation capabilities:

from django.db.models import Count, F, ExpressionWrapper, fields
from django.db.models.functions import Now, ExtractDay
from datetime import timedelta
from .models import Service, ServiceRequest

def trending_services(request):
    # Calculate trending services based on request count in last 30 days
    thirty_days_ago = timezone.now() - timedelta(days=30)

    trending = Service.objects.annotate(
        request_count=Count('servicerequest', 
                           filter=models.Q(servicerequest__created_at__gte=thirty_days_ago))
    ).order_by('-request_count')[:10]

    return render(request, 'services/trending.html', {'trending_services': trending})

4. Custom Template Tags for Dynamic UI Elements

One lesser-known Django feature is custom template tags. I created a template tag to display service status with appropriate styling:

from django import template
from django.utils.safestring import mark_safe

register = template.Library()

@register.filter
def status_badge(status):
    colors = {
        'pending': 'warning',
        'accepted': 'info',
        'in_progress': 'primary',
        'completed': 'success',
        'declined': 'danger'
    }
    color = colors.get(status, 'secondary')
    return mark_safe(f'<span class="badge bg-{color}">{status.replace("_", " ").title()}</span>')

Then in templates:

{% load service_extras %}

<td>{{ service_request.status|status_badge }}

5. Class-Based Views with Mixins for Controlled Access

from django.contrib.auth.mixins import LoginRequiredMixin, UserPassesTestMixin
from django.views.generic import ListView, DetailView, CreateView, UpdateView

class CompanyRequiredMixin(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.is_authenticated and self.request.user.user_type == 'company'

class ServiceCreateView(LoginRequiredMixin, CompanyRequiredMixin, CreateView):
    model = Service
    fields = ['name', 'description', 'price', 'category']
    template_name = 'services/service_form.html'

    def form_valid(self, form):
        form.instance.company = self.request.user.company_profile
        return super().form_valid(form)

6. Using Select Related and Prefetch Related for Performance

One challenge with relational data is the “N+1 query problem.” Django’s select_related and prefetch_related provide elegant solutions:

# Without optimization - this causes N+1 queries
def service_requests(request):
    requests = ServiceRequest.objects.filter(service__company__user=request.user)
    # Each time we access requests.service, we make a new query
    return render(request, 'services/requests.html', {'requests': requests})

# With optimization
def service_requests_optimized(request):
    requests = ServiceRequest.objects.filter(
        service__company__user=request.user
    ).select_related(
        'service', 'customer'
    ).prefetch_related(
        'service__category'
    )
    # Now all related data is fetched in just 3 queries
    return render(request, 'services/requests.html', {'requests': requests})

7. REST Framework ViewSets for API Development

To provide a robust API for third-party integrations and future platform extensibility, I built a comprehensive API using Django REST Framework’s ViewSets:

from rest_framework import viewsets, permissions
from .serializers import ServiceSerializer, ServiceRequestSerializer
from services.models import Service, ServiceRequest

class IsCompanyOrReadOnly(permissions.BasePermission):
    def has_permission(self, request, view):
        if request.method in permissions.SAFE_METHODS:
            return True
        return request.user.is_authenticated and request.user.user_type == 'company'

class ServiceViewSet(viewsets.ModelViewSet):
    serializer_class = ServiceSerializer
    permission_classes = [IsCompanyOrReadOnly]

    def get_queryset(self):
        queryset = Service.objects.all()
        category = self.request.query_params.get('category', None)
        if category:
            queryset = queryset.filter(category__slug=category)
        return queryset

    def perform_create(self, serializer):
        serializer.save(company=self.request.user.company_profile)

8. Advanced Form Processing with FormSets

For services with multiple attributes, I used Django’s formsets:

from django.forms import inlineformset_factory
from .models import Service, ServiceAttribute

def service_create_with_attributes(request):
    AttributeFormSet = inlineformset_factory(
        Service, ServiceAttribute, 
        fields=('name', 'value'), 
        extra=3, can_delete=True
    )

    if request.method == 'POST':
        form = ServiceForm(request.POST)
        if form.is_valid():
            service = form.save(commit=False)
            service.company = request.user.company_profile
            service.save()

            formset = AttributeFormSet(request.POST, instance=service)
            if formset.is_valid():
                formset.save()
                return redirect('service-detail', pk=service.pk)
    else:
        form = ServiceForm()
        formset = AttributeFormSet()

    return render(request, 'services/service_with_attributes.html', {
        'form': form,
        'formset': formset
    })

9. Leveraging Django Admin for Quick Internal Tools

Django’s admin site is incredibly powerful. I customized it for internal management:

from django.contrib import admin
from .models import Service, ServiceRequest, Category

@admin.register(Service)
class ServiceAdmin(admin.ModelAdmin):
    list_display = ('name', 'company', 'price', 'category', 'is_active')
    list_filter = ('is_active', 'category', 'company')
    search_fields = ('name', 'description', 'company__company_name')

    def get_queryset(self, request):
        qs = super().get_queryset(request)
        if request.user.is_superuser:
            return qs
        return qs.filter(company__user=request.user)

@admin.register(ServiceRequest)
class ServiceRequestAdmin(admin.ModelAdmin):
    list_display = ('service', 'customer', 'status', 'created_at')
    list_filter = ('status', 'created_at')
    date_hierarchy = 'created_at'

10. Middleware for Request Tracking

from .models import Service, ServiceView
from django.utils import timezone

class ServiceViewMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)

        # Check if this is a service detail page
        path_parts = request.path.strip('/').split('/')
        if len(path_parts) >= 3 and path_parts[0] == 'services' and path_parts[1] == 'detail':
            try:
                service_id = int(path_parts[2])
                service = Service.objects.get(id=service_id)

                # Record anonymous view
                ServiceView.objects.create(
                    service=service,
                    ip_address=self.get_client_ip(request),
                    user=request.user if request.user.is_authenticated else None,
                    viewed_at=timezone.now()
                )
            except (ValueError, Service.DoesNotExist):
                pass

        return response

    def get_client_ip(self, request):
        x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR')
        if x_forwarded_for:
            ip = x_forwarded_for.split(',')[0]
        else:
            ip = request.META.get('REMOTE_ADDR')

Don’t forget to add it to your settings:

MIDDLEWARE = [
    # ... other middleware
    'services.middleware.ServiceViewMiddleware',
]

Conclusion

Building Netfix with Django taught me how powerful and flexible the framework truly is. These advanced features – from custom user models to complex queries with annotations – enabled me to create a robust marketplace with clean, maintainable code.
What I appreciate most about Django is how it scales with your knowledge. As you discover more features, you can refactor and improve your application while maintaining backward compatibility

Testing catches these before your users do. This is a testing playbook for TypeScript MCP servers built on the official SDK.

The demo-to-production gap for MCP servers

The official TypeScript SDK makes it easy to get something working. A few tool registrations, an McpServer instance, a transport, and you are serving. The problem is that “working” in the demo sense and “working” in the production sense are different things.

A demo tests one happy path. Production tests edge cases that emerge from real clients: reconnects, concurrent tool calls, malformed inputs, slow downstream APIs, and the transport contract itself. None of those show up in a single manual run against your local instance.

The gap is not a criticism of the SDK. It is a consequence of how easy the SDK makes it to build a server without thinking about what breaks it. A test suite closes the gap before you ship.

What actually breaks: transport, sessions, tool contracts

Three categories fail most often.

Transport behavior. The SDK added Streamable HTTP support in version 1.10.0. Under this transport, the server exposes a single HTTP endpoint that handles both POST and GET. Clients use POST for tool calls and GET to open a streaming connection via server sent events. Tests that only exercise stdio miss this entirely.

Session state. The StreamableHTTPServerTransport is stateful per session. If you store anything in process memory keyed by session ID, a restart or a second instance will drop it. Tests that do not simulate reconnects miss this failure mode.

Tool contracts. Each tool you register has an input schema and an expected output shape. Tests that call tools with valid inputs only miss the cases where a client sends a slightly wrong shape or a downstream API returns something unexpected.

Unit-testing tools and resources in isolation

The cleanest place to start is the tool handler itself, before any transport is involved.

Each tool handler is a function that takes validated input and returns a result. Extract the handler logic from the server.tool() registration so you can call it directly in tests.

// tool-handlers.ts
export async function getItemHandler(input: { id: string }) {
  const item = await fetchItem(input.id);
  return { content: [{ type: "text", text: JSON.stringify(item) }] };
}

// getItem.test.ts
import { getItemHandler } from "./tool-handlers";

test("returns item content", async () => {
  const result = await getItemHandler({ id: "abc" });
  expect(result.content[0].type).toBe("text");
});

This pattern makes each handler independently testable without spinning up the full server. Stub the downstream calls with your test framework’s mocking utilities. Cover the happy path, malformed input, and downstream failure.

Resource handlers work the same way. Extract, test in isolation, stub dependencies.

Contract assertions against the MCP schema

After unit tests, the next layer checks that your tool registrations conform to the MCP protocol. A contract test instantiates the real server and sends actual protocol requests, then asserts on the response shape.

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { InMemoryTransport } from "@modelcontextprotocol/sdk/inMemory.js";
import { createServer } from "./server";

test("list tools returns registered tools", async () => {
  const server = createServer();
  const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();
  await server.connect(serverTransport);

  const client = new Client({ name: "test", version: "1.0.0" }, {});
  await client.connect(clientTransport);

  const result = await client.listTools();
  const toolNames = result.tools.map((t) => t.name);
  expect(toolNames).toContain("get-item");
});

The InMemoryTransport in the SDK is designed exactly for this. It lets you run client and server in the same process without any network, which keeps tests fast and deterministic.

Assert on the full response shape for each tool: input schema, output content types, error response format. This is the layer that catches the gap between what your server claims to support and what it actually returns.

Testing Streamable HTTP behavior

The in memory transport covers the protocol layer. Testing the HTTP transport layer catches a different class of failure: auth middleware, session header handling, and the streaming path.

Stand up a real HTTP server on a random port, run your requests against it, and shut it down after each test.

import { createServer as createHttpServer } from "http";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

let httpServer: ReturnType<typeof createHttpServer>;
let baseUrl: string;

beforeAll(async () => {
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: () => crypto.randomUUID(),
  });
  const mcpServer = createServer();
  await mcpServer.connect(transport);
  httpServer = createHttpServer((req, res) => transport.handleRequest(req, res));
  await new Promise<void>((r) => httpServer.listen(0, () => r()));
  const addr = httpServer.address() as { port: number };
  baseUrl = `http://localhost:${addr.port}`;
});

afterAll(() => httpServer.close());

test("POST returns a valid MCP response", async () => {
  const res = await fetch(`${baseUrl}/mcp`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", method: "tools/list", params: {}, id: 1 }),
  });
  expect(res.status).toBe(200);
  const json = await res.json();
  expect(json.result.tools).toBeDefined();
});

Add a test that opens GET on the same endpoint and confirms the SSE connection accepts. Add a test that sends an invalid session ID and checks the server handles it without crashing.

A CI setup that catches regressions

A test suite only helps if it runs consistently. For MCP servers, the minimal CI setup is:

• Unit tests on every commit (fast, no network)
• Contract tests via InMemoryTransport on every commit (still fast)
• HTTP transport tests on pull requests and on merge to main

If you deploy across multiple instances, add a test that starts two server processes and verifies that a session created on instance one can be resumed on instance two. This tests your external session store. It is slower, so running it on pull requests is reasonable.

If you are building an AI product that depends on your MCP server, the deployment and observability patterns in Next.js for AI products apply directly to the production layer above the server. For the enterprise session model, see MCP for enterprise agents.

FAQ

What is an MCP server?
An MCP server exposes tools, resources, and prompts to LLM clients via the Model Context Protocol. Clients connect to it and call tools by name, receiving structured results.

How do you test an MCP server?
Start with unit tests on each tool handler in isolation. Add contract tests using InMemoryTransport. Add HTTP transport tests against a local server instance for the full network path.

What transport does MCP use?
MCP supports stdio for local use and Streamable HTTP for networked servers. Streamable HTTP uses a single endpoint that handles POST requests for tool calls and GET requests for SSE streaming. The TypeScript SDK supports Streamable HTTP from version 1.10.0 onward.

Building production AI systems? I consult on agentic AI and AI product engineering at mudassirkhan.me.

Installing FFmpeg should be one decision: download. In practice, it’s a stack:

1. Which build to pick? Or, should I build it myself?
2. Which license variant (GPL vs LGPL, with or without --enable-nonfree)
3. Which codecs and accelerators (x264, x265, NVENC, QSV, VA-API, libfdk_aac, AV1)
4. Shared or static
5. Which OS and arch (Windows x64, Linux x86_64/ARM64, Apple Silicon, musl)
6. Whether you can legally redistribute it inside your own app

Most pages cover one slice and assume you already know the rest. So it turns into tab-hopping across release notes, comparing build matrices, and guessing whether the binary you grabbed will hit nvenc not found at runtime.

So I built ffmpeg.download. Answer a few questions — OS, what you need to encode/decode, whether you’re shipping it inside something — get a direct link to a specific build with its checksum and source.

Cases I built it for first:

1. ffmpeg: command not found on a server — static Linux build, no apt/yum dance
2. NVENC on Windows — a build that actually has the encoder compiled in
3. Embedding in a commercial app — LGPL build, redistribution-safe
4. Apple Silicon native — not Rosetta, not a generic universal binary
5. Reproducible CI — pinned versions with checksums
6. Managing your production enviroment with consistent ffmpeg versions

It’s a simple-to-use index of the trusted providers, filtered by what you actually need.

How to move from isolated hospital systems to event‑driven, FHIR‑based architectures in a context with poor connectivity and legacy vendors.

In many private clinics in Venezuela, “digital transformation” has meant installing a Hospital Information System (HIS) and maybe an Electronic Health Record (EHR). The problem is that most of these systems do not expose standard APIs, or do it in a very limited way.

As an engineer, the real challenge is not “going paperless”, but making systems talk to each other: getting lab, pharmacy, admissions, telemedicine and billing to exchange data without adding more technical debt.

In this post I’ll share a practical architectural approach, from a developer’s perspective, to move a typical clinic environment from ad‑hoc integrations to an HL7 FHIR + event‑driven architecture.

The starting point: interoperability level 1–2
In practice, most clinics I work with operate like this:

Manual CSV or PDF exports.

Occasional point‑to‑point HL7 v2 interfaces (if you’re lucky).

No formal API documentation.

Human “copy‑paste” processes between systems.

In HIMSS terms, that’s level 1–2 interoperability. A realistic technical goal is to bring critical systems up to level 3 (semantic), where data means the same thing everywhere.

Why FHIR fits this environment
FHIR brings several properties that are extremely valuable in this context:

API‑first. Everything revolves around HTTP resources.

Well‑known structures. JSON with clear fields for Patient, Observation, Encounter, Medication, etc.

Mature implementations. HAPI FHIR in Java, for example, lets you spin up a server quickly.

A minimal viable pattern looks like this:

Deploy a FHIR server (e.g., HAPI FHIR) as the central point.

Expose a small, focused subset of resources for the first use case: Patient, Encounter, Observation, Medication, DiagnosticReport.

Build one adapter per legacy system that:

Consumes events or exports from the source system.

Transforms them into the corresponding FHIR resource.

Publishes them to the FHIR server via its REST API.

Integration layer: avoiding point‑to‑point hell
Without an integration layer, every integration is a fixed pair of systems. With ten systems, you have forty‑five possible pairs.

Recommended architecture:

An event bus (Apache Kafka for high‑volume scenarios, RabbitMQ for more modest loads).

Microservices (Java + Spring Boot, for example) responsible for:

Subscribing to domain‑specific topics (lab, pharmacy, admissions, etc.).

Transforming messages to the FHIR model.

Publishing to the FHIR server.

In parallel, an integration engine like Mirth Connect can simplify HL7 v2 → FHIR handling.

This shifts the problem from “every system talks to every other system” to “every system talks to the bus”, and “the bus talks FHIR to the outside world”.

Dealing with unreliable connectivity
In Venezuela, you simply cannot assume stable connectivity, not even within the same city. From a software architecture standpoint, this means:

Implementing the Outbox Pattern in source systems.

Using local queues to buffer events when the connection is down, and flush them when it comes back.

Designing idempotent consumers on the event bus side to avoid duplicates and inconsistencies.

From this perspective, the FHIR server becomes the consolidated source of truth, but local systems must still be able to operate with a subset of data while offline.

Security by design, not as an afterthought
Two concrete recommendations:

• For client applications (web, mobile, clinical front‑end): SMART on FHIR on top of OAuth 2.0, with fine‑grained scopes per resource.
• For server‑to‑server integrations: OAuth 2.0 with trusted clients, managed certificates and TLS 1.3 everywhere.

Trying to “bolt on” security at the end is a terrible idea in a domain where data is, by definition, highly sensitive.

Conclusion and next steps
If you’re in a similar environment (private clinic in LATAM with multiple legacy systems) and want to start working with FHIR, my suggestion is:

Pick one small but critical use case (for instance, integrating lab results into the EHR).

Stand up a FHIR server with a minimal resource model.

Build a single adapter for one source system.

Add the event bus and security from day one, even if you only have a couple of systems.

From there, adding new systems becomes a repeatable pattern, not a heroic project every single time.

Call to action for dev.to
If you’re working on healthcare interoperability in LATAM and want to compare architectures or trade war stories, I’d be happy to connect. You can find more details and case studies at codebymelendez.com or reach out to me on LinkedIn.