約1,2ヶ月ぶりのブログ更新となる。
今回はゴリゴリの技術的な記事となる。 今回はそう「 Slackのような構造のリアルタイムチャットアプリケーション 」を作っていきたいと思う。
なるべく詳しく書き残したいと思っているので、記事は複数部構成にしようと思う。
初回のこの記事では下記のことを綴っていこうと思う。
これら2点について解説していこう。
その前に注意書きを残しておこう
状態管理はReactのHooksを使う
Function Componentを使用する
基本コードはいずれもTypeScriptを使用する
それでは早速見ていこう。
技術選定紹介
まずは大まかな技術選定から綴っていこう。
早速下記にまとめたので見ていこう
大きくまとめると上記の6つとなる。 Next.jsとTailwindCSS、Supabaseについては以前アップした記事で紹介しているのでそちらをチェックしていただこう。
Auth0
Auth0は豊富な認証系のAPIを提供するサービスで、webのみならずネイティブアプリにも対応している。
その特徴はなんといっても随一の認証に関するAPIの豊富さである。
今回作成するアプリではAuth0のmanagementAPIを使用し、通常の認証機能だけでなくユーザー管理機能・Googleの認証まで実装するつもりだ。
基本料金は無料だが、料金が発生すると高額であることも有名だ。
Hasura Cloud
Hasura CloudはGraphqlサーバーを自前で用意することなく実装することができるプラットフォームだ。超充実したAPIが用意されていて、リアルタイム処理やRDB対応したクエリが可能だ。
基本料金無料でHerokuをホストとして始めることができる。しかし今回はSupabaseの提供するPostgresqlで実装する。
Apollo Client
Apollo ClientはJavaScriptの包括的な状態管理のライブラリである。Graphqlと合わせて使うことでローカルデータとリモートデータの両方を管理することができる。
Hasura Cloudとの相性が良いので、併用して使われることが多い。
フロントのホスティングはVercelを使用するため簡単にデプロイできるようにしてある。
続いて
ドメイン設計の詳細
今回作るアプリケーションはLineのようなシンプルなチャットではなくSlackのような、チャットに対してスレッドを建てられるアプリにする。
そのため、ドメイン設計を少し改良する必要がある。下記に今回作るアプリのドメインモデルをリストにしたので確認していただこう。
chatRooms(チャットルーム)
messages(メッセージ)
participants(チャットルームへの参加者)
大まかにこんな感じだろう。Auth0でユーザー管理をしないのであれば別途で「Profiles」のようなモデルを作成するのも良いだろう。
勘の鋭い方ならお気づきだろう
スレッドの中に入るメッセージは??と
詳細は次に綴ろう。ドメインモデルの更に詳細を綴ろう。
chatRooms
id | createrId | name | createdAt | updatedAt |
---|---|---|---|---|
uuid型 | チャットルームの作成者ID | チャットルーム名 | 作成日 | 更新日 |
messages
id | roomId | userId | text | createdAt | subMessages |
---|---|---|---|---|---|
uuid型 | チャットルームのID | 発信者ID | 本文 | 作成日 | json型 |
messagesモデルの中にJSON型のsubMessagesというデータを持たせている。 subMmessagesの中身は下記だ。
subMessages:[
{id: uuid
userId: 発信者ID
text: 本文
createdAt: 作成日
},
{id: uuid
userId: 発信者ID
text: 本文
createdAt: 作成日
},
...
]
それやるくらいだったらsubMessagesモデル作れや!!
ごもっともである。だが今回は私の気まぐれでこんな設計にした。もし実装される際は是非別でモデルを作っていただきたい。
messagesモデルに対してPUTCHでどんどんメッセージを追加していくイメージだ。
uuidはv4を使って実装していく。subMessageなので単純な数値をIDと見立てて実装するのもいい気がするが今回はuuidv4でなるべく永続可能な構成にしている。
participants
id | roomId | userId | createdAt |
---|---|---|---|
uuid型 | チャットルームのD | 参加者ID | 作成日 |
終わりに
とまあこんな感じで手軽に作っていこうと思う。Auth0の設定が面倒な場合は、「認証機能だけAuth0でユーザー管理機能はこっちでモデルを作る」構成がいいと思う。
今回はAuth0の技術検証も兼ねて実装したかったのでこんな感じの構成になる。
今回の記事はこれにて終了だ。
次の記事ではまず今回の中心技術であるsupabaseの設定の詳細を綴っていこう。
supabaseは大変優れたUI/UXだが、日本語のドキュメントが無いため初見だと操作に迷いが生じやすい。なのでなるべく詳細に解説していくつもりだ。
次回の記事のアップロードは1週間後か今週末に出来れば良いかな〜と思っておる!!
ソレではさらばじゃ!!!