Sanic フレームワーク

# バージョン21.9

# 概要

これはバージョン21の3つ目のリリースサイクルです。 バージョン21は、12月の長期サポート版リリースで「確定」する予定です。

# 知っておきたい

詳しくはChangelog (opens new window)をご覧ください。注目すべき新機能・不具合、アップグレード対象など...

# 設定値の削除: WEBSOCKET_READ_LIMIT、WEBSOCKET_WRITE_LIMIT、WEBSOCKET_MAX_QUEUE

ウェブソケット実装の全面的な見直しに伴い、これらの設定値は削除されました。現在、これらを置き換える予定はありません。

# FALLBACK_ERROR_FORMATのデフォルト値の非推奨

エラーハンドラが添付されていない場合、Sanicはフォールバックのフォーマットタイプとしてhtmlを使用してきました。これは非推奨となり、v22.3からtextに変更される予定です。この値は auto に変更されましたが、変更前の v21.12LTS までは、最後の手段として HTML を使用し続けるでしょう。

# ErrorHandler.lookup署名の非推奨

ErrorHandler.lookupは今、2つの位置専用引数を必須にしています:

def lookup(self, exception, route_name: Optional[str]):

不適合なメソッドを使用すると、Blueprint 固有の例外ハンドラが適切にアタッチされない原因となります。

# 今後の機能削除のお知らせ

注意点として、以下の項目はすでに非推奨となっており、バージョン21.12LTSで削除される予定です。

  • CompositionView
  • load_env (代わりに env_prefix を使用)
  • サニックオブジェクト（アプリケーションインスタンス、ブループリント、ルート）は、以下に準拠した英数字を使用する必要があります。^[a-zA-Z][a-zA-Z0-9_\-]*$
  • アプリケーションとブループリントのインスタンスへのオブジェクトの任意の割り当て (代わりに ctx を使用します。この削除は 21.9 から 21.12 にバンプされました)

# ウェブソケットの全面見直し

ウェブソケット接続の取り扱いについて、大きな見直しが行われました。@augustin (opens new window) のおかげで、websockets (opens new window) に新しい実装が追加され、Sanic が自分自身でウェブソケット接続の I/O を処理することができるようになりました。そのため、Sanicは最小バージョンを websockets>=10.0 に引き上げました。

この変更は、Sanicのウェブソケットハンドラに関するいくつかの奇妙な点が修正されたことを除けば、開発者にはほとんど気づかれないはずです。例えば、誰かが切断したときに CancellError を自分で捕らえることができるようになったはずです。

@app.websocket("/")
async def handler(request, ws):
    try:
        while True:
            await asyncio.sleep(0.25)
    except asyncio.CancelledError:
        print("User closed connection")

# ビルトイン信号

バージョン 21.3 で signals が導入されました。現在、Sanicはコードベース自体からシグナルイベントをディスパッチします。これは、開発者が以前よりもはるかに近いレベルでリクエスト/レスポンスサイクルにフックする能力を持っていることを意味します。

これまでは、何らかのロジックを注入しようとすると、ミドルウェアに限られていたのです。統合シグナルは「スーパーミドルウェア」だと考えてください。現在ディスパッチされるイベントは以下の通りです。

  • http.lifecycle.begin
  • http.lifecycle.complete
  • http.lifecycle.exception
  • http.lifecycle.handle
  • http.lifecycle.read_body
  • http.lifecycle.read_head
  • http.lifecycle.request
  • http.lifecycle.response
  • http.lifecycle.send
  • http.middleware.after
  • http.middleware.before
  • http.routing.after
  • http.routing.before
  • server.init.after
  • server.init.before
  • server.shutdown.after
  • server.shutdown.before

Note

serverシグナルは、4つのメインサーバリスナーイベントと同じです。実際、これらのリスナーはシグナルを実装するための便利なラッパーに過ぎません。

# より賢い自動例外フォーマット

Sanicは現在、エンドポイントとクライアントに基づいた適切な例外フォーマットで応答しようとします。たとえば、エンドポイントが常に sanic.response.json オブジェクトを返す場合、例外はすべて自動的に JSON でフォーマットされます。同じことが、 text と html のレスポンスにも当てはまります。

さらに、ルート定義により、ルートごとに使用するフォーマッターを_明示的に_制御できるようになりました。

@app.route("/", error_format="json")
async def handler(request):
    pass

# ブループリントのコピー

ブループリントは、新しいインスタンスにコピーすることができます。これは、ルートやミドルウェアなど、それに付随するすべてのものを引き継ぎます。

v1 = Blueprint("Version1", version=1)
@v1.route("/something")
def something(request):
    pass
v2 = v1.copy("Version2", version=2)
app.blueprint(v1)
app.blueprint(v2)

/v1/something
/v2/something

# ブループリントグループの便利なメソッド

ブループリントグループは、通常のブループリントと同じすべてのメソッドを使用できるようになりました。これにより、ブループリントのコピーと合わせて、ブループリントは非常にコンポーザブルで柔軟なものになるはずです。

# Acceptヘッダーの解析

SanicのRequestオブジェクトは Accept ヘッダーをパースして、クライアントの content-type の優先順位のリストを提供することができます。単純にアクセッサとしてアクセスすることができます。

print(request.accept)
# ["*/*"]

また、ワイルドカードでの照合も可能です。例えば、受信したリクエストに含まれるものとして:

Accept: */*

その場合、以下は True となります。

"text/plain" in request.accept

# デフォルトの例外メッセージ

SanicException から派生した例外はすべて、デフォルトの例外メッセージを定義できるようになりました。これにより、複数の場所で同じ例外を再利用する際に、例外が提供するメッセージに関するDRY問題が発生しなくなり、より便利で保守しやすくなりました。

class TeaError(SanicException):
    message = "Tempest in a teapot"
raise TeaError

# 型アノテーションの利便機能

Pythonの型アノテーションを利用して、パスパラメータの型を制御することが可能になりました。次のようにする代わりに、

@app.route("/<one:int>/<two:float>/<three:uuid>")
def handler(request: Request, one: int, two: float, three: UUID):
    ...

次のようにシンプルにできるようになりました。

@app.route("/<one>/<two>/<three>")
def handler(request: Request, one: int, two: float, three: UUID):
    ...

これらの例では、どちらも同じルーティングの原則が適用されることになります。

# 明示的な静的リソース型

静的なエンドポイントに、リソースをファイルとして扱うかディレクトリとして扱うかを明示的に指示できるようになりました。

static("/", "/path/to/some/file", resource_type="file"))

# ニュース

# sanic-ext のリリースと sanic-openapi の非推奨化

サニックの基本理念のひとつは、「独裁者ではなく、道具であること」です。このホームページのトップページにあるように、

ツールに制約されることなく、構築したい方法で構築。

これは、（特にWeb API開発者が）使用する多くの一般的な機能が、sanicリポジトリに存在しないことを意味します。これには良い理由があります。独創的であることは、開発者に自由と柔軟性を与えます。

しかし、時には同じものをビルドしたり再構築したりする必要がないようにしたいものです。Sanicはこれまで、プラグインでギャップを埋めるために、コミュニティの素晴らしいサポートに本当に頼ってきました。

初期から、公式の sanic-openapi パッケージがあり、アプリケーションに基づいた OpenAPI ドキュメントを作成する機能を提供していました。しかし、このプロジェクトは何年も悩まされ、メインプロジェクトほどの優先度は与えられていませんでした。

v21.9 のリリースから、SCOはsanic-openapiパッケージを非推奨とし、メンテナンスモードへ移行します。これは、現在の将来を維持するために必要なアップデートは継続されますが、新しい機能の拡張は行われないことを意味します。

その代わりとして、 sanic-ext という新しいプロジェクトが導入されます。このパッケージは、OAS3ドキュメントを構築する機能を提供するだけでなく、API開発者がアプリケーションで必要とする多くのギャップを埋めることができます。例えば、CORSをセットアップし、必要に応じてHEADとOPTIONSレスポンスを自動で有効にすることができます。また、標準ライブラリのデータクラスやPydanticモデルを用いて、入力されたデータを検証することができます。

機能一覧は以下の通りです。

  • CORS保護
  • 受信リクエストの検証
  • RedocやSwagger UIを使った自動OAS3ドキュメント作成機能
  • 自動的な HEAD、OPTIONS、TRACE レスポンス
  • 依存性注入
  • レスポンスシリアライゼーション

このプロジェクトは今のところまだ alphaモードであり、変更される可能性があります。実運用に耐えうるものと考えていますが、機能追加を続ける中でAPIを変更する必要があるかもしれません。

詳しくは ドキュメント をご覧ください。

# 感謝

今回のリリースに参加された皆様、ありがとうございました。👏

@aaugustin (opens new window) @ahopkins (opens new window) @ashleysommer (opens new window) @cansarigol3megawatt (opens new window) @ChihweiLHBird (opens new window) @gluhar2006 (opens new window) @komar007 (opens new window) @ombe1229 (opens new window) @prryplatypus (opens new window) @SaidBySolo (opens new window) @Tronic (opens new window) @vltr (opens new window)

そして、ドキュメントの同期と中国語への翻訳を維持してくれた@miss85246 (opens new window) と @ZinkLu (opens new window) には、多大なる感謝を捧げます。

もし、このプロジェクトを楽しんでいただけるなら、ぜひ貢献をご検討ください。もちろん、コードの貢献も大好きですが、どんな形の貢献も大歓迎です。ドキュメントを書いたり、ユースケースを見せたり、会話に参加してあなたの声を伝えたり、もし可能なら金銭的貢献 (opens new window)も検討してください。

← バージョン21.6 →

MIT Licensed
Copyright © 2018-present Sanic Community Organization

~ Made with ❤️ and ☕️ ~