This was my go to for learning Flask, I wish I never found it. Flask has a very niche use case in my opinion and if you need something to scale (in terms of code complexity) Flask is the absolute worst decision you can make.
Try Django instead. If you read my comment history you'll see that I learnt this the hard way.
In my experience it's quite the opposite. We use Flask for a large-scale webapp in production quite successfully and it's enabled us to reduce application complexity significantly.
While you get up and running faster with Django, in the long run you spend more time fighting it, whereas with Flask you only spend time on stuff that you actually need.
Yep. This is exactly how I feel. Django is great to get projects going, but eventually you just end up fighting it a lot.
I even recommend people not to install too many flask extensions, just use Django if that is how you like your development. Flask is much better when you just build for it - It takes longer to deliver, but you'll be enjoying that project for years.
This is inspired by Elixir's compile-time config per environment/release/etc...
Instead of a huge settings.py, I have:
settings/__init__.py : Import the correct settings
settings/core.py : The stuff that Django generates and that you touch almost never
settings/base.py : The basic settings of your project (your apps, middlewares, ...)
settings/envs/dev.py : Development settings
settings/envs/prod.py : Production settings (read from env vars, the 12 factors app way)
settings/envs/test.py : Test suite settings
2. Separate your business code from your Django apps
In most project, I have the package `myproject.lib` which contains all the business code, easily testable and mockable. Then I have the Django apps in `myproject.apps.<appname>` which imports from `myproject.lib`.
This allows you to make your views quite small because all the logic is not there.
3. Most of the time, you don't need class-based views.
A small function which call your business code and render a JSON document, or an HTML document is more than enough. Django provides many function decorators that are easier to reason about (login_required, permission_required, require_http_methods, ...).
4. You might not need an API
Server Side Rendering is coming back into trends, huge SPA that are heavy on the client's resource are becoming less frequent. Then, why would you need a REST/GraphQL API?
You can work with HTMX, Django Forms, small views that call your business code and return some small rendered template, then sprinkle some Alpine.JS (or jQuery) on top of it, and you get your SSR SPA that scales well enough.
5. Deploy with gunicorn and whitenoise
By default, Django won't serve staticfiles in production, you need to distribute them via a CDN. Which is a bit more complicated to deploy. Instead, use Whitenoise to force Django to serve staticfiles but with the correct HTTP cache headers so services like Cloudflare can take over after the first request (usually done by your E2E test suite by the way).
Then you only need one Docker image, one gunicorn, and if you deploy in Kubernetes, one Ingress resource.
6. Use django-anymail
This is, by far, the best library out there. I usually make a mailjet account, add my API key to my settings, and use the mailjet backend of django-anymail. No SMTP setup required.
All of those tips might seem obvious, but they get you far, very far. Also, IMHO the urls.py from Django is vastly superior to the route decorator from Flask.
strongly disagree with this. flask is what you make of it. you create your design patterns. for example, here's an MVC boilerplate i use for all my flask apps: https://github.com/esteininger/flask-mvc-boilerplate
After reading your comment history and searching it, it seems to me that you never learned to use Flask. Jumping into new project and learning a framework at the same time means that you may have to restructure everything after you have learned it.
I learnt it quite well actually. Used it in a few projects one quite large.
It worked ok for internal apis not open to customers, but even then Django was much better as just setting up the admin side provided a lot of value to the business (for free).
All forgotten now but wasted a huge amount of time glueing things together that came for free with Django.
Zr40|3 years ago
nicbou|3 years ago
JodieBenitez|3 years ago
alexcnwy|3 years ago
Flask is scaling really well for us and it’s flexibility is far better than Django’s opinionated approach.
ibz|3 years ago
While you get up and running faster with Django, in the long run you spend more time fighting it, whereas with Flask you only spend time on stuff that you actually need.
joaodlf|3 years ago
I even recommend people not to install too many flask extensions, just use Django if that is how you like your development. Flask is much better when you just build for it - It takes longer to deliver, but you'll be enjoying that project for years.
Flask is for longevity.
parham|3 years ago
linkdd|3 years ago
I have some tips I use in all my Django projects:
1. Split your settings.py in multiple files
This is inspired by Elixir's compile-time config per environment/release/etc...
Instead of a huge settings.py, I have:
See my gist as an example for the `settings/__init__.py`: https://gist.github.com/linkdd/4aac2c2efc4a51af6ca4b05f395de...2. Separate your business code from your Django apps
In most project, I have the package `myproject.lib` which contains all the business code, easily testable and mockable. Then I have the Django apps in `myproject.apps.<appname>` which imports from `myproject.lib`.
This allows you to make your views quite small because all the logic is not there.
3. Most of the time, you don't need class-based views.
A small function which call your business code and render a JSON document, or an HTML document is more than enough. Django provides many function decorators that are easier to reason about (login_required, permission_required, require_http_methods, ...).
4. You might not need an API
Server Side Rendering is coming back into trends, huge SPA that are heavy on the client's resource are becoming less frequent. Then, why would you need a REST/GraphQL API?
You can work with HTMX, Django Forms, small views that call your business code and return some small rendered template, then sprinkle some Alpine.JS (or jQuery) on top of it, and you get your SSR SPA that scales well enough.
5. Deploy with gunicorn and whitenoise
By default, Django won't serve staticfiles in production, you need to distribute them via a CDN. Which is a bit more complicated to deploy. Instead, use Whitenoise to force Django to serve staticfiles but with the correct HTTP cache headers so services like Cloudflare can take over after the first request (usually done by your E2E test suite by the way).
Then you only need one Docker image, one gunicorn, and if you deploy in Kubernetes, one Ingress resource.
6. Use django-anymail
This is, by far, the best library out there. I usually make a mailjet account, add my API key to my settings, and use the mailjet backend of django-anymail. No SMTP setup required.
All of those tips might seem obvious, but they get you far, very far. Also, IMHO the urls.py from Django is vastly superior to the route decorator from Flask.
TL;DR: Don't fight Django, embrace it.
Beefin|3 years ago
whateveracct|3 years ago
nabla9|3 years ago
That's my impression at least.
parham|3 years ago
It worked ok for internal apis not open to customers, but even then Django was much better as just setting up the admin side provided a lot of value to the business (for free).
All forgotten now but wasted a huge amount of time glueing things together that came for free with Django.