Python Sanic或異步框架使用Asgiref的原因？

Question

我知道答案是“永遠取決於”，但總的來說，會有理由在Sanic等Async框架中使用asgiref包裝器。

https://github.com/django/asgiref https://github.com/channelcat/sanic

我的主要問題是，為什么有人會在異步框架中使用它，我理解Django的用例，但是如果您考慮了異步編程，那么類似的東西似乎有點懶惰，可以解決問題。

告訴我我錯了。

Answer 1

我對asgiref特別不熟悉。 但是，話雖如此，我對asgi的想法很熟悉，可以替代wsgi。

用Sanic來說，這是無關緊要的。 Sanic具有內置的自己的服務器 ，並且開箱即用地異步運行。

我不想告訴您您本身是錯誤的，但是在Sanic世界中我看不到它的用處。

Answer 2

一，背景：

一些異步框架（如sanic和aiohttp早於ASGI成熟的時間，並且因為它適合用作異步服務器/應用程序接口。

結果，他們已經在其代碼庫中內置了Web服務器實現。 他們可以改用ASGI作為接口，而不是自己的內部接口，但這對他們的維護人員來說意味着很多工作。

那么，為什么它可能是值得的？

好吧，如果這樣做，他們將獲得的好處是：

• 能夠在多種不同的服務器實現下運行。 （要么自己的實現，或任何一種uvicorn ， hypercorn ， daphne服務器。）能夠實現服務器之間透明切換給出了一個更堅固的生態系統，意味着服務器實現可以跨框架共享。 Sanic將獲得具有HTTP / 2支持，Windows支持和PyPy支持的服務器實現，並且可以解決套接字流控制所存在的一些突出問題。
• 能夠受益於共享中間件和其他工具。 能夠編寫可在任何ASGI框架上運行的中間件將對整個生態系統有所幫助。 您可以編寫可與任何ASGI框架一起使用的調試中間件，靜態文件服務，測試客戶端等，而不必為每個框架構建新東西。
• 降低復雜度。 擁有經過徹底設計和獨立的服務器/應用程序界面，有助於減少開發人員在查看應用程序框架內部時需要考慮的表面積，因為這意味着您已經在服務器代碼和應用程​​序代碼之間建立了充分記錄的界限。
• 可組合 由於ASGI是可組合的界面，因此您可以通過有用的方式將其組合。 例如，在同一個Web服務器上服務兩個不同的Sanic應用程序。

簡而言之，出於與WSGI有益相同的原因，ASGI是有益的。 對於sanic而言，這sanic一個勝利，而對於現在編寫一個新的asyncio框架的任何人來說，這都不是一個勝利，因為他們已經完成了編寫服務器實現的所有繁重工作，但是這樣做仍然有很多好處，而且它d絕對是整個社區的勝利。

相關： Sanic上的ASGI門票 。

（還請注意， asgiref只是一個Python軟件包，帶有一些用於處理ASGI框架的幫助程序，這恰好是保存ASGI規范文檔的存儲庫。問題實際上是關於將Sansig用作ASGI，而不是使用asgiref 。）