Live data from Hacker News

Flask 1.0 Released

palletsprojects.com

121–130 of 184 posts

Re: Flask 1.0 Released

#121

Earlier quoted context omitted.

I've been developing with Django since the 0.90 days and, to be honest, I've seen a lot of scalability issues with Django itself once you get big enough. Those issues all relate to how Django is an all-in-one solution with a lot of modules, which you start dropping one by one as you use different solutions. For example, Django's cache layer is great, but as you scale you'll want to use Redis clients directly rather t…

> ORM is fantastic (and much more intuitive than SQLAlchemy) Any articles or blog posts you can recommend to give some examples or comparison? > entire Django ecosystem of apps that make heavy use of the model layer. Exactly why I don't want to use the django system. I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist. Its not that django is a bad web framewo…

> Any articles or blog posts you can recommend to give some examples or comparison?

Not really sorry, it's all personal experience.

> I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist.

What about all the cases where you need support from database schemas? For example let's say you want to have access to Stripe subscriptions from Python and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM.

Re: Flask 1.0 Released

#122
post #28

Flask has a stigma for not being that good when building larger apps, but honestly Flask scales really well for that type of use case (coming from a development / maintenance point of view). I have some pretty large Flask apps with dozens of top level dependencies and models spanning across many thousands of lines of code. Even if I don't touch the code base for a few months, it's easy to jump back into it. I'm also…

My employer made me switch from Flask to Django providing non-scalability reason. I asked around on a few online forums and they told me that flask has no such issues. There was an article where somebody from DISQUS explained how they were able to use flask in production without much hassel and there's no reason to switch to django. My employer told me to not use flask as it is not production grade. The problem was t…

This is sad. Flask is a very nice microframework that does not have any of these scalability limitations for which your employer asked you to switch to Django.

I have used both Flask and Django for a long time, so I think I could contribute a couple of points in this regard.

- Django with a very good documentation and batteries included helps to build a lot of functionality in less time without having to look anywhere else. In the same time, flask being a microframework, you need to look for the batteries yourself and it takes experience and knowledge to know which components to use and which to avoid.

- None of these two frameworks will magically fix the scaling issues or are free to scaling issues.When you hit issues with scaling, you need to find the bottleneck and fix it. There is no other magic bullet here. I would suggest do not be religious about things and try both of them without any bias in your personal projects and then evaluate. Do not form an opinion without knowing something yourself.

Re: Flask 1.0 Released

#123
post #22

Earlier quoted context omitted.

I think a lot of criticism is valid. Flask has a lot of bizarre conventions which don't scale well, like stuffing all shared resources into the global context or app-level dicts and using `@route()` decorators all over, for example. And I'm not sure what the benefit is, except that clever feeling one gets when they use decorators or other seemingly magical features unnecessarily and later need to workaround the tight…

Decorators improve dev speed. No need to be constantly switching back and forth between views and urls.py. Still, sometimes nice to see all in one place.

They only improve speed from an initial "get it working" point of view. That's part of the reason flask is rarely taken seriously as a production solution. Not having natural separation between views and urls is a real PITA for anyone trying to create a long term solution or larger project. For what it's worth, I also hate the argument that bad design increases Dev speed. That's only true until you need find something later, then you have to hunt around instead of having one place to look, wiping out any initial gains. It's false economy.

Re: Flask 1.0 Released

#124
post #88

Earlier quoted context omitted.

I think its explicitness is hugely wonderful for maintenance I find all the magic really off-putting in Flask…

I thought what the parent comment meant was that there's little to no magic in Flask compared to some macro-framework like Django/Spring. Can you get any more explicit than Flask and still be called a framework, without hitting the socket levels?

Well flask did evolve of Werkzeug a utility wrapper around wsgi, in response to bottlepy.

I also find a lot of the "magic" is found in flask extensions.

Re: Flask 1.0 Released

#125
post #48
post #31

Earlier quoted context omitted.

> Flask has a stigma for not being that good when building larger apps Not sure how to quantify that "large" but I've worked on some api backend services written in Flask with a quarter million lines of python code and not feeling "outgrowing" Flask. Granted, it took some good design and effort to make all piece s work together. These days, horizontally scale apps is the way to go.

In my experience, Django is less suitable for large projects than Flask. The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer. This is manageable in the small, but when you hit scale, this tight coupling adds a whole bunch of unnecessary complexity to…

>template can trigger hundreds of db calls

I'll take what is caching for 500, Alex

Re: Flask 1.0 Released

#126
post #55

Earlier quoted context omitted.

This was my experience. Just exited a startup that relied on Python heavily. Built a flask-restful based back end with SQL Alchemy.. Never had any issues with flask per say, but it made me happy I know languages with far better tooling and concurrency experience/performance :)

Did you ever attempt to use PyPy? Flask works with it, and in my experience the handful of times I've needed Python to be more performant, PyPy got me there easily. My use-case was I was doing a heavy part of an ETL pipeline out of MySQL and it was taking an unreasonable amount of time. PyPy was a roughly ~8x speedup, which ended up being faster than doing direct manipulation with MySQL via the cli (!!!).

For interest sake, can SQLAlchemy run on PyPy; pgsql driver support? thanks,

Re: Flask 1.0 Released

#127
post #10

I don't understand why use Flask instead of Django, I usually work with a lot of crud systems, I think that Django is the best option to do it. I think that Django is better because it has an autogenerated admin site and this is really helpful when you work with the customers, they can easily populate the database while you work in the logic

Django was the main reason I started with Python. Really loved it more than Wordpress or Rails. However, Flask is just much simpler to get started. So nowadays, where I mostly have to achieve the most bang for a given set of bucks I usually choose Flask.

Re: Flask 1.0 Released

#128

Earlier quoted context omitted.

> ORM is fantastic (and much more intuitive than SQLAlchemy) Any articles or blog posts you can recommend to give some examples or comparison? > entire Django ecosystem of apps that make heavy use of the model layer. Exactly why I don't want to use the django system. I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist. Its not that django is a bad web framewo…

> Any articles or blog posts you can recommend to give some examples or comparison? Not really sorry, it's all personal experience. > I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist. What about all the cases where you need support from database schemas? For example let's say you want to have access to Stripe subscriptions from Python and cache them to you…

> For example let's say you want to have access to Stripe subscriptions from Python

I will use the official stripe flask checkout example[0].

> and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM.

With their OpenAPI definitions[1] to create the needed sqla model boilerplate, which creates the needed pgsql tables. For change log of my models it is kept in my py model files and xml with sql diff using a cheat where I implemented a Liquibase python wrapper[3].

I'm lucky where I work in a not to enterprise env so self-rolled solutions is sometimes acceptable and we try to keep it sane.

[0]: https://stripe.com/docs/checkout/flask

[1]: https://github.com/stripe/openapi

[3]: https://github.com/Morabaraba/python-liquibase

Re: Flask 1.0 Released

#129
post #10

I don't understand why use Flask instead of Django, I usually work with a lot of crud systems, I think that Django is the best option to do it. I think that Django is better because it has an autogenerated admin site and this is really helpful when you work with the customers, they can easily populate the database while you work in the logic

I have worked with the Django some, but not a lot, but I always find the admin site a bit frustrating and hard to configure and style. Maybe it's just my lack of knowledge and experience about Django, but it often times seems faster to generate a crud admin interface in many other frameworks like asp.net.

Otherwise I am a big fan of Django, I think it is possibly the best web dev framework out there even if I work in asp.net for most of the time.

Re: Flask 1.0 Released

#130
post #33

Earlier quoted context omitted.

That sounds like a helleva large codebase, especially for Python. What did the application do? How large was the dev team?

I have worked on several Python code bases exceeding 500k lines. Not sure why you think that's uncommon.

I've worked on a couple codebases approaching that a few hundred k. But at that point we've usually done major refactor, usually resulting in a codebase with a level of magnitude less lines.

I'm not saying exceeding 500k lines is impossible, but it seems like a very large system for a well written codebase with low duplicity. I would love to see what the codebase looks like for such a system written with Flask.

Post reply on HN