ASGI

ASGI 规范

类似于 WSGI 协议, ASGI 是一种 web 服务器和 web 应用程序之间进行交互的接口标准.

在如 FastAPI 的 Web 框架中, 每个中间件就是一个实现了 ASGI 协议的异步协程可调用对象.

通过 ASGI 协议实现 Web 应用, 好处是应用框架本身可以脱离复杂的网络协议.

不管是 HTTP、HTTP2、WebSocket 还是以后可能会支持的更多协议, 应用本身只需要关心如何处理传入的数据流, 并根据情况将相应的数据量传递给外部实现了各种协议的服务器.

而且对于想要阅读源代码的用户来说, 这种分离机制, 使得代码功能分工更明确, 更加模块化, 我觉得是非常友好的一件事.

至于坏处, 自然是不同于其他语言或Web框架的实现, 容易给人带来一点点的困惑.

ASGI 带来的困惑

就以 FastAPI 举例, 通过以 ASGI 协议的方式实现中间件, 优点自然是规范.

用户可以框架无关的去了解中间件实现了什么功能, 并且可以很方便的将代码分享到其他同样以 ASGI 协议的方式实现中间件的框架.

至于缺点, 便是相较于 tornado、flask 这些框架, 用户即使阅读了文档, 如果对 ASGI 协议并没有很清晰的认知, 那么处理起来也是一件很麻烦的事情.

如果涉及到对响应的修改, 那么实现操作将会进一步的复杂.

自然, FastAPI也提供了如继承`FastAPI.routing.APIRoute, 通过get_route_handler实例方法得到原始的路由处理函数, 并返回一个新的路由处理函数来定制行为的方案.

这种做法, 和其他语言或 Web 框架里通过为路由函数或路由组来添加中间件的行为已经非常接近了.

同样, 也更让人对 FastAPI 中的中间件存在困惑了.

用户究竟该如何考虑以确定是使用middleware、APIRoute甚至是dependencies来定制行为呢?