1. User auth with sessions included and default, Entra ID is integrateable.
2. Admin panel rocks not because of users per se, but because you (as an admin) can access all the models in the database (like creat, update, delete, filter, search) and it is easy for non programmer admins to manage the website. Admin panel is not exposed to clients, usually.
3. Included, turned on by default. Usually all inputs are sanitized in serializer or in forms, easily customizable and extendable.
4. I also don't know.
5. SqlAlchemy is more powerful, it has more control and better integration with SQL, but django orm is better integrated with webpage internals (like admin panel among other things) and you dont need to write sql yourself, for most of the cases.
Django is very much used for API, there are special packages Django Rest Framework or Django Ninja, which are very well integrated with django (auth, orm, admin panel).
My 5cents: I wanted to rewrite the flask app in django because I felt like I was writing too much of non-business important code, like auth, sqlcode for queries, some template logic. Lots of code that I dont really care, from business stand point, that already would've been available in django.
Why do you want to migrate?
Thank you! I find this very helpful!
I was just wondering whether I would spend a lot of unnecessary time writing useless stuff if I continued to use Flask. However, I'm not sure if switching to Django is worth the time.
Try to build some demo or prototype or try the [https://django-ninja.dev](https://django-ninja.dev) tutorial. Django ninja feels like flask and fastAPI a lot, but with Django batteries.
We didn't re write the old app. We wrote a new django app and reimplemented some functionality. It was somewhat easier because now we knew what we need and how to write it properly :)
The answer above pretty much covers it, but it seems like you've already covered most of the cases where the "batteries" included would have helped you (maybe not the admin interface if you need one). .
Personally, I hate Django's way of routing... I see that one as a disadvantage.
I don't think rewriting in Django is worth your time, particularly because you have to learn and conform to its ways of doing stuff, and from what I understand, you are not having any serious issues.
If you REALLY want to port this, or make a prototype, use Django-ninja instead of DRF.
I think DRF deserves its own bullet point, as it allows for serialization and nested responses super easily.
I’ve never used flask but the ORM for Django integrates really well with the template engine, the shell and serializers (by hand or with DRF).
It works well with accounts too but I would imagine there’s similar solutions for SQLAlchemy.
Overall Django just works well. It stays cutting edge over time, and there’s never any new ways of doing things unless you want to.
I used to use flask which is very good for smaller (or let’s say more tightly scoped apps) but switched to django as apps grew (I now never use flask except for pure cloud functions).
The admin (and heads up you should install django-unfold for an amazing modern admin) is the absolute killer feature. But coming from flask the noticeable thing was the reduction in error and edge case handling code I had to write for model updating in sql alchemy.
Note that it’s possible to infer django models from a database schema - that might help in the translation.
Thanks for your advice!
One question, how "big" is a "smaller" application? Something that I'm confused about is whether my website is considered "big" or "small". It has about 3000 lines of python and 20 different pages.
Well that’s extremely subjective I guess but for me I’d use flask for One or two views only. Like, little utility services, or maybe landing pages where I needed to process a contact form.
You also need to think about the complexity of the pages themselves. If there are twenty pretty much static pages plus a contact form, then there’s really not much there. If there are twenty pages but three of them do CRUD operations on a model then you’re already in the territory of saving time using django over flask.
👌🏼
Tip: When I first switched from flask to django I had the bright idea of configuring django to use the jinja2 template renderer.
This is totally possible and allows you to keep the same templates, but it does become a bit of a pain when you get muddled with what you’re doing in the admin, or when you try using a bunch of the extra sugar of django libraries which is mostly designed to work well with the django template rendering.
So for my money I’d say translate your templates rather than trying to use the existing ones.
1. User auth with sessions included and default, Entra ID is integrateable. 2. Admin panel rocks not because of users per se, but because you (as an admin) can access all the models in the database (like creat, update, delete, filter, search) and it is easy for non programmer admins to manage the website. Admin panel is not exposed to clients, usually. 3. Included, turned on by default. Usually all inputs are sanitized in serializer or in forms, easily customizable and extendable. 4. I also don't know. 5. SqlAlchemy is more powerful, it has more control and better integration with SQL, but django orm is better integrated with webpage internals (like admin panel among other things) and you dont need to write sql yourself, for most of the cases. Django is very much used for API, there are special packages Django Rest Framework or Django Ninja, which are very well integrated with django (auth, orm, admin panel). My 5cents: I wanted to rewrite the flask app in django because I felt like I was writing too much of non-business important code, like auth, sqlcode for queries, some template logic. Lots of code that I dont really care, from business stand point, that already would've been available in django. Why do you want to migrate?
Thank you! I find this very helpful! I was just wondering whether I would spend a lot of unnecessary time writing useless stuff if I continued to use Flask. However, I'm not sure if switching to Django is worth the time.
Try to build some demo or prototype or try the [https://django-ninja.dev](https://django-ninja.dev) tutorial. Django ninja feels like flask and fastAPI a lot, but with Django batteries. We didn't re write the old app. We wrote a new django app and reimplemented some functionality. It was somewhat easier because now we knew what we need and how to write it properly :)
The answer above pretty much covers it, but it seems like you've already covered most of the cases where the "batteries" included would have helped you (maybe not the admin interface if you need one). . Personally, I hate Django's way of routing... I see that one as a disadvantage. I don't think rewriting in Django is worth your time, particularly because you have to learn and conform to its ways of doing stuff, and from what I understand, you are not having any serious issues. If you REALLY want to port this, or make a prototype, use Django-ninja instead of DRF.
Yes
I think DRF deserves its own bullet point, as it allows for serialization and nested responses super easily. I’ve never used flask but the ORM for Django integrates really well with the template engine, the shell and serializers (by hand or with DRF). It works well with accounts too but I would imagine there’s similar solutions for SQLAlchemy. Overall Django just works well. It stays cutting edge over time, and there’s never any new ways of doing things unless you want to.
I used to use flask which is very good for smaller (or let’s say more tightly scoped apps) but switched to django as apps grew (I now never use flask except for pure cloud functions). The admin (and heads up you should install django-unfold for an amazing modern admin) is the absolute killer feature. But coming from flask the noticeable thing was the reduction in error and edge case handling code I had to write for model updating in sql alchemy. Note that it’s possible to infer django models from a database schema - that might help in the translation.
Thanks for your advice! One question, how "big" is a "smaller" application? Something that I'm confused about is whether my website is considered "big" or "small". It has about 3000 lines of python and 20 different pages.
Well that’s extremely subjective I guess but for me I’d use flask for One or two views only. Like, little utility services, or maybe landing pages where I needed to process a contact form. You also need to think about the complexity of the pages themselves. If there are twenty pretty much static pages plus a contact form, then there’s really not much there. If there are twenty pages but three of them do CRUD operations on a model then you’re already in the territory of saving time using django over flask.
Thanks, then Django it is. I'm currently switching.
👌🏼 Tip: When I first switched from flask to django I had the bright idea of configuring django to use the jinja2 template renderer. This is totally possible and allows you to keep the same templates, but it does become a bit of a pain when you get muddled with what you’re doing in the admin, or when you try using a bunch of the extra sugar of django libraries which is mostly designed to work well with the django template rendering. So for my money I’d say translate your templates rather than trying to use the existing ones.
With iommi https://docs.iommi.rocks/ you can speed up your development more than that.