generated at
複雑GUIにおけるRepositoryパターンの勘所
#Server_State #複雑GUI #宣言的UIの設計レシピ

前提: ここでのRepositoryについて
Web APIや外部ストレージへのデータアクセスに関する責務を持つ
内部的にはREST、GraphQL、LocalStorageなどのインタフェースで実装される
---
経験上、GUIにおいて技術的な知識を隠蔽するという目的でレイヤードアーキテクチャにしてもペイすることは少ない
SPAでのレイヤードアーキテクチャの考察と不確実性へのマインドセット
最近はスキーマ駆動開発がメジャーなのでAPIクライアントの自動生成もできる
→Repository自体が自動生成されるものになっている
GUIにおけるRepositoryは「DBの抽象化」ではなく、「リソースの抽象化」である
CRUD操作の発想にとらわれるとスケールしない
アプリケーションロジックの命名にCRUDを持ち込まない
ブログのアプリを作るとして
「記事の中身をとってくるクエリ」はユースケースやパフォーマンスチューニングなどの要件から数パターンあってもおかしくない。
同一のAPIを使った情報の表示であってもページや表示箇所によって微妙に表示の仕方が異なる場合がある
データ構造やWeb APIがきちんと設計されてればクライアントサイドでRepositoryが必要になることはほぼない
Resource-based APIとUsecase-based APIの勘所
特に最近はコンポーネントの中でフェッチするのが主流
Render As You Fetchパターン
そこまでして守るべきビジネスロジックがフロントにはあまりない
シンプルにストア層とコンポーネント層をhooksでわけるぐらいでも十分なケースがある
レイヤを重ねても開発効率が落ちるだけな時も...
多くのプロジェクトはリファクタリング耐性を必要とするくらいの大きな規模になる前に開発が終わってしまう
関心の分離はドメインとプレゼンテーションから考える(PDS)
宣言的UIのデータ構造をシンプルにしたいなら、ドメインモデルやPresentation Modelの構築を検討するほうが素直
フロントエンド(SPA)でオニオンアーキテクチャっぽくデータフェッチとドメインを分離する例みたいに単方向データフロー(unidirectional data flow)を作って依存管理する

koushisaの結論→宣言的UIのデータアーキテクチャはコンポーネントを中心に考える