概要

個人開発（元記事URL 貼る）における調べ物のメモです。
自分の見解や苦労などはIMOとしてトグルに格納しています。

abeuzZ

DBのPKにUUIDv7を採用する

motivation

YoutubeやInstagramライクなコンテンツ配信するサイトなのでそれらと同じくコンテンツをauto_incrementではないものにしたかった。
上記サービスはUUIDほど長くない独自のID生成を使っていると思われるが、今後業務で携わるサービスでもUUIDv7が採用される可能性はあるので先に触ってメリデメを体感したい。
UUIDv7がRuby3.2あたりから組み込まれており、気軽に利用できる。
UUIDv4はMysqlのパフォーマンスが低下するがUUIDv7であれば防げる（はず）
- postgresが対応がされてそうだが今回の開発はNext.jsの学習で手一杯になると思われるので使い慣れているMysqlで行きたかった。

abeuzZ

Railsの実装方法

https://ptrchm.com/posts/rails-uuid-v7/

基本的な形としてはmodelでbefore_createする際にidをUUIDv7で上書きすれば良い。

IMO

before_createはRailsのコールバックなので、コールバック無視する記述とか書いたらDBのデフォルト（今回であればMYSQL8.0のUUIDv4）採番される模様。
コールバックモリモリのサービスでコールバック無視みたいな記述に会ったことはあるので気を付ける。
今回は個人開発なので大丈夫だとは思うが。

DB設定方法

abeuzZ

knowledge

MySQLにおけるパフォーマンスの低下についての解説記事

IMO

正直そこまで理解できていないが、書き込む際もメモリ上ででソートするから完全ランダムなUUIDv4はパフォーマンスが落ちるという認識。
これに対しUUIDv7は頭がタイムスタンプなのでソート可能で書き込み時のパフォーマンス低下を防げる、という認識。

間違ってたらご教授いただけると助かります！

MySQL に UUID のデータを 16 byte で保存する

開発速度優先の為、今回は不採用だが参考に。

IMO

どこかの海外のフォーラムでもUUIDを利用する際のTipsとしてデータを16byteにしてDBパフォーマンスを上げる方法を提案していたのでありだと思われる。
一方でRailsのORMが対応しているのかどうなのかなど調べるのが大変だったので一旦不採用。
パフォーマンス問題の壁にあたった時に思い出せるようにメモ。

abeuzZ

ActionDispatch::HostAuthorizationの対応

開発時にローカルでフロントエンド側からAPIをcallするときに発生。
現状フロントエンドからdockerサービス名で接続しており、デフォルト設定のlocalhostではないのでエラーになった模様。

development.rb

config.hosts << "docker service name"

rails6で追加された。（今までのプロジェクト5.xだったから知らなかった、、、）

本番は本番で設定が必要なので忘れないこと。

development以外の環境では、Rails.application.config.hostsは空になり、Hostヘッダーチェックは行われません。production環境でヘッダー攻撃から保護したい場合は、以下のように手動でホストを許可する必要があります。

abeuzZ

Rails Credentialが環境毎に設定できる

bin/rails credentials:edit -e [env]
bin/rails credentials:show -e [env]

IMO

整理しやすさもあるし、チーム開発で本番のCredentialを渡さなくて済むのでセキュリティ的にも良さそう。