RevCommのフロントエンドエンジニア兼イベントモデレーターの小山です！
RevCommは7/5(水)に「世界に認められたAIスタートアップが、Djangoを使って感じる良さとは？ 」というイベントを開催しました。今回はそのイベントで公開したスライドや動画を公開しながら、イベント中に時間の都合で答えられなかった質問にも答えていきます。
今回のイベントは私が企画からモデレーターまで務めさせていただきました。登壇した小門さんと近藤さんは、RevCommの中でも技術についてのプレゼンやディスカッションが得意な2人です。期待以上に良いプレゼンをしてくれて、参加者の方々にも深い質問をいただくことができた会になりました。
フレームワークの使い方はドキュメントでも学ぶことができますが、状況に応じた選定や判断は使い手次第。今回はその点にも触れていますので、ぜひともご閲覧いただけるとありがたいです！
Q and Aへの回答
イベントではたくさんの質問をいただくことができました。時間の関係上、全てに答えることができなかったので、この場で共有をさせていただきます。
—
Q: Djangoのバージョンアップ計画とかどうされていますか？ 直近だとDjango4.2でMySQL5.7とPostgreSQL11のサポートが切れるので、そのあたりでどのように適用されたか、またはどのように適用しようとしてるなどあれば教えてください。
A: 社内ではマイクロサービス単位にアプリケーションが分かれていて、プロジェクトとして独立しています。 スケジュールや方式など含めた計画はプロジェクト毎に策定しています。 Django 3.2 LTS は 2024年4月にはメインストリームから外れるため、なるべくそれまでに更新することを社内の共通認識としています。
またDBは PostgreSQL バージョン12以上を使用してるため、その影響はありませんでした。 DBやRedisなど、周辺のサービスもこまめにバージョンアップすることも重要だと思います。
Q: 40個もアプリが分かれてると大変そうですが、どういう基準でアプリを分割してるのでしょうか。
A: 機能の責務や依存関係を考慮します。
例えばユーザー認証の機能とログイン後に利用する機能とでDjangoアプリケーションは分割します。 責務ごとにアプリケーションを分割することで改修範囲を小さくできたり、コードベース全体の見通しを高く保つことができます。
Q: 一部でDjango4.2を利用されているとのことですが、アップデートしてよかったところや、注意が必要だったところはありますか？
A: 前述の通り、Django 3.2 LTS はいずれメインストリームから外れて開発も停止するため、最新の LTS に追従することはほぼ必須と考えて対応しています。 また、細かい機能改善も多数あり便利になっていっています。
アップデート時の注意点として、初めにリリースノートから大きな変更や影響が無いか確認しました。 Django 4.2 release notes
他の質問にもある、MySQL5.7/PostgreSQL 11 のサポート切れについても書かれています。 既に社内でアップデート済みの対応については別のブログ記事でも説明しています。
Q: 2019年の途中からDjangoに切り替えたということですが、移行時にはどのように実施したのでしょうか？全部書き換えるとすると実装もテストすごく大変そうだなと思い気になりました。
A: 当時Djangoへの移行を担当した方にヒアリングしたところ、下記のような返答をいただきました。
Node.jsからDjangoへ切り替えた当時は機能・コードともに少なかったので、テストも実装もあまり時間かからず移行できました。振り返ると、早い段階で移行する判断ができたので良かったと思います。
また、当時は品質よりスピードが求められていたこともあり、ユニットテストはまだなく、手作業によるシステムテストだけ実施し、品質を担保していました。このためテストケースはそのまま流用できたため、移行のネックになることはありませんでした（現在はユニットテスト、システムテスト、QAプロセスまで整備しています）。
Q: Djangoはディレクトリ構成を統一しやすいというお話があったかと思いますが、それはstartappコマンドで作られるDjangoアプリケーションの構成はほぼそのままで使われることが多いから似たような構成になりやすい、という意味でしょうか？
A: 必ずしもそのまま使う必要は無いと思います。
例えば、django-admin startapp コマンドで作成されるファイルに models.py や views.py などがあります。 我々のプロジェクトでは models/xxx.py, views/xxx.py など、ディレクトリ配下にモジュールを分割して配置しています。 ファイルか (models.py) ディレクトリか (models/) という違いはありますが、命名と役割をDjangoのプロジェクト雛形に準拠しています。
Q: RevCommの開発もTDDで行われているのでしょうか
A: TDDかどうかは個人に任されております。ただ機能追加したい際や既存の処理を変更した際には合わせてユニットテストを書くという共通認識はあります。
Q: フロントがTS、バックエンドがDjangoという構成なら、最近だとDjangoのかわりにFastAPIを使う選択肢もあるかと思いますが、仮に新規で開発することになった際に、どちらを採用したいと思っていますか？ または全く別の選択肢を考えているなら、それについて教えていただけると幸いです。
A: 個人的には TypeScript のライブラリも選択肢に挙げたいところですが、技術者の確保を考えると Python のライブラリになるかと思います。
また、新規サービスの種類にもよりますが FastAPI も選択肢に上がると思います。実際に直近立ち上がったプロジェクトではマイクロサービスとして切り出す API を FastAPI で作ってます。また、3年ほど前に BFF に FastAPI を採用した際には、「asyncio対応、型ヒントへの対応、OpenAPIドキュメントの自動生成、Django ほど多機能ではなくていい」などが決め手になったようです。
Q: 多数のDjangoAppを含むコードベースを運用する上で、DjangoApp同士の依存関係に関して規約や工夫されていることはありますか？
A: 規約は特に入れていないです。 複数の App で明らかに何度も利用するものは common ディレクトリに処理を寄せていたり、App間に依存が発生する場合(全文検索のAppと検索対象のAppなど)はSSOTを心がけて依存が複雑にならないようにしています。
全体的に特定の技術に固執しすぎずに、実現したいことに合わせて柔軟に技術選定を行っているという回答でした。また個人の自由もある程度認めながらも、チーム全体のことを考えるという感じですね。
終わりに
RevCommが急成長する中で、開発者は日々課題に向き合っています。その過程で得た知見やそのときの判断は社内だけでなく、きっと社外の誰かの参考にもなるはずです。これからもイベントを開催してより良い会にしていきたいと考えています。ぜひとも楽しみにしてください！
