2日目は別のイベント (Go Conference 2025) に被ってしまったので、1日目だけの参加でした。1年は365〜366日しかないのでそういうこともありますね。
聞いたトークのメモはCosenseにだいたいあります。特におもしろいと思ったトークについて個別に取り上げてみます。
- ハッピーパスに集中しよう、最適なコードの配置が分かるまでは「最もシンプルで、うまくいく」場所に置こう、ということが実践されている
- 最初から作り込みすぎずに全容が分かってきてからコードを動かす、というスタイルは自分も好き
- 一方で、忙しさが高まりすぎると全容が分かってもコードを動かす暇を作りづらい、みたいな構造になりやすい (なったことがある) のも気になる
- フットワーク軽く動くのと、チーム全体の開発をブロックしないことをうまく両立できるようにありたいね
- 普段はReactやNext.jsを使いまくっていて、Hotwireはまったく触っていない、という立場の上で……
- 高度なUIを作るときの本質的な難しさにうまく向き合えるアーキテクチャを実践しよう、という話だと理解した
- 状態管理をうまくやってスパゲティ化しないようにする、とか
- ReactだろうがHotwireだろうが変わらなさそう
- Railsには、リクエストのHTTPメソッドに応じて参照するDBをprimary/repliceで切り替える機能がある
- read/write splitting
- 一方で、GraphQL APIだと標準のread/write splitting機能が使えない
- 参照系・更新系いずれもHTTP POSTだから
- graphql-rubyのフックポイントで参照先DBを切り替える機能を実装した
- query (HTTP GET相当) で更新しているクエリはDB切り替えの対象外とできるようにした
- GraphQL APIをGETで叩けるようにして、クエリ文字列はpersisted queryでハッシュだけ送れるようにすると、標準機能に乗っかれるかも? とか登壇後に議論させていただけてよかった
- persisted query用のクライアント・サーバーの実装も要るし、トレードオフがありそう
この件改めて考え直してみたが、フィールド名が変わったり削除されたり追加されたりした時に、HTTPキャッシュなどが絡むと、そのフィールドある(ない)ことにしたFEのリリースとキャッシュサイクルも関係するのも面倒だな〜という問題もありそう https://t.co/eItNhYcJmL
— Koya Masuda (@koxya) 2025年9月26日
- Server-Sent Eventsのことはある程度知ってたけど、けっこう知らない仕様があった
- Last-Event-IDとか
- async gemの採用事例いろいろ見れておもしろかった
- 長時間にわたる常時接続だとデプロイ時に接続が切れたときのハンドリングとかが要る? というのがちょっとずつ気になってきた
- SSEのLast-Event-IDヘッダはこのあたりを意識した仕様なのかな
来年はもう日程が分かっているし、なんとかして両日参加したいな〜〜。
