Support for trio via anyio

[graingert]

Starlette has recently added support for trio via anyio

And I'm interested in using falcon on trio too, and would be happy to help with a port to anyio

[vytas7]

Hi @graingert !
That definitely sounds intriguing, as Trio offers a more structured way to control async tasks.

However, there are some concerns we'd probably need to address before moving forward.

• @kgriffs may provide additional insights here, but I think it's fair to state that overall Falcon's ASGI port was more complex than we had anticipated, so the question here is how anyio is going to further affect that maintenance burden, even if you lend a hand with the initial implementation.
• How is generalization of the async bits via anyio going to affect performance, if at all? We'd like to avoid any performance hit for uvloop, [arguably] the most common way to deploy an ASGI app.
• We'll need to discuss this with other maintainers, but personally I would be reluctant to (re-)introduce any hard dependencies. It feels nice to have exactly zero (since Falcon 2.0) 😈 Is it feasible to make anyio support optional?
• How does support across ASGI servers look like? Although the majority of our tests are unit tests, but we also have a rather extensive test suite exercising Falcon with all popular WSGI and ASGI servers, including Uvicorn, Daphne and Hypercorn on the ASGI side (incl Websocket).

Generally speaking, we're more flexible when it comes to the test suite, so most of the above concerns do not apply there.

Looking at https://github.com/encode/starlette/pull/1157/files, it doesn't look too heavy, particularly given that Falcon doesn't do certain types of wrapping automagic, adapters and built-in servers found in Starlette, however, it would still be good to get a feeling how big the required changes are.

Maybe you could start from a limited MVP prototype, or even just a quick review what needs to be done in the codebase, just to prove feasibility; and we could take it from there?

[kgriffs]

I like the idea of doing some initial prototyping. Providing 100% test coverage for the ASGI paths can actually be more challenging vs. writing the implementation, so I would be interested in seeing how many additional paths anyio support would require (in addition to running our existing test suite against a trio-enabled Falcon app). I would also be interested in seeing if there are any strange edge cases that trio's behavior brings up that we would have to handle and test.

If the changes are minimal, the edge cases few, and the dependencies are unlikely to see a lot of churn (i.e., the anyio/trio interfaces are stable) we can probably absorb the maintenance burden, esp. if we get some help. 😉

Also, echoing @vytas7, we would need to avoid introducing any significant performance degradations. And we would also need to avoid introducing a required dependency to Falcon, since having zero dependencies is indeed important to a segment of our community. In other words, we would need to make it possible to swap anyio/trio for asyncio without requiring any dependencies for a default Falcon installation. And again, doing so without introducing a performance regression.

[graingert]

In other words, we would need to make it possible to swap anyio/trio for asyncio without requiring any dependencies for a default Falcon installation.

Think of anyio as a library like six. It automatically picks whether you use asyncio or trio depending on the currently running event loop. You could of course vendor it

[kgriffs]

Ah, I see. Installing anyio doesn't actually pull in trio, but it does require idna and sniffio. Falcon does vendor mimeparse, but we originally allowed that only because it was essentially a single, easy-to-audit ~190 lines that rarely changed. anyio is relatively much more complex, and pulls in two additional deps that we would also have to vendor. Granted, we could perhaps put a process in place to generate PRs when updates are detected, but at the end of the day the attack surface and risk of subtle breaking changes induced by these dependencies is something that vendoring would not necessarily alleviate. TBH, I am playing devil's advocate here and it may not be a big deal, but it's something we'll need to noodle on and socialize with the community.

I think the first step would still be to prototype this proposal and benchmark the overhead induced by anyio's extra layer of abstraction. If overhead is negligible we can then decide what to do about the extra dependencies. Otherwise, we'll need to explore other strategies.

[kgriffs]

P.S. I sat in njs' introductory talk on Trio a few PyCon's ago and was impressed; it would be great if people could opt into it with their Falcon apps. I'm optimistic that we can find a way to make it happen.

[vytas7]

Re dependencies, another point to consider is that the majority of Falcon users are likely still on WSGI, at least when it comes to existing code bases. For them, anyio, sniffio & friends are in most cases just redundant.

On the positive side, our direct usage of asyncio primitives is really scarce for the main functionality, I could only find one instance of asyncio.wait(...) for WS, a couple of references to asyncio.CancelledError etc. The testing client and Falcon's own tests are a different story, as @kgriffs pointed out, porting all the tests might prove challenging.

[vytas7]

I hope I'm not already sounding as a big naysayer, as I also love the ideas behind Trio!
But since Falcon does not run in isolation, yet another thing that we might be inclined to wait for (or simply await 😈) is getting any high performance, production ready ASGI app server to support anyio (or Trio directly). Which in turn relates to encode/uvicorn#169 (comment), unless of course any other performant ASGI server appears.

[vytas7]

Unfortunately this might get delayed even more on our side, as it seems Uvicorn has closed the respective issues both for HTTP/2 and Trio without fixing them. So unless there exists a performant, production ready ASGI server with Trio support, it will be hard for us to find motivation and time to invest into this. A community PR might still be considered though.

[vytas7]

Hi again @graingert!
It was nice to meet you in person in Prague last summer (I'm unfortunately not participating this time) 👋

I was trying to estimate the amount of work needed to make this happen, and it doesn't seem too complicated as Falcon doesn't make too heavy use of asyncio.create_task() & friends.

However, there are some complications where I'm not sure what the best design is, for instance, one can schedule tasks via resp.schedule() after sending a response to the client.

Should I construct an AsyncExitStack, and then schedule tasks using the task group within:

async def fancy_task(task_status=anyio.TASK_STATUS_IGNORED):
    task_status.started()
    await anyio.sleep(1.0)
    logging.info('Exiting fancy_task...')


async def scheduled_task(message):
    await anyio.sleep(3.0)
    logging.info(f'Scheduled task: {message=}')


async def main():
    # Earlier in the application, e.g., in ASGI lifespan handler
    stack = contextlib.AsyncExitStack()
    bg_tg = await stack.enter_async_context(anyio.create_task_group())

    async with anyio.create_task_group() as tg:
        logging.info('Pretending to handle request...')
        await tg.start(fancy_task)

        logging.info('Scheduling task...')
        bg_tg.start_soon(scheduled_task, 'Hello, World! #1')
        bg_tg.start_soon(scheduled_task, 'Hello, World! #2')

    async with anyio.create_task_group() as tg:
        logging.info('Pretending to handle another request...')
        await tg.start(fancy_task)
        await tg.start(fancy_task)

        logging.info('Scheduling other tasks...')
        bg_tg.start_soon(scheduled_task, 'Task #2')

    # ASGI Lifespan shutdown event could attempt this
    await stack.aclose()

(Seems to work? 🤔)