There's flask-restless, which removes most of the boilerplate. There's still good reasons to choose django over flask though, but easy rest apis can be achieved with both.
To me the beauty of a restful API in flask is that you don't need to commit to anything. As far as the user is concerned, as long as /api/v1/user/15 gives back the user details for user number 15 (after checking authorization if necessary). The person who follows in my footsteps should be able to rewrite things one end-point at a time (as long as we clean things up after every transaction) in any other language (go lang or rust or swift seem like best bets). At least that is my hope, even if the person who follows in my footsteps is me!
I am learning Python right now and want to build a website using this programming language. Django and Flask seem to be the best frameworks for this purpose. I understand that Django has steeper learning curve and comes with "everything", whereas Flask is more modular and compositional.
If I were to use Flask, is there anything that I could not do but that Django could?
The advantage of Django is it comes bundled with everything you could need. Flask is simple, but then you need user authentication. Which library do you use? Is it updated and maintained? What about an ORM, forms, templating, localzation. Do they all work together?
Suddenly it's not so simple.
That being said, if your app really is simple (single file, under 100 lines) flask is excellent.
Oh, come on. There are plenty of large websites written in flask. It's not that hard to use at all, and all those things you list are definitely a part of it. Hell, I have a 20 KLOC website written in bottle, and no one ever said it was poorly done, insecure, and so on.
The problem is that a lot of people writing Python web stacks don't know how to write Python at all, and no framework will save that shortcoming.
Part of my point was that if your site is going to be 20 KLOC then why not use a framework that is aimed at building 20 KLOC large sites rather than one that is aimed at writing 200 line sites.
Flask is advertised as a micro framework. if you want to rebuild Django with it then sure you can, but I personally can't see why you'd want to.
Flask is used by Pinterest and LinkedIn, which I'm guessing are a touch more than 100 lines of code.
Flask is, of course, more powerful than bottle, and has less batteries included than Django. Saying Flask is good for 100 LOC sites is terrible advice, no matter which way you try to slice it. It isn't. It's widely-used and well-maintained.
I've used Flask for single file sites with 10-250 lines. It's great (ish). What's bad about it? Your saying it's only good for writing large applications? How so?
Your contention is that it's only good for small sites. I'm saying it's good for any sized site as long as you actually know how to RTFD and program in Python.
Django is no different. Django falls apart spectacularly in the hands of people who can't program.
Does eventually needing a truck justify driving one when for now everything fits in a van? The structure Django imposes on you may get in the way while you're still experimenting.
What I like most about Flask is, it provides the barebones for request/response handling, and gets out of your way. Add SqlAlchemy to the mix, and python handles the rest.
I'm using Flask, but building my apps with Python.
This simple/complex equation should be reversed IMHO. Want to throw together something quick? Go with Django, where everything you need is built-in. Want to build a big app? Go with Flask, and build your stack specific to your needs.
As a bonus, once you have built a complex app with your own abstractions/magic succesfully, it becomes faster for you to build new projects with your own framework than any other alternative.
I've ever understood this argument. Any library you can pick and mix into your Flask app you could just as easily pick and mix into your Django app. It's all just Python.
You most certainly can. I've built several Django apps with Elasticsearch-DSL as a backend and another app with a completely custom backend (you need a really good reason to do this).
There are tradeoffs of course: you give up the Django admin and a bunch of other things, at which point we might as well have used Flask. But our shop has a number of other "normal" pure-Django apps so it makes sense for us to use Django as a common base.
Awhile ago there was a book called "Lightweight Django" in which the authors showed how to use Django in a stripped-down Flask-like manner. Ultimately Django is just a big bag of parts that you can use or not use.
It's exactly the same situation: either you luck out, and someone already wrote all the conveniences and utilities and integrations with components for you exactly the way you want them with exactly the set of other components you wanted, or you do it yourself.
Also, you could make a similar argument about swapping major components into, say, Pyramid. Most of the alternatives people promote to Django are not really some paradise of trivially-swapped-but-tightly-integrated components. They just do exactly what Django does, with a different set of "use these or lose the integration" components chosen up-front for you.
I've used SqlAlchemy with Flask. You only need a few lines of code to integrate them.
But yes, with Flask (or similar frameworks/libraries), you need to do the integrations yourself with the components you want to use. Advantage of Flask in this regard is, you don't need to fight with Flask to make it happen. That's why I'm saying it's better suited for complex apps that you want to build with your own abstractions.
The real problem is the cargo cult thinking when it comes to frameworks, instead of doing a cost/benefit analysis and thinking about trade-offs.
Following statements like "Django for complex apps, Flask for 100 lines of apps" without researching the reasons behind probably will result in more problems in the future.
Flask is a great fit with smaller APIs but not tiny like this in my experience. Great support for SQLAlchemy and database migrations. Better than Django ORM in my opinion.
If you have little experience with backend development, Django may help you by forcing you to code into a predictable and sensible structure; Flask won't limit you in any way, which is great but It's easier to shoot yourself in the foot and its harder to keep a consistent codebase.
If you're familiar with SQL, it may take some time to adapt to the Django ORM, which is really great but favors ease of use over power.
All in all, with Django you'll fight to override defaults and with Flask to enforce them.
I loved both enemies
> If I were to use Flask, is there anything that I could not do but that Django could?
No, but it might be simpler.
When I started doing webdev in Python I used Flask (it's so slim, they said) and I still like it, but if you have some kind of DB in the back and care about user management, Flask won't help you.
Most people then use sqlalchemy and specific extensions for Flask to handle the user and security stuff. Although this works, I would advise you to start with Django.
If you are learning python, I would stick with Django. It'll get the basics up and running for you and you can focus on python specific code. If you go with flask you'll need to be piecing everything together on your own, and then you're not just learning python, you're learning web application components and flask as well.
With frameworks, the more they do for you, the more risk you will end up fighting against them if you need to do something they're not designed for.
Django isn't particular bad at this (it has some escape hatches to allow you to e.g. write custom SQL), but it is overal still quite a big framework and it's certainly harder to bend to your will than Flask.
So, you need to know the extra things it gives you and figure out if they will be helpful for your website.
Loosely, Django is: routing + HTML request parameter handling + HTML rendering + templating + user sessions + lots of database read/write help, assuming simple CRUD access patterns.
Flask is: routing + HTML request parameter handling + HTML rendering. Then, if you want any of the other things, you go and find a library for them.
I do not have much experience with flask, but I recently told a coworker: if you are fighting the Django framework to do something, atleast question why you are doing that because there is a good chance you are going down the wrong path. The caveat is, yes there are some times when that is necessary, but it is also necessary to question what you are doing, and why it isn't possible.
