Discover Flask • Hacker News Board

Re: Discover Flask

#41

Post by siddhant » Sun, Feb 21, 2016, 3:59 PM UTC

ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

Django is cool, and has been my choice for a fair number of projects. Although recently I had an interesting experience with it when I wanted to use websockets (yes, I know it's not written for that use case).

It was stunning that most of the solutions out there rely on some sort of a hack to get it working. I ended up porting over my project to Tornado, because I need websockets for a lot of the features I'm working on. And it worked out really well, especially after I combined it with SQLAlchemy and Alembic. 80% of the feature set right there. And SQLAlchemy is such a fantastic toolkit.

I'm hoping that django channels (http://channels.readthedocs.org/en/latest/) stabilizes soon.

Re: Discover Flask

#42

Post by devishard » Sun, Feb 21, 2016, 4:15 PM UTC

nawitus wrote: post #28

devishard wrote: post #12

Earlier quoted context omitted.

I would choose Flask over Meteor any day. JavaScript is the unholy union of various browsers introducing hacks which are then standardized by committee. Considering that's the design process, it actually is pretty well done. But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design. I haven't used meteor, but I have used a few other JS frameworks and libraries on the b…

> But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design. JavaScript has a coherent design specially if you're using ES6+ in strict mode with a linter. Modern JavaScript is a great language, and comparable to Python.

I'm using ES6 in strict mode with a linter and Babelify to transpile for browser compatibility and I stand by what I said. I've been writing JavaScript since there was JavaScript to write, and the situation has improved drastically, but JavaScript is still far from being a coherently designed language.

Re: Discover Flask

#43

Post by devishard » Sun, Feb 21, 2016, 4:24 PM UTC

nawitus wrote: post #26

ianamartin wrote: post #19

Earlier quoted context omitted.

I don't want to come across as a Python zealot here, but in my experience, Python has almost never been the problem in scaling. Certainly not to the extent where I would say that it costs a premium in hardware. Though, I suppose it depends on the application. My experience has been that Python will give you more than enough rope to hang yourself with, and lots of apps that are meant to scale have some homegrown crap…

> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance. But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Mos…

It has not been my experience that web applications are I/O bound using typical architectures in Python. I think you would have a very hard time arguing that Node.JS is more performance than nginx.

Re: Discover Flask

#44

Post by lucian1900 » Sun, Feb 21, 2016, 4:35 PM UTC

ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

If Django replaced their very limited ORM for SQLAlchemy, I'd agree.

There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.

Re: Discover Flask

#45

Post by CuriouslyC » Sun, Feb 21, 2016, 4:54 PM UTC

ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

This is mostly true if your application is mostly CRUD with HTML endpoints (the use case Django was designed for), particularly very "solved" use cases like blogs.

(As an aside, for very crud-heavy applications that are client-heavy with primarily JSON data endpoints, I suggest using PostgREST if possible. It is almost certainly going to be better than any CRUD API you produce yourself)

If your application is mostly endpoints that do "interesting" stuff, you aren't going to hit much of the Django infrastructure, and piece you are most likely to hit (the ORM) is so far behind the dominant Python ORM (SQLAlchemy) that it is just painful.

Flask is a lot better at getting "out of your way" than Django. The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base.

Re: Discover Flask

#46

Post by CuriouslyC » Sun, Feb 21, 2016, 5:06 PM UTC

lrem wrote: post #17

devishard wrote: post #10

Earlier quoted context omitted.

Python 2.7 will be around for a while due to legacy code, but it's only a matter of time before Python 3.x is more widely used. Don't invest time learning skills that will only dwindle in value. Some stuff is broken in the ecosystem. That's true of all ecosystems. If you're coming from the JS world it's far, far better. But if you are importing every 0.x versioned library that vaguely solves a problem close to your p…

> Python is a solid choice of language for the back ends of web applications. With caution advised when it comes to scaling. You might, or might not, pay a pretty hefty premium in the amount of hardware needed.

In addition to the things other people have mentioned, you also have the ability to easily call C code from python (compared to the unpleasantness that is JNI, for instance), and there are tools like Cython, Numba, Blaze, etc that let you rewrite your hot code into a more performant variant.

Of course, at megascale these optimizations might still not be sufficient, but there is no reason you can't deliver hundreds of thousands of requests per second very affordably with a python stack.

Re: Discover Flask

#47

Post by wcarss » Sun, Feb 21, 2016, 5:12 PM UTC

CuriouslyC wrote: post #45

ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

This is mostly true if your application is mostly CRUD with HTML endpoints (the use case Django was designed for), particularly very "solved" use cases like blogs. (As an aside, for very crud-heavy applications that are client-heavy with primarily JSON data endpoints, I suggest using PostgREST if possible. It is almost certainly going to be better than any CRUD API you produce yourself) If your application is mostly…

> The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base.

I wholeheartedly agree! Do you have any resources in mind (even perhaps not specific to flask) that you think would be useful to people hitting that wall?

Re: Discover Flask

#48

Post by nawitus » Sun, Feb 21, 2016, 5:18 PM UTC

dorfsmay wrote: post #36

nawitus wrote: post #26

Earlier quoted context omitted.

> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance. But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Mos…

Wait, in PROD, you don't use Python as the server, you stick uWSGI in front of python/flask, that will deal with the network I/O limitation.

How does uWSGI help here? The OP recommended running 4 instances of Flask/Python, and with uWSGI you still have 4 instances. It doesn't help with I/O.

Re: Discover Flask

#49

Post by nawitus » Sun, Feb 21, 2016, 5:19 PM UTC

devishard wrote: post #43

nawitus wrote: post #26

Earlier quoted context omitted.

> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance. But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Mos…

It has not been my experience that web applications are I/O bound using typical architectures in Python. I think you would have a very hard time arguing that Node.JS is more performance than nginx.

"It has not been my experience that web applications are I/O bound using typical architectures in Python."

Okay, my experience differs. Most modern web applications are relatively lightweight, and are mostly "proxies" or thin wrappers between the load balancer and the database.

Re: Discover Flask

#50

Post by nawitus » Sun, Feb 21, 2016, 5:20 PM UTC

ianamartin wrote: post #30

nawitus wrote: post #26

Earlier quoted context omitted.

> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance. But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Mos…

That hasn't been my experience. If your ACLs are set up properly, you won't encounter a full table lock, and therefore won't have problems like you described. I agree that this could be a problem in theory. In practice, it has not been. Again, it boils down to how you architect your code. EDIT: you need to stick your sessions to a specific instance. Otherwise, you are correct that there's a problem. But as long as yo…

I wasn't talking about database locks. My point was that making a database request takes a really long time relative to processing a request in the web application. Therefore the web application spends most of the time doing nothing and waiting for the database request to complete.