DEV Community: Sam Farahmand

Docker Is Not Dead (Stop Writing That Headline)

Sam Farahmand — Wed, 10 Sep 2025 18:21:02 +0000

Every few months, someone posts a hot take: "Docker is dead. Time to move on."
Nope. Not dead. Not even close. Docker is alive, drinking coffee, and still running your local stack while you type your LinkedIn rants.
Why the drama? Because Kubernetes removed its dockershim back in v1.24 and standardized on containerd/CRI-O. That broke… absolutely nothing for your Docker-built images. They're still OCI images, they still run everywhere. The only thing that died was a shim.

What the haters say

The Daemon Thing. Docker runs a root-level daemon (dockerd). If you hand someone access to docker.sock, you basically gave them root. Rootless mode exists but isn't universal.
Kubernetes dropped dockershim. True - but it just switched runtimes. Your images still run fine. Licensing & Money. Docker Desktop is free for small teams, paid for bigger ones. Finance noticed.
Pull Limits. In 2025, Docker Hub tightened free pulls. Paid users now get unlimited pulls (fair use). CI pipelines had to authenticate or mirror.
Shady Images. Public Hub images sometimes contain junk or even malware. If you docker pull randomstuff123, that's on you.
Alternatives exist. Podman, nerdctl, and containerd are legit. Especially if you hate daemons or subscriptions.

Fair complaints. Still not a funeral.

What actually happened

Kubernetes standardized; Docker specialized.
K8s stopped babysitting Docker, and Docker leaned harder into dev workflows.

Builds: BuildKit + Buildx are now default. Faster builds, smarter caching, multi-arch without crying.
Compose: docker compose up is still the fastest way to stand up a stack locally. Now with Compose Bridge, you can even spit out Kubernetes manifests when you're ready to promote.
Content & security: Verified Publishers, Official Images, and Docker Scout help you dodge shady pulls. And yes - Docker is retiring Docker Content Trust (DCT) for Official Images, moving toward Sigstore/Notation.
Hardening: Docker Engine 28 flipped defaults: unpublished ports are no longer reachable from your LAN. Secure by default, fewer surprises.
New domains: Docker's 2025 push into AI/agent apps with GenAI Stack and Compose patterns. Dead platforms don't ship new features every quarter.

Why Docker still matters in 2025

Local Dev Experience. Still the easiest way to go repo -> running app on macOS, Windows, Linux. (Yes, Desktop runs in a VM on macOS/Windows, but performance keeps improving with VirtioFS and Synced Shares.)
Build Once, Run Anywhere. Docker-built OCI images run fine on containerd, CRI-O, Podman. That's the whole point.
Ecosystem Gravity. Testcontainers, dev containers, endless tutorials - most expect a Docker-API–compatible runtime.
It Just Works. Sure, you could handcraft containerd configs. But do you really want to?

Practical advice

Use Docker for dev and builds.
Run containerd/CRI-O in Kubernetes. Your images won't care.
Harden the basics: rootless mode, non-root containers, scans, digest pinning, trusted registries.
If Hub limits hurt: authenticate, mirror, or pay (paid = unlimited pulls).
Plan ahead: DCT is being retired -> move to Sigstore/Cosign/Notation.

The punchline

Docker isn't dead. It just grew up.
Kubernetes standardized runtimes; Docker doubled down on being the default developer platform: builds, Compose, trusted content, security, even AI workloads.

You can grumble about daemons or Desktop pricing, but here's the truth: Docker remains the fastest, friendliest way to get real work done - and the images it produces run everywhere that matters.
So next time you see "Docker is Dead", just reply with the obvious:
"Nah, it's still alive. And it just built my app in 3 seconds flat."

Finally: A 15-Second Fix for Local Referrer & Attribution Testing

Sam Farahmand — Fri, 05 Sep 2025 15:56:16 +0000

Preview attribution flows before production - works with Adobe, GA4, Target, and Piano.

Here's the problem: you can't preview referrer-driven locally. Browsers don't send a real Referer or fill document.referrer the way they do in production. That leaves Growth, Marketing, Analytics, Experimentation, and QA teams flying blind until things are live-when dashboards suddenly scream "Direct/None" and someone inevitably asks if Adobe is broken. Fun (it's not, this time).

The fix is surprisingly simple (Which is ironic, because the browser is basically running an obstacle course behind the scenes). All you have to do is act like the referrer for a moment over HTTPS, then jump straight into your app. The browser sets a real referrer - no extensions, no flags, no staring at a waterfall of requests in the network tab while your coffee gets cold.
And it works everywhere: Adobe Analytics/Experience Cloud, Adobe Target, Piano, GA4 - any tool that makes you argue about attribution.

Why it fails locally

Browsers are picky. Open a link from your terminal and hit a top-level 302? Some drop document.referrer. Serve your app without a "real" HTTPS origin? Same result. Local ≠ production, which is why pre-launch checks for campaigns, partners, and paywalls feel like guesswork - or weather forecasting.

We don't need to fight the browser; we can play by its rules for five minutes: look like the referrer, then redirect.

Meet Reflex (the Fix)

To make that easier, I built a tiny helper called Reflex. It's a simple CLI that handles the annoying setup for you so you can test referrer-driven flows locally without wrestling with configs or browser quirks.

What Reflex does

Point the referrer host (e.g., news.google.com) at your machine for a moment.
Serve a tiny HTTPS page using a locally trusted certificate.
Redirect into your app so the browser sets a real Referer and document.referrer.

You can do this with a small CLI, reflex. It updates your hosts file with a tagged entry, spins up HTTPS, and opens your browser in private mode so each run is clean. Push button, receive referrer.

15-Second Setup

One-time setup: share the same local CA between root and your user so browsers trust the certs.

# Assume you already installed mkcert

sudo mkcert -install
mkcert -install

# required in Linux
sudo mkdir -p /etc/mkcert
sudo cp -a "$(mkcert -CAROOT)/." /etc/mkcert/
sudo chmod 755 /etc/mkcert && sudo chmod 644 /etc/mkcert/*

Then run a flow using reflex (deep breath, two commands):

sudo reflex run \
  --referrer https://news.google.com \
  --target   https://your-app.example

What happens: it opens a private window (will do his best), serves a tiny HTTPS "referrer" page, and sends you to your app with a real Referer - so tags, SDKs, and experiments act like the real world.

Cleanup (It does it on exit though):

sudo reflex cleanup --referrer news.google.com

# OR if you are too lazy (just like me 😅)

sudo reflex cleanup --all

Pick your redirect

meta (default): the reliable workhorse. Short HTML meta refresh - best bet for a stable document.referrer.
js: same idea, different flavor. Quick window.location after a beat.
302: the spicy one. Great for testing 302 behavior, but some browsers drop document.referrer on top-level 302s opened externally. Choose with care.

Who benefits (and how)

Growth/Marketing: confirm attribution before launch so dashboards don't go "Direct/None".
Analytics/Tagging: validate Adobe Analytics/Experience, Piano, GA4 events with correct referrer and UTM context.
Experimentation: verify A/B targeting rules (Adobe Target, Piano) actually trigger.
QA/E2E: write stable tests for referrer-sensitive flows without staging contortions.
Data/BI: reduce "mystery traffic" and post-deploy fire drills.

Gotchas (quick fixes)

Need the full referrer URL, not just origin? Add --referrer-policy unsafe-url.
Corporate VPN/DNS agents can override /etc/hosts. If it seems ignored, that's the culprit. Thanks, security.
Private/incognito keeps runs clean and reduces "why does this only happen on my machine?" moments.
Requires admin rights (hosts + binding to 443). If 443 is busy, reflex falls back to 8443.

Bottom line

This is the missing local preview: see how your site behaves under a specific referrer before you ship. Emulate the referrer, redirect once, and your browser plays by real-world rules. Your analytics tools (Adobe Analytics/Experience, Piano, GA4, etc.) get proper context, experiments behave, and your team gets their evening back (maybe the weekend, too).

If you want the CLI that does this, it's reflex. Use it, tweak it, or copy the idea - the key is giving your browser the polite intro it expects.
Source and Binary on Github: https://github.com/samfrm/reflex

Python vs PHP vs Go vs Node.js: Which Backend Should You Pick in 2025?

Sam Farahmand — Tue, 02 Sep 2025 22:11:10 +0000

After building and shipping with Python, PHP, Go, and Node.js, here’s a field-tested breakdown of when each one actually makes sense in 2025.

Why I wrote this post?

With the rise of #vibecoding, a lot of friends and teammates are spinning up side projects, prototypes, and MVPs.

The recurring question I get is: “Which backend language should I use to move fast without boxing myself in later?”

AI can give generic answers; this post is my field-notes version after shipping with Python, PHP, Go, and Node.js.

Backend Languages for Prototyping (2025 Edition)

Quick Comparison Table

Criteria	Python	PHP	Go (Golang)	Node.js (JavaScript)
Performance	Medium (interpreted)	Medium (improved since PHP 8)	High (compiled)	High (generally below Go in throughput)
Learning curve	Very easy	Easy	Moderate (static typing)	Moderate (JS quirks, tooling choices)
Concurrency model	Threads/async; GIL caveats	Request-per-process; async libs exist	Goroutines + channels	Event loop (async, non-blocking)
Community maturity	Large and stable	Large (CMS/eCommerce heavy)	Mature, infra-focused	Large and very active
Popular frameworks	Django, FastAPI, Flask	Laravel, Symfony, WordPress	Gin, Fiber, gRPC	Express, NestJS, Next.js (API routes)
Best fit	APIs, data/ML services, prototypes	CMS, content sites, SMB e-commerce	Microservices, infra, APIs	Real-time apps, full-stack JS
Scalability	Moderate (infra dependent)	Low–Moderate (great for CMS)	High (great for microservices)	High (scale via clustering/workers)
Deployment ease	Solid for containers/serverless	Easiest on shared hosting	Excellent (single static binary)	Solid for serverless & JS-centric stacks

2025 Ecosystem Trends

Language	Trend (2025)	Notes
Python	Steady (strong)	ML/AI + modern API stacks keep it relevant
PHP	Declining (new apps)	Still dominant for CMS and existing stacks
Go	Rising (cloud/infra)	Microservices & infra teams keep adopting it
Node.js	Steady (JS default)	Real-time + full-stack JS; Bun/Deno are interesting

Python: the “get-it-done” toolkit

Python remains the fastest way I know to stand up an API that talks to a model, a database, or a notebook. The ecosystem around FastAPI (type hints + Pydantic) and Django (batteries included) is hard to beat for developer velocity.

Why I reach for it

Clean, readable code; fast time-to-first-endpoint
Libraries everywhere (data/ML, ORMs, auth, queues)
Great DX for schema validation (Pydantic) and docs (OpenAPI out of the box with FastAPI)

Tradeoffs

Throughput is lower than Go (even with uvicorn + gunicorn)
Concurrency always needs thought (GIL; pick async stacks deliberately)

Gotchas I’ve hit

Environments: use uv/poetry or containers early to avoid “works on my machine”
Async mixed with sync libraries can silently block your event loop
NumPy/PyTorch dependencies can bloat Docker images—multi-stage builds help

Tiny example (FastAPI)

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello from Python backend!"}

PHP: the pragmatic workhorse (especially for CMS)

If your problem looks like “publish content quickly and manage it well,” PHP is still the shortest path to value. Laravel is a genuinely pleasant modern framework; WordPress still powers a huge chunk of the web.

Why I reach for it

Instant hosting almost anywhere; frictionless deploys
Laravel’s DX (migrations, queues, mail, auth) is underrated
WordPress for content sites when time-to-market wins

Tradeoffs

Less mindshare for brand-new, API-first apps
Legacy code and plugin ecosystems can be messy

Gotchas I’ve hit

Mixing bespoke code with heavy WordPress plugins complicates upgrades
Async/concurrency exists (Swoole/ReactPHP) but is niche—plan for classic request/response

Tiny example

<?php
echo "Hello from PHP backend!";

Go: performance, simplicity, and easy ops

Go shines when you need predictable performance and simple operations. Small static binaries, fast startup, and a standard library that covers the basics.

Why I reach for it

Concurrency is first-class (goroutines, channels)
One binary, fast startup → ideal for containers, CLIs, microservices
Straightforward standard library; great for infra/service glue

Tradeoffs

More boilerplate than Python/JS; fewer batteries included
Generics exist but are intentionally conservative

Gotchas I’ve hit

Error handling is explicit; build helpers, don’t fight it
JSON + omitempty + pointers vs values can surprise newcomers
Migrations: pick one tool early (e.g., golang-migrate)

Tiny example

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "Hello from Go backend!")
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Node.js: real-time and one-language everywhere

Node.js is still the default for teams that want to stay in JavaScript end-to-end and ship real-time features quickly. The ecosystem is gigantic and modern frameworks have strong opinions (which can be a blessing).

Why I reach for it

Real-time (WebSockets) and streaming are first-class
One language across frontend/backend reduces cognitive load
Next.js/NestJS provide structure without too much ceremony

Tradeoffs

Historically messy ESM/CJS module story (better now, still a footgun)
Raw throughput trails Go in many benchmarks; scale horizontally early

Gotchas I’ve hit

Package churn: pin versions and use lockfiles religiously
Long tasks can block the event loop—move them to workers/queues
Serverless cold starts vary by provider/runtime—measure, don’t assume

Tiny example (Express)

const express = require('express');
const app = express();

app.get('/', (_req, res) => res.send('Hello from Node.js backend!'));

app.listen(3000, () => console.log('Server running on :3000'));

When to use what (pragmatic picks)

Situation	My default choice
Need an API this week, minimal ceremony	Python (FastAPI)
Content-heavy site, editors need to move fast	PHP (WordPress/Laravel)
Performance-critical service or many small services	Go
Real-time features or full-stack JS team	Node.js
Heavy ML/data integration	Python
Existing WordPress ecosystem to extend	PHP

Deployment notes that actually matter

Python: Use uvicorn/gunicorn behind a reverse proxy. For serverless, keep dependencies lean; pydantic/NumPy can impact cold start.
PHP: Dead-simple on shared hosting; for Laravel, run queues/schedulers as services and cache your config/routes.
Go: Multi-stage Docker builds produce tiny images; health checks + readiness probes make rollouts painless.
Node.js: Use a process manager (PM2) or containers. Offload CPU-heavy work to worker threads or a queue. Measure event-loop lag.

Final thoughts

Picking a backend language is less about hype and more about fit for your team, your problem, and your runway.

If I’m building an MVP API or anything ML-adjacent, I start with Python (FastAPI).
If I need real-time features or my team is JS-native, I go Node.js.
If I’m building small, fast services that I’ll operate for a while, I pick Go.
If the project is content-first (marketing site, editorial workflows, SMB e-commerce), PHP still ships fastest.

Architecture, testing, and deployment discipline will move the needle more than the language. Choose the stack your team can actually maintain, and optimize for feedback cycles.

Your turn

What are you shipping with this year, and why? I’m especially curious about teams moving from Node → Go for specific services, or from Python → Node for real-time features. Let me know in the comments.