Vývoj backendu pomocí Flask a Django

Flask vs. Django: kdy který framework zvolit

Flask a Django jsou dvě nejrozšířenější Python platformy pro vývoj backendu. Flask je mikro-framework s minimalistickým jádrem, který dává velkou svobodu v architektuře a volbě knihoven. Django je plnohodnotný framework typu „batteries-included“ se silnou konvencí, integrovaným ORM, autentizací, administrací a šablonováním. Výběr závisí na požadavcích projektu, velikosti týmu a očekávané životnosti řešení.

Architektonické paradigmy a konvence

• Flask: preferuje explicitní rozhodování – vy si skládáte router, ORM, validační vrstvu, DI i background úlohy. Vhodné pro lean služby, mikroslužby, prototypy a vysoce customizované architektury.
• Django: prosazuje „konfiguraci skrze konvence“. Aplikační struktura je předem daná (aplikace, modely, pohledy, šablony), díky čemuž je onboarding a škálování týmu jednodušší.

Modulární srovnání podle klíčových oblastí

Datová vrstva a migrace: SQLAlchemy vs. Django ORM

Ve Flasku je nejčastější volbou SQLAlchemy (Core + ORM). Nabízí expresivní dotazování, relační joins, eventy a skvělou práci s triggery či pohledy; migrace řeší Alembic. Django používá vlastní ORM s deklarativními modely, automatickými migracemi a admin rozhraním. Pro komplexní reporty a analytické dotazy je výhodné kombinovat ORM s raw SQL.

API návrh: REST, GraphQL a serializace

• REST: ve Flasku často Flask-RESTX/Flask-Smorest; validace pomocí Marshmallow či Pydantic. V Djangu je standardem DRF s viewsety, routery, throttlingem, paginací a browsable API.
• GraphQL: Flask integruje Graphene či Ariadne; Django má Graphene-Django s mapováním na modely.
• Serializace: Flask – Marshmallow/Pydantic; Django – DRF Serializers, ModelSerializers.

Asynchronní zpracování, WebSockety a realtime

Pro dlouhotrvající úlohy použijte Celery (broker RabbitMQ/Redis). Realtime komunikace:

• Flask: Flask-SocketIO (pod WS/long-polling), pro čisté ASGI zvážit Quart/Starlette interoperabilitu.
• Django: Django Channels pro WebSockety, skupiny a presence; přirozená integrace s ASGI servery.

Bezpečnostní standardy pro produkční backend

• HTTPS a HSTS, správné Secure/HttpOnly cookies, SameSite politika.
• CSRF ochrana (ve Flasku rozšíření, v Djangu vestavěná).
• Rate limiting a ochrana proti bruteforce (Flask-Limiter, DRF throttling).
• Secret management: prostředí (.env, Vault), rotace klíčů, žádná tajemství v repozitáři.
• Input validace a sanitace; schema-driven kontrakty (OpenAPI/JSON Schema).

Konfigurace, prostředí a 12-factor discipliny

• Oddělení konfigurace od kódu, hierarchie settings pro dev/stage/prod.
• Immutabilní buildy, container-first nasazování, stateless procesy.
• Standardizované logování (JSON), korelace požadavků, metriky a tracing.

Testování a kvalita: unit, integrační a end-to-end

• Unit testy: pytest, izolace byznys logiky, mocking externích služeb.
• Integrační testy: testovací klient Flask/Django, in-memory DB nebo kontejnerizovaný Postgres.
• E2E: Playwright/Cypress na API/UI vrstvě, smluvní testy s OpenAPI.
• Kontinuální integrace s coverage gates, statická analýza (ruff, mypy), pre-commit hooky.

Šablonování, server-side rendering a headless přístup

Flask používá Jinja2, Django má vlastní šablonovací engine. Pro headless architektury exportujte čisté JSON/GraphQL API a frontend řešte separátně (React/Vue/Svelte). U projektů s důrazem na SEO lze kombinovat SSR a API (Django templates/HTMX, Flask+Jinja + progressive enhancement).

Statická média a soubory

• Flask: obsluha statik přes reverzní proxy (NGINX), verzování a CDN; nahrávání přes rozšíření (Flask-Uploads) nebo vlastní logiku.
• Django: collectstatic, storage backends (S3, GCS), per-env nastavení a URL podpisy.

Vrstvy aplikace a doporučená architektura

• Prezentace: views/blueprints, DRF viewsety, serializéry.
• Doména: službová vrstva (use-cases), čistá byznys logika bez framework závislostí.
• Data: repository pattern nad ORM, transakční hranice, jednotky práce.
• Integrace: klienti na externí služby (HTTP, gRPC, message bus), definované ports/adapters.

Výkon: latence, propustnost a optimalizace dotazů

• Profilování (py-spy, cProfile), APM (OpenTelemetry + backend).
• Caching: aplikační (Flask-Caching, Django cache framework), datový (Redis), HTTP (ETag/Cache-Control).
• Optimalizace dotazů: select_related/prefetch_related v Djangu, joinedload/subqueryload v SQLAlchemy.
• Asynchronní I/O pro čekací operace (síť, FS), batchování a bulk operace.

Autentizace a autorizace

• Session-based: jednoduché pro tradiční weby; CSRF ochrana nutností.
• Token-based: JWT, OAuth 2.0, OIDC; integrace s identity providery.
• Role a práva: v Djangu vestavěné Permissions/Groups; ve Flasku knihovny jako Flask-Principal nebo vlastní policy vrstva.

Tvorba admin rozhraní a backoffice

Django admin akceleruje CRUD nad daty a je ideální pro interní nástroje či správu katalogů. Ve Flasku lze kombinovat Flask-Admin/Flask-AppBuilder, případně postavit admin jako samostatnou SPA nad API. Klíčové je auditování akcí, granularita oprávnění a exporty (CSV/Excel).

Observabilita: logy, metriky a tracing

• Strukturované logy s korelačním request-id a uživatelským kontextem.
• Metriky (prometheus klient), SLA/SLO a alerting na chybovost, latenci a saturaci.
• Distribuovaný tracing (OpenTelemetry) pro sledování volání mezi službami.

Nasazení: WSGI/ASGI servery, kontejnery a CI/CD

• Servery: Gunicorn/Uvicorn/Hypercorn; NGINX/Envoy jako reverzní proxy.
• Kontejnery: vícefázové buildy, minimální báze (alpine/ubi-micro), distroless runtime.
• CI/CD: testy, bezpečnostní skeny, migrace před startem, healthchecks a postupné nasazení (blue-green/canary).

Monolit, modulární monolit nebo mikroslužby?

Django tradičně exceluje v monolitech a modulárních monolitech s jasnými hranicemi aplikací. Flask je přirozený kandidát pro mikroslužby. Rozhodnutí má vycházet z team topology, nezávislosti domén, rychlosti nasazení a požadavků na koordinační overhead (smluvní testy, verzování API, observabilita mezi službami).

Práce s dlouhými úlohami a plánováním

• Celery pro asynchronní fronty (ETL, notifikace, thumbnailing), plánování přes beat nebo externí orchestrátory.
• Transactional outbox vzor pro spolehlivé publikování událostí (Kafka, RabbitMQ).

Doménově řízený návrh v Python backendech

Bez ohledu na framework zvažte DDD principy: agregáty, entity, value objekty, doménové události. Izolujte doménu od frameworku, aby byla testovatelná a přenositelná. Framework poté slouží hlavně jako adapter pro web, data a integrace.

Mezivýsledky a PoC: jak efektivně začít

• Pro nejasnou doménu začněte ve Flasku jako PoC s minimem závislostí.
• Pro produkt s jasnou doménou a backoffice potřebami startujte v Djangu s DRF a adminem.
• V obou případech definujte OpenAPI kontrakty a datové modely dříve, než porostou závislosti.

Časté chyby a jak se jim vyhnout

• „Leaky“ doména vázaná na ORM – oddělte službovou vrstvu a validaci.
• Nedostatečná observabilita – bez metrik a traců neodhalíte regresi výkonu.
• Neřešené migrace a datová kvalita – CI pipeline by měla zahrnovat migrační testy.
• Přehnaná asynchronnost – async použijte jen tam, kde zkrátí čekání, nikoli pro CPU bound logiku.

Doporučené „baseline“ stacky

• Flask baseline: Flask + SQLAlchemy + Alembic + Marshmallow/Pydantic + Flask-Login + Celery + prometheus klient + OpenTelemetry.
• Django baseline: Django + Django ORM + Migrations + DRF + Django Auth + Channels (dle potřeby) + Celery + cache framework + OpenTelemetry.

Souhrn a doporučení

Flask nabízí lehkost, jemnou kontrolu a je ideální pro mikroslužby a vysoce specifické backendy. Django přináší rychlý start, jednotnou architekturu a bohatou výbavu pro podnikové aplikace. Pro datové a produktové týmy je pragmatické zvažovat hybridní ekosystém: monolit či modulární monolit v Djangu pro core doménu a satelitní Flask služby pro specializované úlohy. Klíčem k udržitelnému vývoji jsou jasné kontrakty (OpenAPI), kvalitní testování, observabilita a discipliny 12-factor – bez ohledu na zvolený framework.