From 426bd096ad5e4f3f7f3deeaa67106228a3831f00 Mon Sep 17 00:00:00 2001 From: raphaelauv Date: Thu, 7 Oct 2021 14:44:39 +0200 Subject: [PATCH] =?UTF-8?q?=F0=9F=93=9D=20Update=20note=20about=20Falcon?= =?UTF-8?q?=20and=20ASGI,=20as=20now=20Falcon=20is=20also=20ASGI=20?= =?UTF-8?q?=F0=9F=8E=89=20(#3073)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Sebastián Ramírez --- docs/en/docs/alternatives.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/en/docs/alternatives.md b/docs/en/docs/alternatives.md index d2792eb0c..28d0be8cc 100644 --- a/docs/en/docs/alternatives.md +++ b/docs/en/docs/alternatives.md @@ -242,8 +242,6 @@ It was one of the first extremely fast Python frameworks based on `asyncio`. It Falcon is another high performance Python framework, it is designed to be minimal, and work as the foundation of other frameworks like Hug. -It uses the previous standard for Python web frameworks (WSGI) which is synchronous, so it can't handle WebSockets and other use cases. Nevertheless, it also has a very good performance. - It is designed to have functions that receive two parameters, one "request" and one "response". Then you "read" parts from the request, and "write" parts to the response. Because of this design, it is not possible to declare request parameters and bodies with standard Python type hints as function parameters. So, data validation, serialization, and documentation, have to be done in code, not automatically. Or they have to be implemented as a framework on top of Falcon, like Hug. This same distinction happens in other frameworks that are inspired by Falcon's design, of having one request object and one response object as parameters.