Next.jsとは別れRuby on Railsにまた惹かれてしまった

GraphQL以外でWebアプリ作ると，アドホックで非公式な，バグだらけの遅いGraphQLの半分みたいになっちゃうんだよ．そう，ブックアプリにもGraphQLは絶対必要．別FWはNextみたいにバックエンドとフロントエンドを一緒に書けるなら不要．複雑なビルド？npm runでOK．RoRモノリスは問題多いよ．Nextが最初ならRoRを同じように批判してたはず．

＞ ”連携開発なら柔軟性は不要”？全く違うよ．固定APIで問題ないアプリは多いしGraphQLは存在しない問題を解決して新しい問題を生む．柔軟性がバックエンドを複雑にしDoS対策やパフォーマンス理解を難しくしバグを増やすんだ．連携開発してるなら柔軟性はいらない．組織の問題だ．ブックアプリには不要だよ．

＞ ”連携開発なら柔軟性は不要”？いや，柔軟性あっても問題ないでしょ．フロントエンドが変なクエリ使わなきゃOK．
＞ ”必要なAPIを提供すれば良い”？うん，でも実際どうやるの？N+1問題回避とか似たデータ必要なクエリ多いからGraphQLみたいに汎用的な方法が必要だよ．手書きエンドポイントは独自のライブラリ書くようなもん．

＞ ”フロントエンドが変なクエリ使わなきゃOK”？悪意のある人はカスタムツールで大量に遅いクエリを実行できるんだよ．フロントエンドがどう使うかに制限されないんだからね．

＞ ”悪意のある人が遅いクエリを大量に”？システムの設定によるね．僕は本番インスタンスではコンパイル済みクエリだけ許可してるから，攻撃者は作者が書いてない違うクエリを実行する方法はないんだよ．

デコンパイラとかリバースエンジニアリングが何かも分かってる？敵対者はシステム設計通りに使うのに制限されないよ．GraphQLクエリはWiresharkとか他のスニファーから簡単に引き出せる．ブラウザに渡してるなら，どんなに決意が固い敵対者でも手に入れられる，絶対に．LLMがデータ得るためにGraphQLエンドポイントスニッフィングしてても驚かないよ．

デコンパイラやリバースエンジニアリングが何かも分かってるかだって？GraphQL（または昔ながらのRDBMS）のコンパイル済みクエリがどう動くか分かってる？ワイヤーで送られるのはクエリIDだけだよ．作者が書いてないクエリをサーバーに実行させる物理的な方法はないんだ．

それじゃあGraphQLの利点を全部投げ捨てたってことじゃん．フロントエンドが必要なものを決定できるようにする代わりに，ページに必要なものを返す新しいバックエンドエンドポイントを書く必要がある．これは/rpc/bffe/get-profile-pageみたいな呼び出しと何も変わらない．そっちの方が書くのもずっとシンプルでツールもずっと優れてるのに．

ううん、うちのbackendはfrontendが使うクエリ全部を（本番で）提供するけど、frontendが使うクエリだけだよ。ビルド時にコンパイルするんだ。新しいクエリ追加したいときは開発環境で決めて（非コンパイルクエリもOK、社外からは無理）、frontendに書けば次のbackendビルドに含まれる。これ全部結構普通の機能だよ。他の全員が馬鹿だって決めつける前に、システムがどう動くか5分くらい考えてみたら？

たぶん偏見かもだけど、GraphQLが意味をなすシナリオが全然見えないんだよね、複雑さがメリットに見合ってない。RESTのデバッグしやすさとかシンプルさを、ほぼゼロのメリットのために捨てることになる。

GraphQLは新しいMongoDBだね。みんな使いたがるイケてる新技術だけど、現実では全く意味不明で解決する以上に問題起こすだけ。Facebookみたいな特定の場所では意味ある問題を解決するけど、ウェブアプリとかウェブ・モバイルアプリしかない会社には全く意味ない。それだけ。GraphQL使うって決めるやつは馬鹿な決定してるよ。

どうして？RESTと同じデバッグのしやすさあるじゃん。もちろんツール経由でリクエストとレスポンス見る必要があるけど、直接見る以外ってのはHTTPS使ってない場合（こっちの方が大問題）以外はすでにそうだったしね。開発者/管理者ページにGraphiQL立ててみれば、昔のREST APIよりずっと簡単に探索的なクエリできるよ。

ふーん、データベースは1970年代から同じことやってるよ（例えばregexesも考えてみて）。結局、柔軟で表現力豊かなクエリを書く言語をワイヤーフォーマットとして使うのが、常に一番安全でパフォーマンスが良いとは限らないんだよね。

Goodreads API終了時にhardcover見つけたんだけど、APIのために作られたサービスみたいで、みんながAPIで何をしたいか予想できないからGraphQLを選んだのはすごく理にかなってると思うんだ。柔軟性が高いしね。でも、Railsへの全面書き直しが正しかったかは疑問だな。前も今もアプリ遅くてグリッチ多いし、Next.jsのままでもできたことだと思う。特にユーザー3万人規模なら、Next.jsで改善できたんじゃないかな。

君の「GraphQLは既存ライブラリみたいなもん」ってコメントの意味がやっと分かったよ。でもみんなExpressとかKyselyとか使ってるじゃん。Apolloだけがそうじゃないって？変だよ。ちゃんとしたREST APIに最初投資すれば、既存エンドポイント使えるし、frontend変更でbackendビルド待つ必要ないかも。メンテしやすいツール使えるし、Productも実験しやすい（frontend変更でbackend変更要らない）、それにFAANG発だからって流行りに乗らない方が良いよ。

「一番遅いエンドポイントをどのチームが担当してる？」みたいな単純な質問が、GraphQLだと計算するのが急に悪夢になるんだ。どの業界も分業に移った理由があるんだよ。セキュリティ管理もめんどくさそうに見えるし、そうだね、frontendは何でも好きなことできるけど、そんなこと誰も望んでなかった。

GraphQLのコンパイル済みクエリをバックエンドに追加しなきゃいけないんだろ？それって、GraphQLを使わない人たちがバックエンドで色々やんなきゃいけないことを批判してた、君が最初に強く反論してたことと全く同じじゃん。まさに君が今説明したやり方こそ、親コメントが君がやってるだろうと思ってたことだよ。

コメントありがとう！うちのアプリが今の構造になった理由、色々と言い当ててるね。そうそう、Next.jsに投資する手もあったし、Railsに移行するよりそっちの方が良かったかもしれない。でも、Railsだとエンドポイントがどうなるか（コードベース、コスト、キャッシュ、開発環境、デプロイ、ホスティングとか）全体像がすごく見えやすかったんだ。もしあの時間Next.jsに投資してたら、まだ unclear な答えもあったと思う。もちろん Next.js でもそこにたどり着けるだろうけど、道筋が Rails ほど明確じゃなかったんだ。

全くその通り！みんなこの議論をすぐに用意したみたいに持ち出すけど、ちょっと考えればわかるはずなんだ。こういう（どんなシステムにもよくある）欠点を抑えるためのツールやパターンはもうしっかり確立されてるから、真剣に技術を見てる人にとっては全然問題にならないよ。

＞ Sure, some use-cases might warrant the flexibility that GraphQL uses. A book tracking app does not.＜
これには同意！自分で体験をコントロールできるなら、僕も限られた体験のためにGraphQLを選ばないだろうね。プロジェクトはGoodreadsがAPIを終了したのがきっかけで、コミュニティのためにもっと良いものを作りたかったんだ。みんながどう使うか全然わからなかった。だから、提供できるものが多ければ多いほど、柔軟であればあるほど、解決できるユースケースも増えるだろうって思ったんだ。おかげで hundreds of people が僕が全く予想しなかった all kinds of things に GraphQL API を使ってくれてるよ。それが僕にとってのGraphQLの魅力で、使い道を後から考えられることかな。でも、GraphQL APIをゼロから作りたいとは思わない（もう二度と）。この場合は Hasura が全部やってくれたからね。うちの場合は REST API を作るより簡単だったんだ。

たまに external data providers （ほとんどが government agencies ）との連携を書かなきゃいけないんだけど、彼らは GraphQL をすごく好むんだよね。そこで使うのは IMHO としてもすごく理にかなってると思う。彼らは entity¹ に関するデータを X fields に分けて提供するんだけど、自分のアプリが必要なのは maybe 20% くらい。GraphQLのおかげで、その 20% だけをリクエストすればいいんだ。何億件もの records を読み込む時、 gigabytes もの不要な JSON を loading, parsing, そして throwing away する手間が省けるからね。¹ one example being tax records with all associated information about tax collecting agencies and taxpayers — it’s a lot of data

Facebookは publicly なアプリでは GraphQL をそのまま使ってるわけじゃないんだ。アプリは server side で定義された named queries を呼び出してるから、GraphQL はただの glorified RPC mechanism で、query language じゃないんだよね。

それは fair な意見だね。
そしてはっきりさせておきたいんだけど（元のコメントが否定的に読めるかもしれないから）、僕は hardcover がすごく気に入ってるんだ。たまにうまくいかないこともあるけど、UI が charming だし、良い open api があるし、reading がすごく好きな人たちが作ったのがすごくよくわかるから、僕の読書記録は全部 hardcover でつけてるよ。君が手に入れられる最高の成功を祈ってる！

＞ Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with.＜
何のこと？
ビルドプロセスが frontend が使いたい queries を取ってきて、コンパイルして、それを backend の build に含めるんだよ。 manual なステップは何もないし、 backend のコードや config を一行たりとも変えたりしない、ましてや新しい endpoint を書くなんてこともない。僕が知る限り、これは GraphQL の全く ordinary な使い方だよ。

GraphQLはもはや流行りじゃなくて、10年も前からあってプロダクションでも5年使われてるんだ。REST APIと比べてN+1問題とか有利な点もあるし、プロダクトチームも実験しやすい。ただ、チームが分かれた巨大システムならREST APIも良い。GraphQLはThriftやgRPCの流れを組んでて、多くの言語でライブラリがあるよ。人気なのは使えるからさ。

GraphQLでもトレースツールやセキュリティは必要だよ。それはいつも同じ。俺の経験だと、GraphQLのツールはraw HTTPSより悪くないし、情報が多いからむしろ良いことも多いんだ。例えば、権限で特定のフィールドを隠すとか、GraphQLなら一箇所で済むから手書きのAPIよりずっと簡単だよ。

うちでもNextJS使ってたけど、もうやめ始めてるんだ。理由はいくつか：認証が大変だった（next-authもiron-sessionも）。API gatewayじゃなかったからrequestをproxyする必要があったけど、docsが不明確で問題が起きた。Vercelのcloudに誘導したがるのも合わなかった。あと、maintainerがあまり親切じゃなかったんだよね。Chillicream/HotChocolateは神対応なのに！

何に移行したの？うちはNextJSをfrontendで使ってて、server-side/apiの便利な処理も少し使ってるけど、backendはDjangoなんだ。基本的にはReactJSをNextJSの便利な機能（file based routingとか）と一緒に使ってるだけって感じだよ。

俺はNext.jsよりRemixの方がこの用途にはずっと良いと思うな。ずっとシンプルだし、自分のサーバーでhostしやすい。Astroもすごく良くて、学ぶのもhostするのも簡単だよ。

他にもAngularのプロジェクトがあって、NextJSは一種のproof of conceptだったんだ。開発者が一つのfront-end frameworkで仕事できるように（そしてupdateについていくのが大変！）、それらのdeployをAngular familyのfeatureに統合し直してるとこなんだ。

Astro.buildってチェックした？必要なところにどんなframeworkでもdrop inできるから、持ってるAngular componentを持ってこれるし、必要ならReactに頼ることもできるよ。

俺はNext.JS検討した結果、server-side renderingにKotlinとKtor (html dsl + htmx) を使うことにしたんだ。backendもKotlinだよ。Kotlin + Ktorはserversideで書くのがマジで気持ち良い。Rubyみたいに速くて簡単でスラスラ書けるのに、Javaのエコシステムと型も使えるのが最高だよ。

htmldslでreusable componentってどうやってるの？Ktorをちょっと試した時、これだけ分からなくて、情報も見つけられなかったから、それが理由でちょっとやめちゃったんだよね。

再利用可能なコンポーネントを作るために、たくさんのextension functionsとKotlinのfunction pointer構文を組み合わせて使ってるんだ。それで、コンポーネント自体はこんな感じになるよ：

fun HtmlBlockTag.radioButtonWithLabel(…)

radioInput(…)
label { … }
}

使い方はこう：
call.respondHtml {
body {
div(…) {
radioButtonWIthLabel(…) {
+”Text for the label”
}
}
}
}

もっと複雑な例は、これをかなり拡張してるだけ。大きなセクションになる単一のextension functionのためだけにファイル全体を割くこともあるよ。それで、これらの単一ファンクションコンポーネントをテストするには、こうしてる：
class SingleSectionTest {
private suspend fun ApplicationTestBuilder.buildApplicationAndCall(…) : Document { … }

@Test
fun “simple test case”() = testApplication {
val data = DataUsedForSection(…)
val body = buildApplicationAndCall(data)
// all the asserts
}
}

こんな感じ。これが君が知りたかったこと？それとも違う例が見たい？

まさに探してた情報、共有してくれて本当にありがとう！これ、今まで見た中で一番いいやり方かも。ただ、Kotlinだと既存のHTMLタグの子（？）として追加せざるを得ないのがちょっと嫌だね、コンポーネントをimportするみたいにできたらよかったのに :(

Kotlinはそれを“Extensions”って呼んでるよ[0]。うん、結構面倒だよね。最初C#で知ったんだけど、StackOverflowとかMicrosoftのドキュメントでコード見つけても、必要なnugetパッケージ入れてないとメソッドがなかったりしてすごくイライラしたんだ。慣れてきて、それがどれだけ便利かも分かったけど、どうしても拭えない不満もいくつかあるんだ（importの問題とか、「このコードどこ！？」って問題とか）。Java/Typescriptでjsxやtsxファイルみたいに、ただのクラスとしてコンポーネントをimportできるとすごくクールだよね。データクラス作って fun renderInto(tag: HtmlBlockTag) { … } みたいなメソッド追加すればそれっぽくはできるけど、KtorのDslの実装上、結局dslが作ってる巨大なStringBuilder（か何か）に繋げなきゃいけない。それに近づけるために、僕は大きなコンポーネントにはファイル全体を費やして、ファイル名もルートのHtmlBlockTag Extensionメソッドと同じにしてることが多いよ（さっきの例ならRadioButtonWithLabel.ktみたいに）。そういうファイルは、たくさんのヘルパーメソッドを同じファイルにまとめておけるから便利で、クラスみたいに全部をまとめておけるんだ。[0] https://kotlinlang.org/docs/extensions.html

JSフルスタックでフロントもバックも特にDB絡みでやりたい時、みんなどうしてるのか本当に気になる。ORMの状況はバラバラに見えるし、pure sql書くか。バックエンドもexpressで生でいく？Next.jsは有名だけど目的が疑問だし（、Remix、Astro、TanStackとか色々。いつも使うものを調整したり再評価したりしないといけないから、ぐちゃぐちゃだよ。個人的なプロジェクトではRuby on Railsに戻っちゃうことが多いんだ。いつも気持ちいいんだよね。一方で、railsエンジニアはJSに比べてすごく少ないから、プロのプロジェクトには向かないんだ。JSとかバックエンドはJavaを選ぶのが無責任じゃなくなるんだ。みんなも同じ気持ちになる？

そうなんだよね。JSのORM状況は良くない。これが定番！っていうのがないし、その質問するとORMは別に必要ないよ、みたいな偉そうな返事がよく来る気がする。Kyselyは本当に良いけど、ORMじゃないんだ。僕の考えでは：JSエコシステムは理由もなく抽象化を避ける傾向がある。例えば、ウェブフレームワークがフォーム送信の形を透過的に検証すべきじゃないって考えるのは、魔法すぎるからって理由。代わりに正しいやり方とされてるのは、入力の形を記述するためにDSL（Zodとか）を学んで、それをチェックするコードを手作業で毎回書くこと。あ、それはReasonsっていう理由でTSの型でやっちゃダメなんだ。これ全部、Rails/Spring/ASP.NETみたいな、ゆうに10年以上前から確立されてるプラットフォームの存在を意図的に無視してるようにしか見えないんだ。良いアイデアを盗めばよかっただけなのに。でも、多分そういうフレームワークの最大の罪は、もうクールじゃなくなったことなんだろうね。これをあまりネガティブに聞こえないように伝えるのが難しいんだ。TSでSSRウェブ開発に挑戦しようとして、オープンな気持ちで臨んだんだけど、僕にとって必要な材料がそこにはなかった。Viteは開発がすごく快適だから、残念だよ。

定番はDrizzleだよ

うちは今、主要なアプリが二つあって、一つはtypescript、もう一つはrailsなんだ。両方でエンジニアを雇わないといけないんだけど、railsエンジニアを見つけるのがnode/typescriptエンジニアより難しいなんて経験はないよ。むしろ、スタックがずっと標準化されてるから、関連経験のあるrailsエンジニアを見つける方が簡単だとさえ思う。node経験がある人だと、たとえnodeエコシステムの他のライブラリを使ったことがあっても、うちが使ってるライブラリの経験が全くないって可能性がすごく高いんだ。でもrailsなら、経験ある人なら誰でもうちのアプリケーションにすぐに飛び込めて、お馴染みのものがいっぱい目に入るよ。個人的には今はelixir Phoenixのファンボーイだから、個人のプロジェクトではrailsを第一候補にはしないけど、会社にとっては素晴らしい選択肢だと思う。実際、人を雇う必要があるなら、他のどんなフレームワークよりも一番おすすめするかもしれないな。

＞ 定番が一つもないって
Prisma.jsが圧倒的に一番人気だと思ってたけど？ドキュメントとか例でいつも見るのはそれだよ。

面白いね、僕はPrismaが定番だって言うかな。うちはヘビーに使ってるけど、全然問題ないよ。

Elixir / Phoenixがもっと人気になることを本当に願ってるよ。これでサーバー書くのはすごく簡単だし、ホスティングやデプロイも楽、アップグレードも（今のところ）痛みがなかったし、lintingやデバッグもすごく簡単だった。Rubyから来るなら、Elixirを学ぶにはちょっとした頭の切り替え（オブジェクト指向から関数型へ）が必要だけど、そのハードルを越えれば、ElixirでのプログラミングはRubyと同じくらい楽しいよ！ :)

うん、良いと思うよ。ただ、俺の（Djangoっていう）黄金基準にはちょっと足りないかな。良い自動マイグレーションとか、マイグレーションでのトランザクションがないんだよね。

なんでそんなに混乱すんの？俺の経験だと、常にプロジェクトの調整は必要だよ。イケてる新しいフレームワークなんて5年で廃れるしね。常に一部は書き換えることになるから、書き換えが楽なエコシステムを選んだ方がいいんだよ。

両方使ったけど、TSコミュニティでは今Drizzleが定番になってるよ。

＞ JSのフルスタックでフロントもバックも、特にDBあるときってどうしてるんだろう？Gel [1]使えばいいじゃん。ORMいらないし（他にも色々便利だよ）。[1] https://www.geldata.com/

ベテラン開発者の悲しい宿命は、良いものが消えて、それが再発明されて、みんなが『すげー！』って騒ぐけど、昔からあったの知らない、って状況を見ることだね。いつか誰かが良いアイデアをパクるんだ。で、みんな初めて出てきたかのように振る舞う。これ、何度か見てきたけど、毎回自分が年取ったなって感じるよ。

500件も報告されてる未解決バグの一つに遭遇しなくてマジ幸運だったわ！

笑。んで、来年にはまた別の何かになってるだろうね。Drizzleとかまだ1.xにもなってないし。

Railsから来るなら、ここから始められるよ 😉 https://phoenixonrails.com/

次に何か作る時に試してみるよ。職場の組織としては、何十ものプロジェクト全部Prismaを使ってるから、違うの試すのは大変そうだけどね。