How it works

What actually happens when you use a tool here.

Not a marketing diagram — this is the real request path for each service, built from what's actually running: FastAPI, Socket.IO, yt-dlp, gallery-dl, FFmpeg, JWT auth, and SQLite. Scroll through, or jump to one below.

Request lifecycle Authentication Download & convert Live monitoring
01 — Every request

Browser to backend and back.

Whatever tool you're using, the request takes the same basic path before it branches into service-specific work.

Your Browser Idempotency gate (POST/PUT/PATCH) Security gate rate limit · blocked IPs bot shield Visitor tracker async, batched Route handler checks its own auth via DI SQLite (WAL) Response + security headers
1
Idempotency gate checks for an Idempotency-Key header on write requests. If it's seen that key before, it replays the cached response and skips everything else.
2
Security gate runs a per-IP token-bucket rate limit (1200 req/min signed in, 600 anonymous), checks against a blocked-IP list, and scores requests against known scanner patterns high scores get tarpitted or silently 404'd.
3
Visitor tracker logs the request to an analytics queue, flushed to the database in batches by a background task it doesn't block the response.
4
The route handler itself checks auth, via dependency injection, not a global middleware step see below.
5
Anything that needs to persist reads or writes through SQLite in WAL mode, with a background task periodically checkpointing the WAL file.
6
The response goes back with security headers attached (CSP with a per-request nonce, HSTS, and others) and a request ID.
02 — Authentication

Signing in, and staying signed in.

Every account is stored with a bcrypt hash (cost factor 12) never the plain password. Sessions are JWT tokens (HS256), backed by a session row in the database.

Password bcrypt compare JWT issued 24h expiry Rejected Session row 7 day expiry Bearer token Per-route DI get_auth_context

Each protected route declares a dependency (Depends(get_auth_context)) rather than going through a global auth middleware it reads the bearer token, looks up the session row, and hands the route an AuthContext with the user's id, username, and role. That's also where ownership gets checked before a route lets you view or change anything of yours. When the JWT expires but the session row hasn't, POST /api/auth/refresh issues a new one without a full re-login. Guest sessions (30-minute TTL, no refresh) work the same way with a placeholder user.

03 — Download & convert

What happens when you paste a link, or drop a file.

Two different tools, one shared pattern: the request returns a job id immediately, and a background thread does the actual work while your browser polls for progress.

Downloader
Paste a URL
Server creates a job record and returns a job id right away
Background thread runs yt-dlp / gallery-dl
TikTok falls back to a Playwright-based extractor if yt-dlp's fails
MP4s get an FFmpeg pass
Normalizes to H.264/AAC with a faststart moov atom
Browser polls the job
queued → downloading → done, no realtime push for this one
File ready to save
Job directory is cleaned up after an hour either way
Converter
Upload a file
Video, audio, image, or document up to 200 MB
Job created, background thread starts
Same queued → converting → done pattern as the downloader
FFmpeg or LibreOffice, depending on format
Video/audio/image via FFmpeg; documents via LibreOffice
Browser polls the job
No hard concurrency limit each job gets its own thread
Converted file ready to save
Once the job status flips to done
04 — Live monitoring

How the status indicators stay current.

Your browser opens one persistent Socket.IO connection to the backend. On connect, the server broadcasts a services_status_update event with the full service list and sends it again whenever the page explicitly asks for a refresh, so the dots update without a page reload.

HomeNode FastAPI + Socket.IO Live
Samba Network file sharing Active
Auth System JWT + bcrypt, session-backed Active
The same connection carries other real-time events too music now-playing state, partner presence, and (in the admin view) a live security feed of blocked/tarpitted requests each scoped to its own Socket.IO room so you only get updates relevant to you.
Want the backend detail behind your own project?

This is the same engineering I build for clients.

If you're evaluating whether I can build something like this for you, happy to walk through the actual architecture.