Rails 経験者が FastAPI 本を読んで感じたこと

こんにちは。スナックミーでエンジニアをしているタク（@yamataku3831）です。

私は前職で6年間 Ruby on Rails で Web サービスを開発してきました。スナックミーでも Ruby on Rails で開発しているシステムがあるのですが、コンシューマー向けの Web サービスに関しては FastAPI と React を使って開発をしています。

エンジニア採用を担当する身として、自分たちが使っている技術についてもしっかり伝えられるようになりたいと思い、「動かして学ぶ！Python FastAPI開発入門」という本を手に取りました。

www.shoeisha.co.jp

サーバーサイドは Ruby on Rails でしか開発してこなかったため、この本を読んで FastAPI が魅力的に感じたり、新鮮さを感じたりする部分がありました。今回はそれらを言語化したいと思います。

私と同じように Ruby on Rails で開発をしていて、FastAPI に興味を持っている方々の判断材料になれば嬉しいです。

FastAPI に魅力を感じたところ

FastAPI 自体に魅力を感じたところや、この本の中で紹介されているものに興味をそそられたものがあったので、3つにまとめてみました。

不具合を型定義により未然に防ぐ

そもそも Python は動的型付け言語でありながらも、昨今の型を重視するトレンドに例に漏れず、「型ヒント」の仕組みが導入されています。「型ヒント」を使用することで⁠コードの可読性を向上⁠したり⁠、⁠IDEによるコード補完を充実⁠させたりすることができます。

一方で、通常「型ヒント」は実行時に影響を及ぼさない仕様になっていることが多いようです。そのため、以下のように指定した型とは異なる値を変数に格納しても、Python ではエラーを発しません。

>>> order: int = 1
>>> order = ‘string’

しかし、FastAPI では Pydantic というライブラリの力によって、API の入出力のバリデーションを行う仕様となっています。それにより、想定していない値を返却すると以下のようなエラーが発生するようになっていて、フロントエンドとバックエンドを接続して動作確認をする前に不具合を検知することができるというメリットがあります。

pydantic.error_wrappers.ValidationError: 1 validation error for Task
number
  value could not be parsed to a integer (type=type_error.integer)

Ruby 3.0 で Ruby にも型定義情報を提供する RBS という仕組みが導入され、Ruby on Rails でのアプリケーション開発でも型を使った開発が可能になっているようです。私は当時型を使用してプロダクト開発をしていなかったため、開発効率を向上する上で非常に強力な仕組みだと感じました。

特に TypeScript の普及によって型を使用した開発が一般的になってきたフロントエンド開発との相性が良さそうという印象を受けました。

フロントエンドとの協業をスムーズにする仕組み

昨今のプロダクト開発において、フロントエンドとバックエンドを分離して開発する場合が多く見られるような気がします。FastAPI はそういった開発において本領を発揮するフレームワークであるとも感じました。

FastAPI では Router にパスオペレーション関数を定義し、リクエストとレスポンスのスキーマを定義した段階で、Swagger UIのドキュメントと API モックが自動的に提供されます。

swagger.io

つまり、ビジネスロジックなど詳細な実装に手をつける前に、フロントエンドの実装に着手することができます。また継続したプロダクト開発において起こりがちな、ドキュメントの更新漏れやそれに伴って起きる実装の手戻りなどを、普段の開発の流れで解消することができる仕組みにもなっています。

以前 Ruby on Rails で開発していた時は、API を追加したり更新した場合は「忘れずに Apipie-rails のドキュメント部分も更新しましょう」といった呼びかけをしていました。そういった中で更新が漏れたりすると「やってしまった」とネガティブな気持ちになりがちだったことを思い出しました。

そういったことがこの仕組みによって改善され、精神衛生を保つことにもつながり、モチベーションとパフォーマンスを高く保ちながら開発できるひとつのソリューションになりそうだと感じました。

保守性を高めやすいアーキテクチャー

これは FastAPI 自体の魅力というよりかは、この本の中で紹介されていたアーキテクチャーに関する魅力なのですが、MVC モデルで問題になりがちな Controller や Model の肥大化を、極力避けれるような設計がなされています。

これは FastAPI のフレームワーク自体がもつ高い自由度だからこそ為せる業になりますが、この本では CRUD の処理が Router（MVC における Controller）から切り離されていました。これによって、処理やロジックをカプセル化できるようになるため、再利用性が向上することで、テスタビリティも向上することができます。

Ruby on Rails で開発している時は、Controller の中で CRUD の処理を書いていました。ただでさえ条件分岐が多くなりがちな Controller で、条件付きのデータアクセスを実装すると、その分だけテストケースが増えてしまいます。その条件分岐やそれを網羅するためのテストを Controller の外でかけるのは、非常にありがたいなと感じました。

FastAPI に新鮮さを感じたところ

自前でエクセプションを返す必要がある

この本では、データが見つからなかったときに 404 の HTTP エクセプションを返す処理を自身で実装していました。

私はこれまで Ruby on Rails で開発してきて、Active Record や Action Controllerといった仕組みの恩恵に与ってきていたこともあり、自身でエクセプションを返さなくても自動的に 404 エラーを返せていました。

そういったこともあり、実装者自ら明示的にコーディングしている点に新鮮さを感じました。忘れないよう都度実装したり、スナックミーのテックブログでも紹介させていただいているようにモジュール化したりする必要がありそうです。

labs.snaq.me

自由度の高い設計が可能

Ruby on Rails の設計理念のひとつに「CoC（Convention over Configuration: 設定より規約）」というものがあります。前職では可能な限り Ruby on Rails の規約に則り、Rails Way に沿ったプログラミングをしていたので、特にチーム開発において余計なコミュニケーションコストやドキュメント管理コストなどが発生しないよう意識しながら開発していました。

rubyonrails.org

一方で FastAPI は Ruby on Rails と比べると自由度が高いため、チームでどういった設計で実装していくのか、しっかり認識を合わせた上で開発していく必要があると感じました。現に弊社では DDD を意識して開発していることもあり、domain というディレクトリを作って、そこに各ドメインに依存したロジックなどをまとめていたりします。