FlutterでのCacheのためのアーキテクチャを薄くしたいメモ

アプリを作ってるとクライアント側でUseCaesやRepositoryを作るアーキテクチャを採用することが多かったが、ちょっと億劫だなと思うことがたまにある

サービスの特性を踏まえてクライアント側だけではなく、全体のアーキテクチャを考えられるのがベスト

GraphQL or RESTful

あくまでもサービス内容によると思うが、直近自分が関わるサービスに於いてはGraphQL のような表現力がある方がクライアント側としては作りやすいと思うことが多いので最近はGraphQL 推し

メモ

GraphQLのクライアントとしてApollo Clientを使っていたらのcacheの機構がすごいなと思ったこと
Apollo Client以外にどんなのあるかちょっと調べる
GraphQL導入でかんがえたほうがいいこと https://engineering.mercari.com/blog/entry/20220303-concerns-with-using-graphql/
Apollo Clientしか使ったことがなかったので、他のClientだったりむしろどういう理由で何を選択すべきか？
- https://user-first.ikyu.co.jp/entry/2022/07/01/121325
FlutterってApollo Client無いけどGraphQLでやるとなったら何を使うのがいいのか？
GraphQLじゃなくてRESTfulの場合でもクライアントをなるべく薄い構造にするために選択肢はないか？
- そもそもRepositoryとかをAPIキャッシュとしてしか使ってなかったみたいなことあるかも？
- それだったらわざわざRepositoryとかいらないよな…
- StateManagementをもっと楽にしたい…
- ReactだとSWRやTanStackQuery(ReactQuery)みたいな物がある

Flutterだとどうするか？

riverpodを使用する