2)
U (skoro) každého frameworku (já dělám se Djangem) máš vývojový server. Ten není vůbec vhodný pro finální nasazení (produkci), ale je fajn pro vývoj tedy na URL localhost (např. v Djangu se Ti automaticky refreshuje s každou změnou zdrojáku).
Proč ne pro produkci? Není vůbec myšleno na věci jako je bezpečnost a práce pod zátěží. Django jako takové dokáže vzít jeden požadavek, zpracovat, vrátit, a pak další.
Na produkci před Djangem potřebuješ něco, co bude požadavky rozhazovat do vláken, která poběží paralelně. To je gunicorn nebo uwsgi (asi skoro rovnocenné, možná jednodušší a dnes běžnější je gunicorn). Ale ani gunicorn není specializován na zátěž a další starosti webového serveru. Kvůli tomu se předřadí ještě nginx. Až budeš mít aplikaci trochu hotovou a půjdeš s ní na produkci, najdeš si návod nginx+gunicorn+django a podle toho to zprovozníš. Jedna služba pod systemd je nginx, druhá služba je gunicorn. Ještě se používal hlídač-restartér supervisor, ale to ti dnes bude dělat sám systemd.
Nginx přebírá část toho URL dispatche. Má nějaké sites-available (a -enabled), které to roztřídí podle domén (když jich obsluhuješ víc). Uvnitř každé sites-available můžeš dál třídit na to, co pustíš Djangu a na to, co vrátí hned Nginx (třeba statické soubory). Nebo když potřebuješ třeba streamovat, může to Nginx pouštět jinam (třeba k Falconu).
U těch statických souborů (obrázky, javascript) je otázka cachování: Je fajn je cachovat na klientu, aby je prohlížeč netahal stále znova (to mu dovolí hlavička HTTP). Ale je potřeba mít možnost na klientu vynutit změnu, když vývojář soubor změní. U nginxu to cca můžeš zajistit tím, že nedovolíš cache moc dlouho.
Nebo máš druhou možnost, přepouštět i požadavky na statické soubory Djangu. Přidáš tam knihovnu Whitenoise a ta to řeší přejmenováním těch statických souborů na unikátní jména po každé jejich změně (na disku i v HTML). Trochu pomalejší, ale získáš výhodu, že s tím můžeš jít i do cloudu, kde nemáš kontrolu nad tím, jestli je tam nějaký nginx.
K volbě frameworku: Jestli to myslíš vážně, vol fullstack framework (v Pythonu: Django). S mikroframeworky (Flask) se nezdržuj. Django není velká výhra, je přesložitělé, některá vývojářská rozhodnutí jsou dost rigidní. Ale 70% těch složitostí si webová aplikace opravdu vyžaduje, 30% bude overhead na tu rigiditu. Naivně jsem si myslel, že Django řeší skoro všechno, ve skutečnosti počítej, že i tak budeš ke každé aplikaci muset přidat 5-30 thirdparty knihoven. Výhoda je, že knihovny jsou, musí se samozřejmě pozorně vybírat, aby to byl mainstream s pár vývojáři, co jsou za danou knihovnou, delší historií a častými aktualizacemi. Když půjdeš do mikroframeworku, budeš tam k těm 5-30 mít ještě X dalších, aby ses dotáhl na level Djanga. Navíc si tenhle stack vybereš sám a musel bys být ultra profík, abys vybral lépe, než za Tebe vybírá tým Djanga. V reálu spíš vytvoříš bezpečnostní díry atp.
Např. s Djangem nebudeš psát SQL (použiješ jeho (slušné) ORM). Nebudeš řešit migrace mezi verzemi databáze apod, máš vestavěnou autentifikaci/autorizaci, máš admin pro údržbu číselníkových dat apod.