🥷

Djangoで快適にAPIを開発する!Django Ninja

2025/02/18に公開

こんにちは、Globe-ingのCTOを務める上田です
私たちGlobe-ingでは、バックエンドの開発言語として主にPythonを使っています。
本記事では、私たちが一般的によく使われるDjango REST frameworkやFastAPIではなく、あえて「Django Ninja」を選んだ理由と、その魅力についてご紹介します。


Django Ninjaとは

Django Ninjaは、作者自身がFastAPIに強くインスパイアを受けた[^https://django-ninja.dev/motivation/]と語っているように、DjangoベースでFastAPIライクな開発体験を提供するライブラリです。
Pythonの型ヒントとPydanticによるAPI入出力の定義やSwagger UIの自動生成、デコレータで直感的にルーティングを定義できるといった、FastAPIの“使いやすいところ”をそのままDjango上で実現してくれます。

from ninja import NinjaAPI, Schema

api = NinjaAPI()

class Item(Schema):
    name: str
    description: str

@api.get("/items/{item_id}", response=Item)
def read_item(request, item_id: int):
    return Item(name="Foo", description="Bar")

このように、FastAPI経験者であればほぼ直感的に理解できる書き方でAPIを定義できます。
さらにDjagoNinjaではDjangoのコア機能(ORM・マイグレーション・管理画面など)をそのまま活用できるのも大きな強みです。DjangoのBatteries included(必要なものをひと通り標準装備している)思想の恩恵を受けて、豊富なエコシステムやプラグイン(Awesome Django)を活用できるのも魅力的です。

他ライブラリとの比較

マイクロフレームワーク (FastAPI, Flask)

FastAPIやFlaskのようなマイクロフレームワークは、軽量で柔軟な反面、ORMやマイグレーションツール、管理画面などの周辺機能を個別に探して組み合わせる必要があります。
たとえばFastAPIの場合は、SQLAlchemy、Alembic、sqladminなどを組み合わせるのが一般的です。テストのたびにデータベースをマイグレートしたり、クリーンナップ処理を自前で書くのもなかなか手間です。
スタートアップでスピード感を大切にする私たちにとって、開発に必要な機能が最初から用意されているDjango + Django Ninjaの方が、初期セットアップを省きつつ素早く開発を進められると考えました。

Django REST framework

DjangoでAPIを作る際には、Django REST framework(DRF)が定番です。
DRFはモデルとレスポンスを直接対応させるシリアライザやビューセットが非常に便利で、シンプルなCRUD機能をサクッと作るには最強の選択肢です。

from django.db import models
from rest_framework import serializers, viewsets

class Item(models.Model):
    name = models.CharField(max_length=100)
    description = models.TextField()

class ItemSerializer(serializers.ModelSerializer):
    class Meta:
        model = Item
        fields = '__all__'

class ItemViewSet(viewsets.ModelViewSet):
    queryset = Item.objects.all()
    serializer_class = ItemSerializer

router = routers.DefaultRouter()
router.register(r'items', ItemViewSet)

一方で、複雑なビジネスロジックやドメイン駆動設計(DDD)を取り入れたい場合は、テーブルとレスポンスを直接マッピングするアプローチが足かせになりえます。
データベースの定義とビジネスロジックが密結合しがちで、複雑になるほど「シリアライザやバリデータの定義が増える」「ビジネスロジックがどこに書いてあるかわかりづらい」といった課題を以前の開発で感じていました。
今回はビジネスロジックを明確に分けて管理したいという方針があり、結果的にDjango Ninjaの方が私たちの設計思想に合っていました。
PoCや小規模サービスの立ち上げでは、DRFが短期集中で完成度の高いものを作るには最適なので、使い分けるのが良いかもしれません。

DjangoNinjaを採用してみて

Django Ninjaはまだ情報量がDRFほど多くはなく、GitHubのスター数も少なめ(DRF: 28k, Django Ninja: 7k)だったことから、最初は若干の不安がありました。しかし、ドキュメントもしっかりしており、メンバーにFastAPI経験者がいたので導入を決定して、実際に使ってみて正解でした。

  • 導入のしやすさ
    FastAPIとの類似点が多いため、使い方の習得もスムーズ。Djangoの管理画面やORMをすぐに使えるので、開発初期のセットアップで手間取らず、本質的な機能開発に集中できました。

  • ドキュメント自動生成でフロント連携が楽
    Swagger UIが自動で生成されるため、フロントエンド(Nuxt.js)はNuxtOpenFetchを利用して、型安全にAPIを呼び出すことが可能に。フロントとバックの連携をスムーズに行えています。

  • Django資産の活用
    たとえばdjango-import-exportを使ったデータのインポート/エクスポートや、管理画面を通じたマスタ編集なども簡単。その結果、プロダクトマネージャが自分でマスタデータを編集できるようになり、開発者の負担が減りました。

  • DDDへの柔軟な対応
    Django Ninjaでは、レスポンスとモデルが密結合せず、Pydanticベースで入力・出力を定義できるため、DDDの戦術的設計を反映しやすいです。ビジネスロジックとデータ永続化の責務をしっかりと分けられるので、成長フェーズでも拡張しやすいアーキテクチャを保てています。

まとめ

「Django Ninjaって何がいいの?」
答えはとてもシンプルで、Djangoの資産を最大限活かしつつ、FastAPIのように軽やかに開発できることに尽きます。

  • Djangoチームの知見を活かしたまま
  • Djangoのエコシステムで開発を加速
  • DDD/クリーンアーキテクチャのようなアーキテクチャにも柔軟に対応

Globe-ingでは、こうした新しい技術やアーキテクチャを積極的に取り入れ、チーム全員で学び合いながらプロダクトを育てていくことを大切にしています。もし興味を持っていただけたら、ぜひ私たちと一緒にチャレンジしませんか?

採用ページやお問い合わせから、いつでもご連絡をお待ちしています!

Globe-ingテックブログ

Discussion