Hacker News new | ask | show | jobs
by dheera 1869 days ago
I've moved most of my Flask projects to Express and NodeJS.

Flask was just a PITA to deploy properly in a way that it could handle lots of concurrent connections without a massive memory footprint, and async in Python is a mess.

The JS ecosystem has on the other hand moved to async and Promises as the standand/default way to implement things, which makes things much easier.

Express middleware is also just easier to write than Flask middleware.

6 comments

> and async in Python is a mess

I’ve heard this a lot of late, but it’s not clear to me why. Would you be willing to expand on your assertion?

Personally, I’ve written a fair chunk of typescript and asyncio based Python over the year for a project and in general I think Python has done an excellent job of their implementation.

Some things are annoying; for example I’ve a consistent case, which I haven’t pared down to better understand, where by exceptions in a coro are never visible. Not to be confused with the classic case of being notified of the exception when your process shuts down.

OTOH some things are really amazing, for example PYTHONASYNCIODEBUG=1. More so the ability to wrap non async, typically blocking, code in an Executor and it “magically” (via thread pools) work in the event loop has also been a boon for the type of work I’m engaged in.

Waaaaay back, I was really hurt by twisted and to a lesser extent tornado. But the async stuff shipped in 3.9x seems completely comparable to JavaScript imho.

The main problem is that many Python libraries come in only sync flavor and using them together with asyncio is a pain.

NodeJS libraries are almost all standardized to async now. Hell, even Tensorflow.js can give you Promises of computation results.

Seems pretty painless to me:

    $ python3 -m asyncio
    >>> from requests import get
    >>> url = 'https://example.com'
    >>> response = await asyncio.to_thread(get, url)
A lot of Python libraries now offer async APIs, have async support on their short term roadmaps, or other async projects have replaced them.
oh neat! I did not know about asyncio.to_thread; I've been using the longer form thread executor pattern.
I hadn't seen that either - looks like it's new in Python 3.9: https://docs.python.org/3/library/asyncio-task.html#asyncio....
And if you aren't using 3.9, the anyio package has a run_async() function in its to_thread module[1] that works the same way as asyncio's to_thread() coroutine function, and the anyio solution is compatible with both asyncio and trio.

[1] https://anyio.readthedocs.io/en/stable/threads.html

You looked into using gevent workers? Sometimes you need to make tweaks to C-based dependencies to make them not block the event loop, but it should work fine for doing a lot of concurrency without a bunch of rewriting. Usually your bottleneck is your database anyway.
How does gevent actually works? It takes care of scheduling and polling?
it uses non-blocking sockets and libev interface to propagate events from the kernel https://sdiehl.github.io/gevent-tutorial/#greenlets
If you like Express and writing middleware in Express, you will love Koa. Its written by the same team that wrote Express so it will be familiar. It makes more use of async/await than Express too.
If you only need 10.000 concurrent users it's pretty easy to do that with threads and gunicorn or uwsgi.

The memory footprint shouldn't be bad, just one page per user.

> The JS ecosystem has on the other hand moved to async and Promises as the standand/default way to implement things, which makes things much easier.

Weird, none of the issues in my career as a full stack dev ever have been due to a lack of async primitives.

There are much more elegant ways of doing concurrency than Promises and coloured (async vs regular) functions, if that's the issue.

> Flask was just a PITA to deploy properly in a way that it could handle lots of concurrent connections without a massive memory footprint, and async in Python is a mess.

That makes me concerned. Does anyone here know if FastAPI is better? How many concurrent connections could your Express app handle at once?

Yes. Night and day. I haven't got too deep into it, but FastApi allows writing async def right out of the box, super easy to set up. Uvicorn is stupid fast and easily configurable. There is also fledgeling asgi (async wsgi) support iirc.