Varför du inte ska använda den inbyggda utvecklingsservern

När ni körde flask run startade Flask en liten inbyggd server. Den var perfekt för inlärning, men var aldrig avsedd att möta riktiga användare. 🚦

Observera varningen som Flask skriver ut vid uppstart. Den säger bokstavligen att detta är en utvecklingsserver och inte avsedd för produktionstrafik.

Som standard är utvecklingsservern till stor del entrådad. Ett långsamt anrop kan få alla andra besökare att sitta och vänta på sin tur.

Riktiga webbplatser hanterar många användare samtidigt. Utvecklingsservern har ingen ordentlig modell med workers för att fördela belastningen över processorkärnorna.

Utvecklingsservern är inte härdad för det öppna internet. Dess svaga säkerhet gör den till ett enkelt mål för felaktiga eller skadliga anrop.

I felsökningsläge kan ett fel skriva ut ett fullständigt stackspår direkt i webbläsaren. Praktiskt för er, men en gåva till angripare i produktion.

Python-webbappar kommunicerar med servrar genom ett kontrakt som kallas WSGI. Flask stöder det, så alla kompatibla servrar kan köra er app.

En produktions-WSGI-server har flera workers, startar om efter krascher och använder anpassade tidsgränser. Den är byggd för att vara tillgänglig under hög belastning.

Den goda nyheten är att era vyer förblir likadana. Ni pekar bara en produktionsserver på ert app object i stället för att anropa flask run.

Under resten av kursen kommer Ni att köra Flask med Gunicorn, en välbeprövad WSGI-server, och sedan kapsla in den i Docker.

Detta innebär inte att Ni ska ta bort flask run. Fortsätt använda utvecklingsservern lokalt för dess omedelbara omladdning och lättförståeliga felmeddelanden.

Utvecklingsservern är till för att lära sig, inte för att lansera. I produktion lämnar Ni över er WSGI-app till en riktig server som Gunicorn. Härnäst gör Ni precis det. 🚀