Skip to main content

UIの一時的な状態の保存の実現

まとめ​

  • 期間限定のイベントなどで表示する必要がある状態は、期間限定でも永続化層に保存できる機構を持つ
    • 利用後は永続化層を破棄するなどする
  • 長期的に運用する必要がある場合は永続下層に保存する

あまり良くない方法

  • 要件としてクライアントのストレージに状態を保存し、揮発を容認する

原因​

  • 一時的にユーザーに表示したいUIの状態管理の方法が決まっていない
    • 例）新機能を案内するUIの開閉状態
  • LocalStorage
    • domainのスコープ次第で他のサービスへの影響がある
    • URLが変更になった場合、引き継ぎが難しくなる
    • マイグレーション設計を考える必要がある
    • ブラウザを変えると揮発する
  • Cookie
    • domainのスコープ次第で他のサービスへの影響がある
    • マイグレーション設計を考える必要がある
    • ログアウトしたり、GDPRによるCookieの利用を拒否すると揮発する
  • Query Params
    • ロジックを実装しているスコープのみに影響
    • 表示ロジックとしてのみ機能する
      • クエリパラメーターを指定するかどうかの状態は別の場所で管理する必要がある

対策​

  • 期間限定の永続化層を作成し保存する。利用しなくなったら破棄する。
    • UIドメイン用の永続下層として管理運用する
  • UIの状態再現としてクエリパラメーターで再現できる状態にする。

対策の動機​

永続化層を作成する理由

「一時的に」がつくようなUIは、サービスの本質的な部分ではなくそれを強調したりサポートするために利用されることが多い。 この「一時的に」という表現に引っ張られて状態保存する先がクライアント側になることが多い。 簡単にこの選択をすることは可能だが、これによって引き起こされる問題に対する解決方法まで想像することをする人は少ないだろう。 「一時的なUI」の使用率の集計、使用状態の強制的な変更、状態の移植をしたいとなった場合、クライアント側に状態があるとあらゆるケースを考える必要がある。 一番問題なのは「クライアントの状態は信頼できない」ということである。クライアントの状態はクライアントで操作可能であるので、マイグレーションという手段ではなく常に状態の上書きという手段しか取れない。 また、集計をしようとしてもクライアントに状態があるので正確に集計することができない。 移植に至っては、移植のたびにそのコストを払い続けることになる。

これらの問題を考えるよりも、UIに対する専用の破棄できる永続層、データベースを構築することが持続性を考えた時に導き出される結論だ。

クエリパラメーターでUIの状態再現させる理由

導入方法​

  • UIに関してはクライアントの責務なので、その範囲でデータベースを構築できることが望ましい。
  • 大量のリクエストを受ける可能性を考慮すると、redisなどで初段は受け、その後はRDBに保存するかもしくはredisの状態を永続化する方法が考えられる
    • もっと良い方法があれば募集。
  • 破棄できるデータ構造をすること
    • リレーションを作らないなど。

継続方法（運用）​

  • データ構造、カラム設計、データベースの破棄までを設計として考えること。

対策の問題点​

  • 永続化層を作成する場合、トラフィック流量に耐えられる設計が求められる

展望​

  • UI向けのハイパフォーマンスデータベース設計

参考資料​