はじめに

初めまして。フューチャーの社内セキュリティ部門、SATの髙橋です。部門におけるシステムのテックリードとして、日夜活動しています。

先日、当部門が運用する社内向けWeb業務システムの更改がなされ、その中で、FastAPIを採用したAPIサーバの構築をしました。

本記事では、FastAPIを選定した理由や、そもそもFastAPIがどのようなものかについて、簡単に紹介します。

ちなみに、以下の記事でも、FastAPIに関して触れられていますので、併せてご覧ください。

なぜFastAPIを選んだのか

前提として、本システムにおけるサーバサイドの実装言語は、Pythonをチョイスしています。

業務システムとしての言語としては、より堅牢な言語を選ぶべきだと考えらえそうですが、最大の理由として、すでに他業務にてPythonを用いて動くシステムを多数構築しており、その知見や今後のシステム間連携等を踏まえるとPythonが最適解であったためです。

近頃のPythonは、弱点とされていた型システム周りにおいて、より強固かつ使いやすくなる改善が多数あり、パフォーマンスにおいてもコンパイラの改善等が予定されているため、業務システムでも裾野を広げていくのではないかと個人的には見ています。

そんなPythonで、APIサーバを構築するためのフレームワークとしては、以下の３つが代表例としてよく挙げられると思います。

まず、Djangoですが、大規模なWebアプリケーションに向いたフルスタックフレームワークとして知られています。

APIだけでなく、フロントエンド、DB（ORM）も含め、すべてをDjangoで構築するということもできるようでした。

しかし、一つのフレームワークへの依存度が高くなることや、システム規模に対して、フレームワークとしての機能が重厚すぎることから、
検討段階で、採用は見送られました。

次に、Flaskです。

こちらは対照的に、軽量でよりAPIサーバに特化しています。必要最低限の機能提供がベースとなっていて、プラグインでの機能拡充ができる作りとなっていました。

実装方法も至ってシンプルな作りで、学習コストも低いです。本システムにおいても、FastAPIを最終的に採用するまで、主にプロトタイプ開発で利用を行っていました。

最後に、FastAPIです。こちらもFlaskと同様に、APIサーバ構築に特化したフレームワークです。

最大の特徴としては、データモデルライブラリのPydanticとの連携による型ヒントの充実、
非同期処理への対応も可能な処理の高速さ、そして何よりOpenAPI定義、API Docを自動で生成する機構が備わっている点があり、保守性向上に大きく貢献してくれています。

これらを、最終的に以下のような観点で評価を進め、FastAPIを採用することにしました。

フレームワーク	機能性	学習容易性	将来性（保守性）
Django	◎	N/A (未評価)	〇
Flask	〇	◎	〇
FastAPI	◎	◎	◎

FastAPIには、次のような特徴があります。

開発のしやすさは、対象のメソッドにアノテーションを付与するだけで、エンドポイントやミドルウェアの処理が定義できるため、フレームワーク特有の記述が少なく済んでおり、コードを簡潔に保つことができています。

個人的に最も恩恵を受けているのは、Pydanticとの連携が強固な点で、普段使っているVSCodeでも入力補助が得られるため、開発体験がとても良いです。

また、アーキテクチャとしてクリーンアーキテクチャ風の構成を取っていますが、ドメインモデルをPydanticで定義し、FastAPIで活かすといったシナジーが得られるため、
自然と堅牢なシステムが構築できます。

依存性注入の仕組みは、まだ実務で適用できていませんが、今後のシステム拡充で採用をしてみたいところです

実務において、なぜFastAPIを選定したのか選定理由と、簡単なFastAPIの紹介をさせていただきました。

FastAPIは、コンパクトなフレームワークでありながら、快適なAPI開発を進めるのにイチオシなフレームワークです。Pydanticとの連携による開発体験は一度試すとなくてはならないものになります。

PythonでAPIを開発する際はぜひ検討してみてください。