The Ultimate Prompt for a Production-Ready Flask Web App (v2 – With Message Queue & Streaming)

Posted on January 18, 2026 by Peter Andersson

Version 1 of this prompt focused on getting authentication, security, UI structure, database discipline, and deployment right.

Version 2 goes one step further.

Modern web apps rarely live in isolation — they consume events, market data, logs, jobs, or background signals. This version adds:

A message queue (Kafka, RabbitMQ, or ZeroMQ)
A clean event ingestion layer
Real-time streaming from the backend to web clients
Without forcing React, WebSockets everywhere, or microservice chaos

The goal is still the same:

One prompt → a deployable, production-grade web app — now event-driven.

✅ The Prompt (Version 2 – Copy/Paste)

You are a senior full-stack + DevOps engineer. Build a production-ready webapp
with secure login AND server-side message streaming to web clients.

BASELINE DEFAULTS (use these unless I explicitly override):
- CSS framework: Bootstrap 5
- App structure: classic multi-page (Jinja templates)
- Database default: MySQL 8 (SQLAlchemy + PyMySQL)
- Optional lightweight alternative: SQLite (only if explicitly selected)
- Auth/session: Flask-Login with server-side sessions (NOT JWT)
- Messaging default:
  - Lightweight: ZeroMQ or RabbitMQ
  - Heavy/streaming workloads: Kafka
  (Pick the simplest valid option unless I say otherwise)

FIRST: Ask me ONLY these questions (no code yet):
1) System name (slug + display name)
2) Domain name (e.g. app.example.com)
3) OS target (Ubuntu 22.04/24.04) and deploy user
4) Backend bind port on localhost (default 8000)
5) OAuth providers: Google, Facebook, plus any of: GitHub, Microsoft, Apple
6) Do we also support email+password? (yes/no)
   - If yes: require email verification? (yes/no)
7) Database choice:
   - MySQL 8 (default, production)
   - SQLite (simple deployments / low volume)
8) Message queue choice:
   - ZeroMQ (in-process / local / ultra-lightweight)
   - RabbitMQ (durable jobs & fanout)
   - Kafka (high-throughput, replayable streams)
9) Event delivery to browser:
   - Server-Sent Events (SSE)
   - WebSockets
   - Polling fallback (if SSE/WebSockets unavailable)
10) UI layout preference: top-nav, sidebar, or both
11) Theme: light only, or light/dark toggle
12) Welcome/onboarding page:
    - enabled by default? (yes/no)
    - disable mechanism: global env flag, per-user toggle, or both
13) Demo pages to include (pick 3–6):
    dashboard, profile, settings, admin, docs, pricing, design-system, live-stream
14) Branding: primary color + logo text

AFTER I ANSWER, GENERATE THE ENTIRE PROJECT as one cohesive deliverable.

Required deliverables:
A) Concise architecture overview (max ~1 page)
B) A single bash script `setup.sh` that writes the entire project
   (assume project dir exists and venv is activated)
C) `.env.example`, `README.md`, `RUNBOOK.md`
D) Deployment assets:
   - systemd unit for gunicorn (127.0.0.1:<port>)
   - systemd unit for message consumer(s) if needed
   - Nginx reverse proxy config
   - deploy scripts: install deps, configure nginx, configure systemd,
     restart/reload, view logs
   - always test nginx config before reload
E) Verification checklist

Backend architecture requirements:
- Flask app factory pattern
- Blueprints:
  - auth
  - main
  - settings
  - stream (or events)
- SQLAlchemy + Flask-Migrate/Alembic
- Identical models and migrations for MySQL and SQLite
- SQLite rules:
  - Enable foreign keys
  - Warn about concurrency limits
- MySQL rules:
  - pool_pre_ping enabled
  - sane pool sizing defaults

User & auth requirements:
- User model:
  id, email (nullable if OAuth-only), display_name,
  created_at, last_login_at, is_admin, welcome_enabled
- OAuth identities table
- OAuth via Authlib (or equivalent mature library)
- Account linking/unlinking with lockout prevention
- Flask-Login sessions with secure cookies:
  Secure, HttpOnly, SameSite
- ProxyFix enabled behind Nginx
- CSRF everywhere (Flask-WTF), logout via POST
- Rate-limit auth endpoints
- Safe redirect handling
- Security headers via Nginx:
  HSTS (when HTTPS), X-Frame-Options, Referrer-Policy, basic CSP

Messaging & streaming requirements:
- Introduce a clear separation:
  - Producer(s): push messages into the queue
  - Consumer(s): read messages and forward to web layer
- Support selected message queue:
  - ZeroMQ: PUB/SUB or PUSH/PULL
  - RabbitMQ: exchanges + queues (fanout/topic)
  - Kafka: topics + consumer groups
- Messages must be JSON-serializable with:
  type, timestamp, payload, optional key

Streaming to browser:
- Implement a backend streaming endpoint:
  - SSE endpoint (`text/event-stream`) OR
  - WebSocket endpoint (if selected)
- Auth-protected streams (user must be logged in)
- Ability to:
  - stream all events
  - or filter by topic/type
- Graceful reconnect handling
- Backpressure / buffering notes documented

Frontend/UI requirements:
- Bootstrap 5 multi-page UI
- Auth-aware navigation
- Live Stream demo page:
  - shows real-time events from message bus
  - visually updates without page reload
  - minimal JavaScript (no framework unless necessary)
- Dashboard may optionally show live widgets fed by stream
- Flash messages styled
- Error pages: 404 and 500

Operational requirements:
- Message consumers must:
  - run as systemd services OR background threads (document choice)
  - log to journald
  - shut down cleanly
- Health endpoints:
  - /healthz (no DB, no MQ)
  - /readyz (DB + message queue connectivity)
- Clear instructions for starting/stopping message services

Quality requirements:
- ruff + black configuration
- Minimal pytest suite:
  - auth protection
  - CSRF enabled
  - redirect safety
  - stream endpoint requires authentication
- .editorconfig and .gitignore
- requirements.txt with pinned versions
- Clear local run + deployment instructions

Output rules:
- Do not ask additional questions beyond the list.
- After my answers, output in this order:
  1) Architecture overview
  2) setup.sh
  3) Message queue setup notes
  4) OAuth provider setup steps
  5) Deployment instructions
  6) Verification checklist

Make sensible defaults if answers are missing, and state them clearly.

🔍 What’s New in Version 2 (Detailed Explanation)

1. Message Queue as a First-Class Component

Instead of background threads “just doing stuff”, v2 forces an explicit message bus.

This gives you:

Decoupling
Replayability (Kafka)
Fanout (RabbitMQ)
Ultra-low latency (ZeroMQ)

And most importantly: a clean mental model.

2. Clear Producer → Consumer → Web Flow

The prompt enforces separation:

[ Producers ] → [ Message Queue ] → [ Consumers ] → [ Web Stream ]

This prevents:

Web requests doing heavy work
Tight coupling between UI and ingestion
“Flask but secretly async chaos”

3. Streaming Without SPA Madness

Instead of React + Redux + WebSocket hell:

SSE by default
WebSockets only if explicitly selected
Minimal JavaScript
Works perfectly with Flask + Gunicorn + Nginx

This is intentional and pragmatic.

4. Auth-Protected Real-Time Data

A common mistake: public streams.

This prompt forces:

Flask-Login protected stream endpoints
User-aware filtering
Proper session handling behind Nginx

No accidental data leaks.

5. Systemd-Managed Consumers

Message consumers are operational citizens:

systemd services
journald logs
health checks
graceful shutdown

This matches how real servers behave.

6. Live Stream Demo Page

Instead of “trust me, it works”:

A dedicated page
Real-time updates
Visual proof of event flow

This page becomes:

a debugging tool
a demo
a future dashboard seed

🧠 Final Thoughts

Version 2 turns the app into a true event-driven system, while still keeping:

Flask
Bootstrap
Classic multi-page architecture
Clean deployment
Human-readable code

You now have:

A secure web app
A message bus
Live data flowing to users
Zero unnecessary frontend complexity

Development