kgriffs/falcon-3.0-roadmap.md

No apologies are necessary, you guys are doing a great job. I put a project on hold for a year because I wanted to use falcon but wanted to do so with web socket support for real time collaboration. I do not regret that decision at all and will patiently keep waiting. I understand that everyone thinks their application is the most important focus in the world right now but don't let yourself feel pressured because of it. You guys take care of yourselves first and foremost and we'll happily keep waiting and be content when it's released. I am going to start building up the new API with the pre-release and see if I cant get some web socket stuff going as well as looking into umongo for async db. You guys just keep doing what you are doing and know that we all appreciate it greatly.

R,
Nate

Are websockets still targeted for 3.0, or are they likely to be moved back to 3.1? I've been plugging away at a personal project using the 3.0 alpha that I knew was going to need websocket support down the road, but it turns out I'll need it earlier in the process than I thought. I'm trying to figure out if I should postpone work on this section of the app on the assumption that websockets will be included in 3.0 with some patience, or if I should evaluate lesser frameworks.

Thanks for your work on 3.0! I'm really enjoying the ASGI support so far.

Hi @onecrayon, thanks for reaching out. I can't promise anything, but I will take a look and see if I can get an initial WebSocket implementation done for 3.0. I don't want to push out the release any longer than we have to (since things already got a bit delayed) but I may be able to sneak something in while @vytas7 is finishing up multipart/form-data.

If you have thoughts on https://gist.github.com/kgriffs/023dcdc39c07c0ec0c749d0ddf29c4da please let me know!

@kgriffs that would be awesome; I am in the same boat as @onecrayon. Out of curiosity what needed to be done with multipart/form-data? Asking just encase it will impact those of us using the alpha.

Hi @nmcbride ! Proper ASGI support is lacking for multipart/form-data. You could probably (attempt to) parse it with the current handler in ASGI too, but then the whole form would be first buffered in a bytestring, and possibly other bad things would happen.

The WSGI multipart code has not seen any changes since the first alpha yet (bar some docs polish) AFAIK.

Multipart (ASGI): I have finally resumed active work on the async multipart/form-data parser.

Although I still have one edge case memory usage tweak in mind (and the whole thing is probably not very optimized for small wrapped stream reads), but it is hopefully getting usable. Also working on the corresponding tests (very sparse atm) and docs (missing altogether).

This Gist explains how to test the current state of the prototype: multipart/form-data demo in ASGI Falcon.

Thanks I'm getting ready to test it out and will let you know how it goes.

Multipart (ASGI): PR #1728 is ready for review! The ASGI multipart/form-data demo Gist is still valid, don't hesitate to give it a spin 😉

As the next step, I'll try to clean up my offshore Falcon+ASGI tutorial and submit it as a PR.

Furthermore, we have a couple of high impact breaking changes and other items needing decision left, mostly related to request query parameter and media handling.
And, as always, merging the PR backlog from our awesome community.

Multipart (ASGI) (PR #1728) – ready for the second round of reviews! Thanks @kgriffs & @CaselIT for feedback.

I have also proposed PRs (some have already got merged) for several smaller high-priority issues within the 3.0 milestone, as well as created a couple of documentation recipe PRs based on discussions on our Gitter channels.

Next, I'm aiming at finishing and cleaning up my ASGI tutorial PR, as well as moving it from Draft.

ASGI Multipart PR has been merged!

ASGI WebSocket:

• Interface: https://gist.github.com/kgriffs/023dcdc39c07c0ec0c749d0ddf29c4da
• Draft PR: falconry/falcon#1741

3.0.0a2 Was just published. Kick the tires and let us know what you think! This version adds ASGI support to the new multipart form parser and a number of other tweaks and optimizations, as well as improved docs. I have updated the roadmap above to reflect planned next steps.

WebSocket implementation is completed and docs for the same are 90% done. I will be updating my PR and taking it out of draft status very soon. Let's try to get the first beta out over the next two weeks.

WebSocket PR merged: falconry/falcon#1741

3.0.0a3 is now available with WebSocket support and cythonized wheels! This is our final alpha, so please give us feedback on any design changes you might want for the new features! The first beta is just around the corner.

First beta should be available very soon.

ASGI tutorial PR merged: https://falcon.readthedocs.io/en/latest/user/tutorial-asgi.html

I am pleased to announce that the first beta is now available on GH and PyPI. RTD has also been updated so you can select 3.0.0b1. More info here: https://github.com/falconry/falcon/releases/tag/3.0.0b1

Second beta should be landing soon.

New: Second beta now available for testing. First release candidate will arrive soon, so please test this beta ASAP. Thanks! https://github.com/falconry/falcon/releases/tag/3.0.0b2

https://github.com/falconry/falcon/releases/tag/3.0.0rc1

rc2 is now available - https://github.com/falconry/falcon/releases/tag/3.0.0rc2

Silly question, but are you still supporting Cython in v3.0? I ask because I wasn't sure if you were going to ship Cythonized versions of the package or if you want us to do a command like pip3 install -v --no-binary :all: falcon==3.0.0rc2 every time we install.

I've also been using Poetry for the past year or so and it has been great: https://python-poetry.org/

Hi @btegs,
And sorry for the confusion, we'll check the docs.

But the answer is that we are shipping wheels for all popular platforms and architectures, so normally you shouldn't need to cythonize manually that way.

Hi @btegs,
And sorry for the confusion, we'll check the docs.

But the answer is that we are shipping wheels for all popular platforms and architectures, so normally you shouldn't need to cythonize manually that way.

Sounds good. Btw have you tried Poetry before? I find it handy when I mix it with pyenv, install the Python version I want, then use either a local or global .python-version and run poetry new project1 to keep everything organized and manage my packages in the .toml file.

I've tried Poetry briefly, but haven't looked more in depth. It is listed as one of the alternatives if/when we decide to proceed with PEP 517. Poetry looks to be the most solid option for managing dependencies by a country mile, but, OTOH, Falcon has no hard dependencies on any third party library.

Resorting to pip install --no-binary :all: ... is still needed in case the wheel is unavailable, which might happen in the following scenarios:

• No wheel is available for the interpreter in question, e.g., Python 3.10 is released and our stable release won't have a wheel for that.
• No wheel is available for the architecture in question, like i386 etc.
• It is desirable to deploy a version other than a release on PyPi, e.g., the latest GitHub snapshot etc.

Btw regarding Falcon 3.0 + Cython, there are some good news, and some worse:

• ➕ (Blowing my own 🎺 here) we are now offering pure Cython code for certain parts of the framework, like decoding a query string. On CPython, this can outperform the std lib by an order of magnitude for percent-encoded query strings.
• ➖ Parts of our ASGI code are not cythonized, as we haven't found any way to utilize a cythonized coroutine in any ASGI server. It seems that wrapping it in another Python async task degrades the performance to worse than pure Python. We'll circle back on this in 3.1: maybe there is a way to speed up coroutines with Cython in a more usable way, or maybe we could offer patches to the popular uvicorn (or other ASGI servers) to somehow remove the said barrier, if at all possible. FWIW, to that end, we have also tried Cython 3.0 alpha, and while that offered a slight improvement, it did not eliminate the issue.

Btw, absent critical bugs, the plan is to ship a stable release on Monday or Tuesday (6th/7th April).

Btw, absent critical bugs, the plan is to ship a stable release on Monday or Tuesday (6th/7th April).

Awesome!

The final release is here! https://github.com/falconry/falcon/releases/tag/3.0.0

First bug fix release: https://github.com/falconry/falcon/releases/tag/3.0.1