筑波大学生向け時間割アプリ。有志で集まりチームで開発・運用されています。 自分はバックエンドの開発とAndroidの開発を担当しています。

Twin:teのバージョン遷移

Twin:teは過去に何度か大型アップデートを行っており、そのたびに大きく構成が変わっています。

• v1：初期バージョンで自分は開発に参加していませんでした
• v2：フロントにVue(2.x)・バックエンドにnode.js/express
• v3（現在）：フロントにVue(3.x)・バックエンドにnode.js/express/gRPCマイクロサービス

現在のバックエンド

v3では機能毎に細かくサービスを分割して協調して動作するマイクロサービスとなっています。 基本的にフロントエンドが得意なメンバーにも開発ができるように言語はTypescriptを使用していますが、一部はgoで動いています。 サービス間はgRPCで通信しており、フロントエンドとはapi-gatewayというサービスを介してhttpsで通信しています。 全てのサービスはlinodeのk8s上で動作しており、CI/CDはGitHubActionで整備されています。

マイクロサービスを選んだ理由

v2までは一つのバックエンドサービスがすべての機能を実装する一般的なものでした。 しかしv3では機能毎に細かくサービスを分割して協調して動作するマイクロサービスとなっています。 マイクロサービスに切り替えた理由として以下が挙げられます。

新サービス実装の心理的負担を減らす

Twin:teは筑波大学生が便利に使えるサービスを開発したいというメンバーが集っています。 よって新しいサービスや機能は思いついたらすぐ実装して公開できる仕組みが必要だと考えました。 仮に全バックエンドが一つのサービスで成り立っていた場合、まず全体のコードの把握が必要になります。また、得意としない言語やフレームワークの場合学習コストがかかります。 こういった新機能を開発したいという気持ちを削いでしまう要因をできるだけ減らすために、また各々が挑戦したいことを既存のコードで制限したくないという思いもありました。マイクロサービスであれば使いたい言語でgRPCが利用できればそれ以外の制約はありません。

コード把握のコスト削減

v1から始まったTwin:teのサービスは大きくなり、時間割以外の機能も多く実装するようになりました。例えばTwin:teはユーザーから寄付金を募っており決済の実装も行っています。 このようにメイン機能ではない性質の異なる機能を一つのバックエンドとして開発する必要がで出てきました。これにより特に新メンバーがコードを把握することが難しくなりました。 例えば特定の機能を修正したい場合に全体のコードをある程度把握する必要がありますが、サービスレベルで完全に分割されていれば対象サービスを把握するだけで修正ができます。

コードの流動性

各々が異なる言語・異なる設計でサービスを開発すると将来的に技術的な負債になりえます。しかし、負債になったら新しく書き直すくらいの流動性があるべきだと思っています。 Twin:teは学生によって構成されるためメンバーに流動性もあります。そのため一つのコードベースを長期的に保持することは難しいのです。 マイクロサービスなら小さい単位から新しく書き直すことが可能になります。

Androidアプリ

Twin:teはチームの規模の観点から、フロントエンドはweb技術で統一しています。 そのためiOS/AndroidアプリのメインUIはWebViewになっています。 ただし、通知機能やウィジェット機能はネイティブで実装する必要があります。

Twin:te AndroidアプリはKotlinで書かれています。 Android12でウィジェット周りのAPIがアップデートされたため利用できないか模索している段階です。

chrome拡張

大学が使用している学習支援システムManabaで提供される授業の課題情報をGoogleCalendarに転送する拡張機能です。UIはReactで書かれています。