なっトク！

FastAPIとDjangoを比べてみる

2023-06-04

Pythonにおいて、アカウント認証を実装できる「FastAPI」と「Django」。

この２つは、どこが違うのだろうか。

そんな疑問をchatgpt-4にぶつけてみました。

以下、その回答です。
　

FastAPIとは

たすく

まず「FastAPI」の特徴、長所、欠点を教えて

FastAPIは、Pythonで書かれたモダンで高速（高パフォーマンス）、Webフレームワークで、APIの構築に特化しています。

以下にFastAPIの主な特徴、長所、欠点について説明します。
　

特徴:

  1. 高パフォーマンス:
    FastAPIはStarlette（Webフレームワーク）とPydantic（データバリデーション）を基に作られています。

    Pythonの非同期処理をサポートしており、非常に高速です。NodeJSやGoと比較しても遜色ないパフォーマンスを発揮します。
    　
  2. 高生産性:
    FastAPIはPythonの型ヒントを使用してルート操作関数のパラメータを自動的に解釈し、リクエストの形状を理解します。

    これにより、APIを開発する際の誤りを最小限に抑えることができます。
    　
  3. 自動的なAPIドキュメント:
    FastAPIは、OpenAPIとJSON Schemaの標準に基づいてAPIドキュメンテーションを自動生成します。
    　
    また、自動的にインタラクティブなAPIドキュメンテーション（Swagger UIとReDoc）も提供します。
    　
  4. データバリデーションと直感的なエラーメッセージ:
    FastAPIはPydanticを用いて、受け取ったデータの形状を確認し、適切なエラーメッセージを自動生成します。
    　

長所:

  1. 高速:
    非同期処理を使用しており、非常に高速なAPIを作成することができます。
    　
  2. 生産性:
    FastAPIはAPIの開発を高速化するための多くの便利な機能を提供しており、それにより開発者の生産性を向上させます。
    　
  3. 堅牢性:
    型ヒントとデータバリデーションにより、エラーの少ないコードを書くことが可能です。
    　
  4. 自動的なドキュメンテーション:
    APIのドキュメンテーションを手動で作成する手間が省けます。
    　　

欠点:

  1. 若いフレームワーク:
    FastAPIは比較的新しいフレームワークであるため、一部の機能やドキュメンテーションが不足している場合があります。
    　
  2. コミュニティとリソース:
    FastAPIはFlaskやDjangoなどのより確立されたフレームワークと比べて、コミュニティが小さく、学習リソースやサードパーティ製のパッケージが比較的少ないです。
    　
  3. 非同期プログラミングの理解:
    FastAPIを最大限に活用するには、非同期プログラミングの理解が必要となります。

    これは一部の開発者にとっては学習曲線が急であるかもしれません。
    　

FastAPIは高速で、生産性を重視したAPI開発に優れたフレームワークですが、その一方でまだ発展途上であるため、特定のニーズや問題に対する解決策を見つけるのが難しい場合があります。

それにもかかわらず、その高速性と直感的な設計は、多くの開発者にとって魅力的な選択肢であると言えるでしょう。
　

DjangoとFastAPIの違い

たすく

DjangoとFastAPIは、どちらが習得しやすいか。
機能的にどちらが十分か

DjangoとFastAPIの習得しやすさについては、ある程度主観的な側面がありますが、以下に一般的な観点から解説します。
　

  1. 学習リソース:
    Djangoは比較的古くから存在するフレームワークであり、多数のチュートリアル、教科書、オンラインコースなどが存在します。

    一方、FastAPIは比較的新しいフレームワークであるため、学習リソースは少なめです。

    しかし、そのドキュメンテーションは非常に丁寧で直感的であると広く認識されています。
    　
  2. 複雑さ:
    Djangoは「バッテリー同梱」フレームワークであり、多数の機能が内包されています（認証、フォーム、ORMなど）。

    そのため、全てを理解し利用するには時間がかかるかもしれません。

    一方、FastAPIはよりスリムで、必要な機能を自由に追加できる設計になっています。

    しかし、その反面、非同期プログラミングの知識が求められる場合があります。
    　

機能面については、DjangoとFastAPIはそれぞれ異なる目的に設計されています。
　

  1. Django:
    DjangoはフルスタックWebフレームワークであり、データベースからテンプレートまで、Webアプリケーションを作成するためのすべての要素をカバーしています。

    それにより、一つのフレームワークで全てを処理できるという利点があります。
    　
  2. FastAPI:
    FastAPIはAPIの作成に特化したフレームワークで、非常に高速なパフォーマンスと高い柔軟性を持ちます。

    また、型ヒントを用いたデータバリデーションや自動APIドキュメンテーション生成などの機能を提供します。
    　

したがって、どちらのフレームワークが「十分」かは、具体的なプロジェクトの要件によると言えます。

全機能的なWebアプリケーションを開発する場合はDjangoが適しているかもしれませんが、高速なAPIを必要とする場合や、モダンな非同期プログラミングを利用したい場合はFastAPIが良い選択となります。
　

アカウント認証を実装したい

たすく

アカウント認証機能はどちらでできるのか。
FastAPIでも実装できるのか？

DjangoもFastAPIもアカウント認証機能を実装することが可能です。
　

Djangoは、フルスタックWebフレームワークであり、そのコア機能の一部として認証と権限管理を提供しています。

Djangoの認証フレームワークは、ユーザーログイン、ログアウト、パスワードの変更やリセットなどの一般的な機能を提供します。

また、セッションベースの認証からトークンベースの認証まで、様々な認証方式をサポートしています。
　

一方、FastAPIはスリムなフレームワークであり、特定の認証機能を直接提供するのではなく、認証の実装に必要なツールを提供します。

FastAPIは、セキュリティと認証に関連する多くの便利なユーティリティ（OAuth2モデル、JWTトークンなど）を提供しますが、具体的な認証のロジックは開発者が自分で実装する必要があります。
　

FastAPIの公式ドキュメンテーションでは、OAuth2を使用した認証の実装方法について詳しく解説しています。

これに従って、自分のアプリケーションに合ったカスタム認証システムを実装することができます。
　

したがって、どちらのフレームワークを選択するかは、開発者のプロジェクトの要件や個々の好みによると言えます。

全機能的な認証システムが必要で、そのための時間やリソースを節約したい場合はDjangoが適しているかもしれません。

一方、自分で細かく制御したい場合や、特定の認証プロトコル（OAuth2など）を使用したい場合はFastAPIが良い選択となります。
　

たすく

「具体的な認証のロジックは開発者が自分で実装する必要があります」

とは、どういうことか。

FastAPIの中にDjangoを組み込むことを指していますか

すみません、私の表現が少し混乱を招いたようです。

FastAPIの中にDjangoを組み込むという意味ではありません。
　

「具体的な認証のロジックは開発者が自分で実装する必要があります」とは、FastAPIが認証のためのベースとなるツールとメカニズムを提供する一方で、具体的な認証プロセス（ユーザー名とパスワードのチェック、データベースからユーザー情報の取得、トークンの生成と検証等）をコードで記述する必要があるということです。
　

FastAPIでの認証の一例として、以下のようなステップがあります：
　

  1. ユーザーがログイン情報（例えばユーザー名とパスワード）を送信します。
    　
  2. あなたのFastAPIアプリケーションは、送信されたログイン情報を受け取ります。
    　
  3. あなたが記述したコードが、データベース等から該当するユーザー情報を探し出します。
    　
  4. パスワード等が一致するかチェックします。
    　
  5. 一致する場合、トークン（例えばJWT）を生成し、それをユーザーに返します。
    　

これらのステップを実装するためのコードを、開発者自身が書く必要があるということです。

FastAPIはこのような認証プロセスをサポートするための多くの機能（依存性注入システム、セキュリティスキーム、ユーティリティ関数等）を提供しますが、具体的な実装は開発者が行います。

これに対して、Djangoはより抽象化されたレベルで認証を提供します。

例えば、Djangoはユーザー管理（Userモデル）、フォーム、ビュー、認証と認可のシステム等を自身で提供します。

これにより、開発者は具体的な認証のロジックを書く必要が少なくなります。
　

たすく

認証部分をDjangoで書いて、APIを利用する部分をFastAPIで書けばよいのですか？

DjangoとFastAPIはどちらも独立したWebフレームワークであり、通常はそれぞれが独立したプロジェクトで使用されます。

このため、一つのプロジェクトでDjangoとFastAPIを混在させることは一般的ではありませんし、実際には技術的な課題が多く存在します。
　

具体的には、両フレームワークは異なるミドルウェア、設定、ルーティング機構を使用します。

これらを一緒に使うことは、コードの複雑さを増加させ、メンテナンスが難しくなる可能性があります。
　

認証をDjangoで実装し、APIの作成にFastAPIを使用したいという場合、一つの解決策はマイクロサービスアーキテクチャを採用することです。
　
つまり、認証サービスをDjangoで実装し、その他のAPIサービスをFastAPIで実装する、というような形です。

ただし、マイクロサービスアーキテクチャは設計や運用が複雑になるため、その採用は慎重に考えるべきです。
　

それぞれのフレームワークが提供する機能とあなたのプロジェクトの要件を考慮に入れて、適切なフレームワークを選択することが重要です。
　
FastAPIはその自由度とパフォーマンスにより、API開発に強みを持っています。

一方、Djangoはその包括的な機能と大規模なコミュニティにより、全機能的なWebアプリケーションの開発に適しています。
　

たすく

メインはAPI開発だが、アカウント認証なども必要な場合、FastAPIで実装するということですか？

はい、その通りです。

FastAPIはAPI開発に特化しているため、メインがAPI開発である場合にはFastAPIが非常に適しています。

そして、FastAPIでもアカウント認証は十分に可能です。
　

FastAPIはPythonの型ヒントを用いたエンドポイントの定義、自動的なリクエストバリデーション、自動的なAPIドキュメンテーション生成など、API開発に便利な機能を多く提供します。
　

アカウント認証に関しては、FastAPIはセキュリティと認証に関連する便利なツール（OAuth2のサポート、JWTトークンの生成と解析など）を提供します。

これらを利用して、開発者自身でアカウント認証のロジックを実装することが可能です。

たとえば、ユーザー名とパスワードによる認証、ソーシャルアカウントによる認証（GoogleやFacebookなど）、トークンベースの認証など、様々な認証方式をFastAPIで実装することが可能です。
　

ただし、この場合にはデータベースやユーザーモデルなど、認証に関連する他の要素を自分で設計し実装する必要があることを覚えておいてください。

また、認証にはセキュリティが重要な要素であるため、パスワードの適切なハッシュ化やトークンの安全な管理など、セキュリティに関する知識も必要となります。
　

めんどくせぇ。アカウント認証のためのコード直接聞いちゃえ

たすく

アカウント認証のためのコードは、生成できますか

私はOpenAIによって訓練されたAIモデルであり、直接コードを生成する能力はありませんが、アカウント認証のためのFastAPIを使用した基本的なPythonコードのサンプルを提供することができます。

以下に一例を示します：
　

※コードは省略

このコードは非常に基本的なものであり、実際のアプリケーションで使用するにはセキュリティ面をさらに強化する必要があります。

パスワードはハッシュ化して保存し、JWTトークンの生成と検証には安全な秘密鍵を用いるべきです。

また、データベース操作はSQLAlchemyなどのORMを用いて行うのが一般的です。
　

PythonやFastAPI、JWTについてのより詳細な理解が必要な場合、公式ドキュメンテーションや適切な教育リソースをご覧ください。
　

たすく

このコードは本当に問題がないか？

あなたが共有したコードは、FastAPIとJWT (JSON Web Tokens) を用いた基本的な認証メカニズムの一部を実装したものです。

ユーザーがログインしてトークンを取得し、そのトークンを使って自身のユーザー情報を取得できるようになっています。

ただし、実際の本番環境で使用するには改良が必要な部分がいくつかあります。
　

  1. fake_users_db はハードコードされたユーザーのデータベースを模したものです。

    現実のアプリケーションでは、実際のデータベースと接続するようにする必要があります。
    　
  2. authenticate_user 関数でパスワードの比較を行っていますが、平文でパスワードを保存・比較することはセキュリティ上推奨されません。

    本番環境では、パスワードはハッシュ化（または塩味付けハッシュ化）し、そのハッシュ値を比較する方がよいです。
    　
  3. JWTトークンの署名と検証に使用する秘密キー（"secret"）がハードコードされています。

    本番環境では、このキーを環境変数などから読み込むようにし、レポジトリには含めない方がよいです。
    　
  4. JWTトークンのデコードに関して、現在のコードではエラーハンドリングが行われていません。

    もしトークンが不正な形式であった場合、jwt.decode() は例外を発生します。

    したがって、この関数を呼び出すコードは適切なエラーハンドリングを実装するべきです。
    　

以上の点を修正すると、より本番環境に近い安全な認証システムを構築できます。
　

ただし、このコードを動かすためにはfastapi, pydantic, python-jwtなどのライブラリが必要です。

これらはPythonのパッケージ管理ツールであるpipを用いてインストールすることができます。


上記の改善点を基に以下のようにコードを書き換えてみます。

ただし、パスワードのハッシュ化と環境変数からの秘密キーの読み込みに関しては実際の実装が必要であるため、その部分は仮のコードとなります。
　

from fastapi import Depends, FastAPI, HTTPException, status
from fastapi.security import OAuth2PasswordBearer, OAuth2PasswordRequestForm
from pydantic import BaseModel
from typing import Optional
import jwt
import os

# 仮のユーザーデータ
fake_users_db = {
    "johndoe": {
        "username": "johndoe",
        "full_name": "John Doe",
        "hashed_password": "fakehashedsecret",
        "disabled": False,
    }
}

class User(BaseModel):
    username: str
    email: Optional[str] = None
    full_name: Optional[str] = None
    disabled: Optional[bool] = None

class TokenData(BaseModel):
    username: Optional[str] = None

app = FastAPI()

oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

# ユーザーの認証を行う関数
def authenticate_user(fake_db, username: str, password: str):
    user = fake_db.get(username)
    if not user:
        return False
    # Here we would need to hash the password provided and compare it with the stored hashed_password
    # ハッシュ化されたパスワードと提供されたパスワードのハッシュ値を比較する
    hashed_password = "hash_the_password_here"
    if not hashed_password == user["hashed_password"]:
        return False
    return user

# ユーザー情報を取得する関数
def get_user(db, username: str):
    if username in db:
        user_dict = db[username]
        return User(**user_dict)

# JWTトークンをデコードする関数
def decode_token(token):
    SECRET_KEY = os.getenv("SECRET_KEY")  # 秘密キーを環境変数から読み込む
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        username: str = payload.get("sub")
        if username is None:
            return None
        token_data = TokenData(username=username)
        return token_data
    except:
        return None

# トークンからユーザー情報を取得する関数
async def get_current_user(token: str = Depends(oauth2_scheme)):
    token_data = decode_token(token)
    if token_data is None:
        raise HTTPException(
            status_code=status.HTTP_403_FORBIDDEN,
            detail="Could not validate credentials"
        )
    user = get_user(fake_users_db, username=token_data.username)
    if user is None:
        raise HTTPException(status_code=404, detail="User not found")
    return user

@app.post("/token", response_model=TokenData)
async def login_for_access_token(form_data: OAuth2PasswordRequestForm = Depends()):
    user = authenticate_user(fake_users_db, form_data.username, form_data.password)
    if not user:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Incorrect username or password",
            headers={"WWW-Authenticate": "Bearer"},
        )
    SECRET_KEY = os.getenv("SECRET_KEY")  # 秘密キーを環境変数から読み込む
    token = jwt.encode({"sub": user["username"]}, SECRET_KEY, algorithm="HS256")
    return {"access_token": token, "token_type": "bearer"}

@app.get("/users/me")
async def read_users_me(current_user: User = Depends(get_current_user)):
    return current_user

この修正版コードでは以下の改良が行われています：
　

  1. パスワードをハッシュ化して比較する部分を仮示（authenticate_user関数）
    　
  2. 秘密キーを環境変数から読み込む（decode_tokenおよびlogin_for_access_token関数）
    　
  3. decode_token関数で例外をキャッチするように改良
    　

ただし、パスワードのハッシュ化と秘密キーの管理は本番環境におけるセキュリティを確保するための重要な要素です。

この仮のコードを基に、適切なハッシュ化方式や環境変数の管理方法を適用してください。
　

  • この記事を書いた人
  • 最新記事

花丸たすく

▸高度情報処理技術者（ＩＴストラテジスト）
▸データアナリスト、ラーニング・アドバイザー
▸「学び直し」に挑戦する社会人を応援
▸落ちこぼれ→京大→教育関連企業→現在
▸「学び直し」から得た「気づき」こそ成長の源泉、現実を変える力
▸武器になる「学び直し」のキホン
▸資格取得・大学受験のエッセンス
▸「勉強マインド」作りへ、自分のノウハウを全部公開

-なっトク！
-,