3 ms·
And, of course, you need multiple separate components because Python/Flask has no central "application" concept,there are multiple, stateless processes. Had yo
by alanfranz 7y ago
And, of course, you need multiple separate components because Python/Flask has no central "application" concept,there are multiple, stateless processes.
Had you got e.g. a Java app running with a multithread application server model, you could serve and process everything within a single process. No Celery, no Redis, no MQ.
This doesn't mean that the above stack has no use. But, whenever picking a tech, you should understand the use case. The "simpler" Python/Flask solution has an increased complexity when the task at hand is not simple anymore.
- twhitmore 7y agoA rather vague and uninformative article. I liked the cartoons, but regard McDonalds as a negative corporation serving low-quality food to the lowest denominator of people.
- deleted 7y ago[deleted]
- WJW 7y agoWhen the task complexity rises further, splitting out the message queue and workers into separate processes makes sense again. That way, you can easily scale worker capacity up and down and you can restart your web server processes without having to worry about background job persistence since that is handled by the message queue.
- alanfranz 7y agoSure. You can do the same with the application server model. But you haven't to as long as you don't want to.
- polote 7y agoIt has nothing to do with Python, there a plenty of async web python framework.
- alanfranz 7y agoI wrote Python/Flask because the application server model is inherently flawed in Python, while Flask is not asynchronous AFAIK; you MUST use an async model (because Python and multithreading still don't work well together), you can't use threads for long-running tasks.
- icebraining 7y ago> Python/Flask has no central "application" concept, They do, it's a WSGI application. Flask has been multithreaded for many years. Python also has multi-process queues that don't need an extra process.
- alanfranz 7y agoWSGI is purely an interface between a webserver and python. What has WSGI to do with state? The application server model makes it so there's a running application, with a state, and which exposes an HTTP endpoint. > Flask has been multithreaded for many years So? You run a blocking thread to performing a long-running task in Flask? With Python? Try, then report what you find. Flask/Django are mostly designed to work with a stateless approach. Nothing wrong with that, but it's got drawbacks. > multi-process queues that don't need an extra process. More processes usually imply more complexity. And still, since you don't have a central application with a state, you NEED an extra piece to manage the result from the queue.
- icebraining 7y ago> So? You run a blocking thread to performing a long-running task in Flask? With Python? Try, then report what you find. I did it for years. It works just fine. The GIL is essentially like running an app on a single core, which works just fine for many use cases. CPU cores are quite powerful. > More processes usually imply more complexity. Right, but I'm only saying you can have more processes without requiring Redis. > And still, since you don't have a central application with a state, you NEED an extra piece to manage the result from the queue. A regular thread can do that.