FastAPIで4プロジェクトを2週間で作ってわかった「最初に知りたかった」こと

「FastAPIって簡単そうだし、サクッと複数プロジェクト作れるんじゃないか？」

そう思って走り出すと、意外なところで時間を溶かしてしまう——そんな経験、ありませんか？

海外の開発者が2週間で4本のFastAPIバックエンドを連続で構築した体験談がdev.toで話題になっています。REST API・Webスクレイパー＋ダッシュボード・ReactのAdminパネル・CrewAIを使ったAIワークベンチ。合計134のPythonファイル・38テスト・CIが15回連続で失敗というリアルな数字が並んでいます 😅

この記事では、その体験談をベースに「FastAPIを本格的に使う前に知っておくと差がつくポイント」を日本語で整理してお届けします！

Contents

🐳 Docker Composeの構成を毎回コピペしていませんか？
⚡ FastAPIで「最初に知りたかった」3つの教訓
まとめ

🐳 Docker Composeの構成を毎回コピペしていませんか？

FastAPI python backend / Photo by Nemuel Sereti via Pexels

話題の投稿でまず指摘されていたのがDocker Composeの沼です。

プロジェクトごとに api・postgres・redis・celery・nginx という同じ5コンテナ構成を使い回すことになりがち。3プロジェクト目には「docker-compose.ymlを丸ごとコピーして変数を3つ変えるだけ」という状態になったそうです。

つまり、「コピペ＝技術的負債の積み上げ」になっているわけです。

対策としておすすめなのが、共通設定をComposeのextends機能や環境変数テンプレートで分離しておくこと。こんなイメージです。

# base.docker-compose.yml（共通設定をここにまとめる）
services:
  api:
    build: .
    env_file: .env  # プロジェクトごとに .env だけ変える
    ports:
      - "${API_PORT:-8000}:8000"

  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}

ポイントをまとめるとこんな感じです。

✅ 変わる値はすべて環境変数（.env）に切り出す
✅ プロジェクトごとに .env だけ差し替えて使い回せるようにする
✅ CIで毎回ビルドし直すよりベースイメージをキャッシュしておくと時短になる

⚡ FastAPIで「最初に知りたかった」3つの教訓

体験談から見えてきた、FastAPI開発でハマりやすいポイントを整理しました。

① 非同期（async）の使いどころを最初に決める

FastAPIは非同期処理（async/await）をサポートしていますが、DBアクセスに同期ドライバを使いつつ async def で書くと、むしろパフォーマンスが落ちることがあります。「asyncを使うならDB接続ライブラリも非同期対応のものに揃える」が鉄則です。

② テストはできるだけ早い段階で書く

今回の体験でも「38テスト・CI15回失敗」という数字が出ていましたよね。FastAPIにはTestClientという便利なテストツールが標準で用意されています。

from fastapi.testclient import TestClient
from main import app

client = TestClient(app)

def test_read_root():
    # GETリクエストを送ってステータスコードを確認
    response = client.get("/")
    assert response.status_code == 200
    assert response.json() == {"message": "Hello World"}

エンドポイントを追加するたびにテストも一緒に書く習慣をつけておくと、CIで大量失敗…という悲劇を防げます 😌