技術系の境界線 | La Verda Luno

これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話（触ってみたレベルでなく実運用等を経たもの）についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ

[programmablekinoko]

サーバーは王様って言葉の倒錯みたいで面白いな、実際そうなんだけど

[honma200]

“サーバーは王様" ビジネスロジックじゃねぇの？(当方SIer)

[turanukimaru]

鯖側はきれいなつもりでも、フロント側は「同時に表示するアレとかコレも欲しい」になるんだよな…だがRead系をフロントが作るのはデータが複雑だと辛い。時間軸とか cancel undo redo 考慮したテーブルはエライことになる

[magnoliak]

可視化されて、論点が分かりやすい！

[efcl]

CQRSによるRead系の分離によるシンプル化。 Readの処理を肥大化させないものとしてのGraphQL

[n_231]

“CQRS” CORSと空目するからクソ命名

[otihateten3510]

Web大変だな（byモバイル）

[j5ik2o]

"もし CQRS の実現が簡単になればより CQRS を使える場面は増えることになりますが、これと同時に Read 系の関心の悩みも一緒に解決しやすそうに思えます。"

[nunohito]

“現実の API はサーバーサイドのモデルの理想から離れていってしまいがちです。まさに「神 API」です。そうした課題への一つの提案が GraphQL だと理解しています。”