バックエンドエンジニアから見た、フロントエンドとのステート2重管理問題 by kono

本LTではバックエンドエンジニアから見たフロントエンドとの分割における「つらみ」を「状態管理」の視点から明らかにし、軽減するためのアイディアを紹介します。

• 状態の2重管理
• なぜ2重管理になってしまうか
• 対策案

バックエンドのAPIとして、Java/Go/Ruby/PHPなどの処理を呼び、フロントエンドはUI/UXに注力するというアーキテクチャは現在よく取られている手法です。
明確な境界があることで責務は分断され、業務ロジックはバックエンドに秘匿され、多くのメリットが享受できます。

一方でステート（状態）はどうでしょうか？
ユーザーの利便性やわかりやすさのためにフロントエンド側で一時的な状態を保持し、画面を組み換え、POSTします。
フロントエンド側で更新された状態を改めてバックエンド側でチェックし、永続化することが多く、状態の保持に関しては複雑性が増してしまいます。