ADR（Architecture Decision Records）用のIssue

[da-yoshi-k]

これは何か

ADRを記録するためのissue。

• スタディサプリでの例
• TISでの例

記載例

提案

• タイトル
  • 「ADR-{3桁の連番}:xxxに関する提案」等、簡潔に書く
• 本文
  • 背景、理由
  • 案(設計思想、実現方法)

スレッドの後のコメントとしてに以下を記載

• 受理or廃止
• 上記決定に至った理由

廃止として決めた場合には再検討を実施する。

[da-yoshi-k]

ADR-001:バックエンドの技術スタックに関する提案

背景

今回のアプリを作成するにあたり、ワークを行う箇所については動的かつ頻繁に画面に描画される内容を変更することを想定している。 個人開発の割に中規模程度の開発ボリュームになりそうであるため、極力学習コストの低い技術スタックを採用するものとする。

案

フロントエンドとバックエンドについて

• コア機能が動的なページになるため、SPAフレームワークのフロントエンドとバックエンドは分離させて個別のアプリケーションとする。

フレームワークについて

• バックエンドは開発エンジニアのスキル的に学習コストが低く、実装工数としても優位性のあるRailsを選択する。

Railsのバージョンについて

• APIモードでRailsを利用し、フロントとリポジトリ自体を分けるため、7系の破壊的な変更の影響を受けにくいと考えているため、バージョンは7を選択する。

DBについて

• HerokuやFry.ioなどのPaaSにおいて無料枠の存在するPostgreSQLを選択する。（使い勝手やメンテナンスコスト見合いでMySQLへの移行も考える）

テストフレームワーク

• 習熟度および利用割合が高く一般的に利用されているRSpecを利用する

その他

• リアルタイムなコミュニケーションを行うため、Action Cableを積極的に利用する。外部のサービス(Socket.ioやTwilio)を利用することも考えたが、チームなどの権限管理などが絡むことを考え、Rails上で管理することを想定する。

[da-yoshi-k]

以下提案内容で受理、決定します。

• ADR-001:バックエンドの技術スタックに関する提案

[da-yoshi-k]

ADR-002:フロントエンドの技術スタックに関する提案

背景

• ADR-001で記載したように、ワークの部分では動的にコンテンツの表示やファシリテーター、発表者の切り替えを行うためSPAでクライアントに表示を行いたい。

利用ライブラリ・フレームワークについて

• 開発者の習熟度の関係でVue.jsを利用する。
• また、実装工数削減のため、状態管理やルーティング機能をデフォルトで利用可能なNuxt.jsを利用したアプリケーション構築を行う。
• こちらも習熟度・スケジュールの関係からTypeScriptではなくJavaScriptでの構築とする。（可能であれば後々リプレイスを行う）

Vue.js・Nuxt.jsのバージョンについて

• Nuxt.js3の正式リリースが行われたことから、基本的にはViteによるビルド速度向上や機能拡充が行われた3系を利用するものとする。
• ただし、習熟度の問題からOptions APIでの記載を基本としつつ、利用方法を理解してからCompositon APIへの移行を進めていく。

CSSフレームワークについて

• Vuetify3系は安定した利用が見込めるか不明であるため、採用を見送る
• 上記を踏まえ、今回はそれであっても開発工数の短縮を見込めるdaisyUIによるコンポーネント作成とする。

テストフレームワークについて

• フロントエンドにおけるテストは初期段階では土地勘がないため、ドキュメントや1次・2次情報の多いJestを採用し、単体・結合テストを書く。
• E2Eテストについては未知であるため、Cypressを第一候補としつつ習熟する予定。

linter, formatterの適用について

• ほぼスタンダードとなっているESLint、Prettierを適用する。

[da-yoshi-k]

以下提案内容で受理、決定します。

• ADR-002:フロントエンドの技術スタックに関する提案

[da-yoshi-k]

ADR-003:PaaSの利用に関する提案

フロントエンドに関して

• 個人かつ非営利での利用であるため、初期開発等はVercelを利用する。
• 制限を迎えたり、多くのアクセスが見込まれる場合にはAWSへの移行を行う。

バックエンドに関して

• 開発に関してはFly.ioへのデプロイを行う。
• こちらもアクセス数やDB等の制限が厳しい場合などにAWSへの移行を検討する。

[da-yoshi-k]

以下提案内容で受理、決定します。

• ADR-003:PaaSの利用に関する提案

[da-yoshi-k]

ADR-004:利用するPaaSの変更に関する提案

背景

デプロイの容易性を鑑みてVercelを利用していたが、サーバレスでデプロイを行う場合には最大実行時間の関係でWebSocketの接続を維持できないことが12/31の時点で判明した。 Do Vercel Serverless Functions support WebSocket connections?

フロントエンドのデプロイ先の一時変更について

上記事象のため、デプロイ先をバックエンドと合わせる形にして、Nuxtのデプロイも行えるFly.ioに変更を行う。 12/31にデプロイ自体は完了しておりWebSocketの接続が行えることは確認済み。

デプロイ先の選定について

Fly.ioのマシンを2台利用することになるため、一時的にはFly.ioをデプロイ先とする。並行して他のデプロイ先を検討と調査を行う。

[da-yoshi-k]

以下提案内容で受理、決定します。 最終的なデプロイ先の選定が完了次第、再度ADRを記載するものとします。

ADR-004:利用するPaaSの変更に関する提案

[da-yoshi-k]

ADR-005:フロントエンドの技術スタックの修正関する提案

TypeScriptの利用について

背景

ADR-002で記載した当時はTypeScriptの習熟が浅かったため採用を見送ろうとしていた。
その後Nuxt3を開発するにあたって、RC→Stableに変更となった際に記述が変更となっているパターンに遭遇し、型の情報を信じた結果動作したため、TypeScriptを利用した方が安全だと判断。

案

• 基本的にはTypeScriptを利用して開発を行う

Composition APIの利用について

経緯

Nuxt3のドキュメントやVue3のドキュメントを参照したときに、Composition APIの記載であることが多くあったため、こちらも判断時に悩まないようにComposition APIに統一するものとする。

案

• CompositionAPIの記法に統一する。

[da-yoshi-k]

以下提案内容で受理、決定します。

• ADR-005:フロントエンドの技術スタックの修正関する提案