HerokuにデプロイしたDjangoアプリに、データを一覧するエンドポイントをDjango REST Frameworkで生やして、データをエクスポート

はじめに

お返し申す！¹ nikkieです。

HerokuでいくつかのDjangoアプリを動かしていましたが、この週末はお片付け。
Herokuのアプリを消す前に、DBに格納されたデータをエクスポートします（アプリ自体はもう使っていないのでデータを保管したらアプリは消します）。
11/26のPython mini Hack-a-thonで取り組みました²。

※筆者はDjangoを実務でバリバリ使っているわけではなく、今回の実装はDjangoアプリの練習（ごく小規模なアプリでうまくいった例）といった趣です。
このブログの情報を実務で利用する場合には、紹介している書籍やドキュメントまで確認されることを強くおすすめします。

背景：PyCon JPスタッフ活動で作ったDjangoアプリ

無料でアプリがデプロイできる（さらにDBも使える）Herokuには大変お世話になってきました。
そして、いよいよ無料枠の終了が迫っています（11/28に終了）。

Herokuにデプロイしたアプリには、過去のPyCon JPスタッフ活動で実装したDjangoアプリ³もあります。
PyCon JPはトークを公募していて、集まったプロポーザル（「私はこういうトークをしたい」という文書）をレビュアー（スタッフ & ボランティア）がレビューし、採択します⁴。
「レビュアーがプロポーザルをレビューするためのアプリ」を2020、2021で作りました⁵。

扱うデータ

プロポーザル（2020、2021で使ったサービス sessionize⁶ から読み込み）
- レビューアプリでは、プロポーザルは読み取りだけです
レビュー
- レビュアーが書き込みます（レビュアーは何件もレビューを書けるが、1つのレビューは1人のレビュアーだけに対応する）
- プロポーザルには何件レビューがあってもよいが、1つのレビューは1つのプロポーザルだけに対応する
- 1つのプロポーザルをN人以上で目を通すようにレビューを進めます

参考までにReviewモデルの定義⁷です。

class Review(models.Model):
    class ReviewScore(models.IntegerChoices):
        YES = 5, "YES😃"
        MAYBE = 3, "MAYBE😐"
        NO = 1, "NO😫"

    reviewer = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.PROTECT,
        verbose_name="レビュアー",
    )
    proposal = models.ForeignKey(
        Proposal,
        on_delete=models.PROTECT,
        related_name="reviews",
        verbose_name="レビュー対象のプロポーザル",
    )
    score = models.PositiveIntegerField("レビュースコア", choices=ReviewScore.choices)
    comment = models.TextField("レビューコメント（NOの場合は必須）", blank=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

数十人のレビュアーで使い、データ量としてはプロポーザルが100件程度、レビューが500〜600件程度です。

Django REST Frameworkでデータを一覧するエンドポイントを生やす

データのエクスポートの方法はWeb API以外にもあると思いますが、今回はWeb APIを選びました。
これは「DRF（Django REST Framework）を触ってみたかった」という理由によります。
アプリ自体を別の環境に移したいわけではなく、人が読める形でデータをファイルに保存しさえすれば、今回のエクスポートは達成されます。

DRFは2021のアプリ開発で初めて触りましたが、akiyokoさんの『現場で使える Django REST Framework の教科書』（以降、この記事では「DRFの教科書」）にめちゃめちゃ助けていただきました。
日本語で読めてぱっと完全に理解できるリソースとして、大変貴重と思います。

レビュー一覧用のシリアライザ

エクスポートしたいデータ（HerokuのDBにだけ入っているデータ）はレビューだけです（プロポーザルはsessionizeに入っています）。
「誰がどのプロポーザルをこれこれの理由で何点とレビューした」という情報が取り出せれば、今回の目的には十分でしょう。
これをSerializerとして実装しました。

class ReviewSerializer(serializers.ModelSerializer):
    reviewer_name = serializers.ReadOnlyField(source="reviewer.username")
    proposal_id = serializers.ReadOnlyField(source="proposal.sessionize_id")

    class Meta:
        model = Review
        fields = [
            "reviewer_name",
            "proposal_id",
            "score",
            "comment",
            "created_at",
            "updated_at",
        ]

実装する上では、『DRFの教科書』の11.7「関連先のモデルまで含めた情報を取得したい」が役立ちました。
ReadOnlyFieldのsource引数！

レビュー一覧用のビュー（ページネーション付き！）

レビューは一度に全件返すのではなく、ページネーションして返したいです。
『DRFの教科書』では、取得（一覧）APIは4.2、ページネーションは11.5で扱われています。
settings.pyによる全エンドポイントへの設定ではなく、個別のエンドポイントに設定する方法が知りたかったので、教科書の案内に従ってDRFのドキュメントを参照しました。

今回はPageNumberPaginationを使います。

継承したクラスで、クラス変数を使ってページサイズを指定します
generics.ListAPIViewを継承したビューのクラスで、クラス変数pagination_classに1のクラスを指定します
ビューのクラスにはあと2つクラス変数querysetとserializer_classも指定します

class StandardResultsSetPagination(PageNumberPagination):
    page_size = 100


class ReviewListAPIView(generics.ListAPIView):
    queryset = Review.objects.select_related("reviewer", "proposal").order_by(
        "pk"
    )
    serializer_class = ReviewSerializer
    pagination_class = StandardResultsSetPagination

これでページネーションされました！
『DRFの教科書』から離れたので実装しきれるか不安でしたが、DRFに用意されたクラスを使い、クラス変数を設定するだけでページネーションが実現できています！

Adminだけレビューを一覧できる

レビューアプリにはAdminがプロポーザルを登録できるエンドポイントがありました。
認証してトークンを取得し、それを使ってプロポーザルを登録します。
『DRFの教科書』7.4で解説されていて、djoserを使って実現しています。

この実装にならい、レビューの一覧エンドポイントも使えるのはAdminだけとしました。

class ReviewListAPIView(generics.ListAPIView):
    permission_classes = [IsAdminUser]  # 追加
    # 変更はないので省略

ページネーションの仕組み

私にとってDRFはブラックボックス（ラップされすぎていて自分のDjango力でデバッグできるか不安）だったので、ページネーションを最初はAPIViewで実装しようとしました。

If you're using a regular APIView, you'll need to call into the pagination API yourself to ensure you return a paginated response. See the source code for the mixins.ListModelMixin and generics.GenericAPIView classes for an example. （上で紹介したDRFのドキュメントより）

mixins.ListModelMixinの実装がこちら⁸。

class ListModelMixin:
    def list(self, request, *args, **kwargs):
        queryset = self.filter_queryset(self.get_queryset())

        page = self.paginate_queryset(queryset)
        if page is not None:
            serializer = self.get_serializer(page, many=True)
            return self.get_paginated_response(serializer.data)

        serializer = self.get_serializer(queryset, many=True)
        return Response(serializer.data)

filter_querysetはReviewへのクエリセットをベタ書きし、get_serializerは先に定義したReviewSerializerを使えばよさそうです。

これを真似し、上記の点だけ変えてビュークラスのgetメソッドを実装すると、paginate_querysetとget_paginated_responseメソッドがないことでAttributeErrorとなりました。

そこでgenerics.GenericAPIViewの実装を見ます⁹。

class GenericAPIView(views.APIView):
    pagination_class = api_settings.DEFAULT_PAGINATION_CLASS

    @property
    def paginator(self):
        if not hasattr(self, '_paginator'):
            if self.pagination_class is None:
                self._paginator = None
            else:
                self._paginator = self.pagination_class()
        return self._paginator

    def paginate_queryset(self, queryset):
        if self.paginator is None:
            return None
        return self.paginator.paginate_queryset(queryset, self.request, view=self)

    def get_paginated_response(self, data):
        assert self.paginator is not None
        return self.paginator.get_paginated_response(data)

paginatorプロパティでpagination_classがインスタンス化されます。
今回の例では（上で定義した）StandardResultsSetPaginationをインスタンス化します。
ページネーション処理はStandardResultsSetPaginationインスタンスに任せる（paginate_querysetやget_paginated_response）という実装で、これは委譲していますね。

以下が当初の実装（APIViewを継承したビュークラス）です¹⁰。

class ReviewListAPIView(views.APIView):
    permission_classes = [IsAdminUser]
    pagination_class = StandardResultsSetPagination

    @property
    def paginator(self):
        if not hasattr(self, "_paginator"):
            self._paginator = self.pagination_class()
        return self._paginator

    def get(self, request, *args, **kwargs):
        reviews = Review.objects.select_related(
            "reviewer", "proposal"
        ).order_by("pk")
        page = self.paginator.paginate_queryset(reviews, request, view=self)
        if page is not None:
            serializer = ReviewSerializer(page, many=True)
            return self.paginator.get_paginated_response(serializer.data)

        serializer = ReviewSerializer(reviews, many=True)
        return Response(serializer.data)

この実装で動かしたあと、ListAPIViewの実装を見たら¹¹、ListModelMixinとGenericAPIViewから多重継承されていることが分かりました。

class ListAPIView(mixins.ListModelMixin,
                  GenericAPIView):

これを見て「ListAPIViewを継承したら簡潔に書けるな」と腑に落ち、上で紹介した実装となりました。

Web API以外のやり方：エクスポートコマンド追加

python manage.py dump_reviewsのようなコマンドを追加してファイルに掃き出してエクスポートする方法も考えられます。
heroku run bash¹²でアプリケーションに接続し、コマンドを実行させてファイルは作成できました。
ですが、Heroku側にできたファイルをローカルに取る方法が限られます。

Herokuにはgit pushでデプロイできるので、「Heroku側でコミットを作れるのではないか（それをpullしよう）」と考えました。
ところが、heroku run bashしてからgitコマンドを叩くと、「カレントディレクトリはGitリポジトリではない」旨のエラーメッセージが表示されます（ファイルは同期していますが、Gitリポジトリではないようです）。
コミットを作ってpullする案はうまく動きませんでした¹³。

今回はエクスポートしたファイルが数百KBだったので、catでターミナルに書き出し、それをコピペして移しました（2020のアプリの方で実施）。
2通りやってみて、Web APIのやり方がしっくり来ています。

終わりに

Heroku無料枠終了に伴い、自作DjangoアプリにWeb APIの口を追加して、HerokuのDBのデータをエクスポートしたことを共有しました。
generics.ListAPIViewの継承により、いくつかのクラス変数を設定するだけでページネーション付きの一覧APIが実装できます！

DRFのソースコードを初めて読んでみましたが、「意外と読めるぞ」という感覚でした。
Djangoアプリと思えばいいんですね、怖がりすぎてました。

今回取り上げたアプリの実装はこちらにアーカイブしています。

なお、最近のプロポーザルシステムはpretalx¹⁴が主流と思われます（2022のEuroPythonやPyCon JPで使用）。
こちらもDjangoアプリみたいなので、ソース読んでみたいなと思っています。

最後に、Thank you, Heroku Free Plan❤️¹⁵
いままでクソお世話になりました。
ありがとうございました！
風邪引くなよ！！

#pyhack Herokuのアプリ、片付けた！
これまで無料で使わせてくれてありがとうございました。

データをエクスポートする開発、頑張った！ pic.twitter.com/sMxKuEmFUa
— nikkie にっきー 🎤10/1 XP祭り 10/14-15 PyCon JP (@ftnext) 2022年11月26日