Best practice for sharing logic between WSGI and ASGI apps

[onecrayon]

I recently found myself copy and pasting logic from an ASGI Falcon app into a different WSGI Falcon app, with the only difference between the two copies being a lack of async/await decorating view methods in the WSGI incarnation. This got me thinking that this code probably deserves to be refactored out as a shared dependency, but that raises the question: what are the best practices for sharing Falcon view classes between ASGI and WSGI? (Specifically, my shared code is performing similar to FastAPI method decorators or spectree except using msgspec to document/validate query parameters and expected JSON bodies; as a result, it needs to provide a view class in order to generate OpenAPI JSON.)

Currently, middleware allows you to share the same class between both flavors with *_async suffixes on your middleware methods. If Falcon allowed this, that would be a good option for my use-case.

In local testing, I also found that async code can override sync methods of the same name. E.g. this works:

class OpenApi:
    def on_get(self, req, resp):
        # Generate OpenAPI spec here
        spec = {}
        resp.media = spec

class OpenApiAsync(OpenApi):
    async def on_get(self, req, resp):
        super().on_get(req, resp)

Presumably the reverse is also possible, and in either case if significant work is being one in the parent I should be wrapping it in a thread or asyncio.run() or whatever. There are likely other approaches, as well.

I don't have any particular strong opinions about what direction makes sense, but wanted to discuss it with the broader Falcon community/devs.

[CaselIT]

Hi,

I think this could make sense, but I'm not sure how to best make this coexist with the current suffix keyword present in the router.
Maybe when the application is async it would prefer looking at on_{methpd}[_suffix]_async before falling back to on_{method}[_suffix]?

What do you think @vytas7 and @kgriffs

[vytas7]

As mentioned, I was thinking to commit a falcon-sync package that could afford easier sharing of different components. But the emphasis would be on compatibility and ease of migration, not performance.