mizchi「オレら知ってますよ。Railsの倒し方」
このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。
ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。
全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。
内容としてはRailsアプリケーションの問題点→置き換え先がNode.js(TypeScript)である理由→Prismaは代替となりえるのか？ という議論をしている。この議論の詳細に踏み込もうとしたら、日記が終わらなくなってしまったので、それは各自場外乱闘してもらうとして。ここではそれぞれの話題についての私の理解を書いていく。
ライブでは楽天市場の商品ページを例に、ユーザーの要求によって複雑化したフロントエンドの実装の話をしている。クライアントサイド N+1 問題、CQRSをヒントに参照系APIとコマンド系APIを分離する話をしている。そこからテンプレートへの値渡しで型定義を駆使したい話とRubyでのコーディングの現状を語る。
Node.jsのはなしにうつるとSSRとRSCでサーバーサイド側でデータ取得を行うことで、APIクライアント→サーバーの問い合わせ方式によるオーバーヘッドを減らすことができる。これがCQRS方式でやりたかった解決策と一致するとmizchiさんは説明する。
そこからNext.jsはルーティングまでしかやってくれなくDB層を持たないのでPrismaを持ち込んで使う。PrismaはTypeScriptの型推論を生かした後発のORMで、クエリの自動最適化まで備えたコアのエンジンがRustで実装されている。開発者が定義した独自スキーマ設定からクライアントコードを生成する仕組みを備えており、複雑な部分が隠匿されていてRailsのActiveRecordのように学習コストが低い。という面で技術優位性がある。
しかしPrismaの運用面では実績が少ないので、まずそこが課題となる。利用者が増えないことにはエッジケースが網羅されないので卵と鶏の問題がある。実際、まだmizchiさんはPrismaをプロダクション環境では使っていない（私も運用したことない）。動画ではレポジトリ内のIssueを探索していき、そこからPrismaが特殊なクエリを発行する例として「関連テーブルのJOINを高速化するためにPostgreSQLではjsonb_agg関数を発行する」という例を紹介した。
またPrismaのVCからの資金調達が好材料と触れられている。長期的にPrisamを利用するには彼らのSaaSビジネスが軌道に乗せる必要があり。Prisma Cloudのプラットフォームに課金して使うことはあまり想像できない私としては先行きは不安が残る。ただMongoDBのごとく大成功してる可能性もある。どうなるんだろう。
---
彼らの会話には「－－という気持ち」「世界観」「書き心地」という言葉が頻出する。これは半ばジャーゴン化しているところもあるが、その言葉が表現しているのは「その技術やアーキテクチャの開発者体験を自分たちの思想や好みに照らし合わせて、どういうスタンスで評価しているのか」ということを言いたいのだと思う。気持ち→共感→気持ち→共感のリレーをつなぎ、総体を形成してゆく。だから共感できないコミュニティ間では別の結論に達することもある（AngularやBlazorあたりを思い浮かべてみて）。
登場する要素技術はDeclarativeなものが多いのに、アーキテクチャリングの過程はアサーションをかけつつ動的に評価実行していっているかんじがギャップがあって面白い。フロントエンドを作るひとたちが柔軟性を重んじていることが伺える。
その意味でRailsの掲げる「控えめなJavaScript」という標語によって実現されている既存のアプリケーションが、フロントエンドエンジニアの期待する共感水準にないのだなと思う。私もHEYのUIはかなり使いづらさを感じているが、Basecamp2とか3の時代はあまり気にしたことがなかったので我々側の感覚も変わっているのだろう。
元をたどるとやはりTypeScriptが覇権を握ったことで、状況が大きく変わっているなと思う。フロントエンドの開発者がだんだん型を記述するという習慣をつけていったこと。CoffeeScriptがデフォルトで推奨されRubyのような書き味を得られることが支持を集めていた一昔前のRailsからは予想できなかった流れだ。
AI(GitHub Copilot)によるコード補完の話題からの流れで、型定義から推論して実装を生成する話題が出ていた。これはRailsのscaffoldやmigrationファイルの生成による自動化と似ているというのは鋭い指摘だと思った。開発者はアプリケーションの設計に関心を向け定型的な実装パターンは自動化するという点は目的が同じである。何でも型定義で解決されがちというのが今のトレンドなのだろう。