16,703 文字
今日では、Laravel、Rails、Next.js、Tanstack start、Solid startなど、多くのエコシステムにわたって毎週のように新しいフルスタックフレームワークが登場しているように感じます。しかし、これらはすべて非常に異なっています。ReactとAngularが異なるというような違いではありません。
これらは、何をするために設計されているか、そしてあなたのプロジェクトに対してどれだけの制御力を持っているかという根本的なレベルで異なっています。私たちは時々「バッテリー同梱（batteries included）」という言葉を使いますが、これらのツールがどれほど異なるかを適切に表現しているとは思いません。そろそろこれについて話し合うべき時だと思います。
楽しい話題になるでしょう。Excaladorでこれらすべてを分析するのにかなりの時間を費やしています。その前に、今日のスポンサーからの簡単なお知らせです。
私はこれまで以上にコードを書いていますし、私のチームも同様です。これは素晴らしいことですが、今やはるかに多くのコードレビューをしなければならないという事実を除けば。コードレビューは楽しいものではありません。すべての行を細かくチェックして小さなミスを探すのは、特にPRが何をするのかの良い概要がなければ、かなり面倒です。そこで、今日のスポンサーであるCode Rabbitが登場します。
Code Rabbitは…待って、それはCode Rabbitではありません。それはGitHubですらありません。それは私のエディタです。なぜCode Rabbitのコメントがあるのでしょう？待って、移行作業中にto-doを削除し忘れたのでしょうか？それを知ることができてよかったです。
皆さんはどうか分かりませんが、私はまだ作業中のコードをGitHubにプッシュして参照ポイントを持つのが好きです。そして気づかなかったのは、そうすると自動的にCode Rabbitがレビューしてくれることでした。これが本当に便利なのは、コードを書いているときにGitHub VS Code拡張機能を使っていることです。ちなみに、PRにこれをまだ使っていないなら、それは素晴らしいですよ。エディタ内で直接PRを開いて、誰かが作業しているものを見て、カーソルなどを使って読むことができます。本当に便利です。
さらに便利なのは、作業中にインラインでコメントを残してくれることです。ここにコメントがあります。ミスを見つけるのに本当に役立ちます。実際、出荷しようとしていたバグがCode Rabbitがエディタ内で私が見逃していたことを教えてくれたおかげで完全に回避できたこともあります。
正直に言うと、それだけでも価値があります。しかし、PRの規模に関係なく、コードベースについて実際に良い提案をしてくれるという事実は素晴らしいです。学習していくので、「これについては気にしない、今後教えないで」と言えば、それを記憶して二度と通知しません。
AIのコード提案を私ほど真剣に受け止めるとは思っていませんでしたが、Code Rabbitとのやり取りを少し重ねた後、コメントの90%以上が実際に変更すべきものだと感じるようになりました。Code Rabbitに何かについて警告しないよう伝えたのを最後に覚えていません。約3回のコードレビュー後、非常に的確になりました。
記録を取っていませんが、Code Rabbitを導入してから少なくとも12〜24個のバグがプロダクションにリリースされるのを防いだと推定しています。月額12ドルで、それは本当にお買い得です。Proプランでも24ドルで、迷わず支払います。Code Rabbitを取り上げられて月300ドル払えと言われても、冗談ではなく払うでしょう。彼らはこの部分を言わせるために払っているわけではありません。無料クーポンコードをもらいましたが、請求額が十分安く、サービスが十分良かったので使いませんでした。
信じられないなら、試してみてください。無料トライアルは非常に寛大です。気に入るかどうか確かめてください。きっと驚くでしょう。soyv.link/coderabbitで今すぐチェックしてください。
フルスタックは意味のない言葉です。切り口によって、Reactには3つの選択肢があります。実際にはもっとたくさんあります。そして他のソリューションにも同様のものがあります。
しかし、これらのうちいくつかは少し変わっています。それらが奇妙な理由については後ほど説明します。他のエコシステムにはそれほど多くのソリューションがありません。ElixirにはPhoenix、RubyにはRails、PHPにはWordPress…冗談です。Laravelがあります。PHPには他にも多くの選択肢があります。
これらの言語には独自のソリューションセットがあります。特に注目したいのはPythonです。PythonにはFlaskとDjangoがあります。この2つの違いは、私が取り上げたい多くのことを表していると思います。以前に両方を試したことがあるので知っています。そしてそれらがどれほど異なるかを理解したとき、私の生活はずっと良くなりました。
Fast APIと言う人もいるかもしれませんが、それについて気づくことがあります。Fast APIと呼ばれています。確かにHTMLを提供できると思いますが、それが構築されている目的ではないと思います。FlaskとDjangoはアプリケーションを実際に提供することを目的としています。
Pythonの世界に詳しくない方のために、これら2つのソリューションをさっと見てみましょう。ここで強調したいのは、セットアップの違いです。この入門ガイドには、Apache、PostgreSQL、MariaDBなどのデータベースソリューション、その他の設定に関するすべての情報があります。そして実際に始めるときには、initを実行すると、これらすべてを含むプロジェクト全体が作成されます。
管理ファイル、初期化ファイル、設定、URL、その他のさまざまなものがあります。対してFlaskの入門は単にこれだけです。Flaskをインポートし、サーブし、ルートを定義し、HTMLを返します。これらのソリューション間には大きな違いがあります。1つのソリューションはあなたに構築方法を教え、あなたが構築したいかもしれないすべてのものを構築するためのすべてのピースを提供しようとしています。
もう1つは、コードベースとブラウザに存在するものとの間の関係を構築する方法です。FlaskとDjangoは、この分裂がどこで発生するかを表す良い出発点だと思います。なぜなら、それらは非常に異なり、ユーザーが見る特定のURLでPythonがHTMLを生成できるようにすること以外は同じ問題を解決しません。
これらを区別するための良い用語をまだ思いつくことができません。近い将来思いつけることを願っていますが、今のところ、「フルスタック」と「フラースタック（より完全なスタック）」と呼ぶことにします。
フルスタックの定義は比較的シンプルだと思います。バックエンドとフロントエンドです。バックエンドとフロントエンドの連携を容易にするものは、フルスタックと考えられます。そして明らかに、これは両側で実行されるべきです。
したがって、フルスタックフレームワークは、ブラウザでレンダリングするための本当に良い方法を提供するバックエンドのものであるべきです。それは組み込みのテンプレートエンジンか何か同様のものでもよいですし、もちろんNext.jsのように、サーバーとクライアントの両方でJavaScriptコードを実行して、両側での動作が最良であることを確認するものでもよいでしょう。
対して「フラースタック」はかなり異なります。明らかにバックエンドとフロントエンドにプラスして、データベース、認証、ミドルウェアパターン、API生成などなど。「バッテリー同梱」と言うとき、人々が参照しているのはこれらすべてのものです。
そしてNext.jsのようなものを見ると、これらのものは何も含まれていません。そしてNextにはミドルウェアがあると言わないでください。Next.jsがミドルウェアをミドルウェアと名付けるべきではなかったのです。なぜなら、ミドルウェアという言葉は他のほぼすべてのエコシステムで非常に異なる意味を持つからです。定義が特によく重なることはまれです。
ミドルウェアは、すべてのAPIリクエストの間に実行されるものを意味することがあります。ミドルウェアは、どのルートにヒットするかによって異なるもののことを意味することがよくあります。それは、特定のものの前に置くことができる層であり、正しいデータがそこに到達するまでに確実に存在するようにするためのものです。
しかしNext.jsでは、ミドルウェアはユーザーがどのページにいても正しいページに行くようにするための方法として使用されます。これはグローバルなものであり、Next.jsのグローバルミドルウェアと、たとえばTRPCやLaravelや皆さんのお気に入りのNestJS（Nextではなく）のようなものから得られるより組み込まれたルートごとのミドルウェアの違いは大きいです。
Xが別の楽しいソリューションのためにSに変わります。最近Nestについてあまり聞いていませんが、それは良い兆候です。以前は人々がNextとこれを混同することがよくあり、それが私に多くの問題を引き起こしていました。
Nestはバッテリー同梱の方向に傾いています。例を見ると、ブートストラップのような始め方があります。始まると、ここにいます。これらの素晴らしいデコレーター（@controllersや@get）が得られます。私はデコレーターが嫌いです。これらのパターンが嫌いです。なぜそうしているのか理解していますが、これはMVCです。これは別の議論すべき点です。
なぜか「フラースタック」はMVCを意味することが多いです。MVCはModel、View、Controllerの略です。アプリケーションの懸念事項をこれらの異なる垂直方向に分離する方法です。何かに取り組んでいるとき、コードがどこに配置されるべきかを理論的に正確に知っているはずです。
現実的に言えば、そのようになるとは限りません。しかしMVCはとても一般的なパターンです。Railsコミュニティによって大きく普及しましたが、それ以来それほど人気ではなくなりました。しかし、まだ絶対に存在するものです。
私が期待しているのは、MVCがもはや暗示されないフラースタックフレームワークの未来です。MVCがこれらのことをするときにほぼ期待されていることが好きではないからです。嫌いです。
誰も怒らせないような図を作りましょう。Next.jsから始めましょう。皆さんは比較的よく知っていると思います。Next.jsは明らかにフロントエンドを非常に優先しており、プリミティブも最小限です。支払い管理や認証のようなアプリケーションを構築するために必要な多くのものを提供していません。
プリミティブはそれらを自分で構築するのをずっと簡単にしますが、それらは提供されておらず、これは多くの開発者、特にエコシステムに慣れていない初心者にとって失敗の落とし穴になる可能性があります。なぜなら、何を使うべきか知らないからです。
実際に言えば、アプリをリリースするときはこちら側にいなければなりません。どこかからバッテリーを手に入れる必要があり、Nextはそれを提供しません。私はそれが好きです。なぜなら、それによってスペースにおいて大量のイノベーションが起こることを可能にするからです。最初は本当に悪い認証ライブラリがあり、時間が経つにつれて、よりよいパターンとパラダイムを持つ新しいものが発見され、スペースにおける認証を大幅に向上させました。
APIの使い方などについても同様です。TRPCのようなツールが発明され、さらにはGraphQLもこの最小限のエコシステムが可能にするものによって発明されました。また、使っているツールがあなたの必要なことをしない場合、ブロックされることなく独自のソリューションを構築できることも意味します。
一方、Laravelでは、実行が優先されますが、それほど高く優先されていません。しかし、多くのバッテリーが付属しています。とはいえ、それらのツールの1つがあなたが必要とすることを正確に行わない場合、あなたは少し運が悪いです。多くの場合、それを回避することができますが、Laravelがもたらす幸せなパスは非常に多くの時間非常に幸せです。
しかし、それがそうでないときには、痛みを伴います。他のソリューションほどではありませんが、Railsのようなものです。ここで怪しい点があるかもしれません。それはこれらの間の大きなギャップです。フロントエンドとバックエンドの優先度の線でLaravelをもう少し近づけるべきでした。
LaravelをRailsよりもフロントエンドとバックエンドの面で高く置いた理由は、Laravelがフロントエンドでの良い体験を作ることと良いバインディングを構築することに多くの努力を注いでいるからです。LivewireからInertiaまで、素晴らしいものがあります。
Livewireはウェブソケットを使用してバックエンドとフロントエンドを同期させる素晴らしい方法であり、Inertiaはあなたのララベルコードベースにリアクトを導入し、フロントエンドのための良いプリミティブを使用しながら、適切なデータを適切な場所でサーバーレンダリングできるようにします。このバランスは本当にクールです。
彼らはJavaScriptを書きたくない場合に良いフロントエンドのプリミティブを提供することに多くの努力を注いでおり、より複雑なフロントエンドを作る必要がある場合にはInertiaのようなもので素早くクライアントサイドのJavaScriptにフックできるようにしています。ReactコードはLaravelの一部ではありませんが、必要であれば導入できます。そしてそれがLaravelについて私が好きな点です。
ここに入れたいフレームワークの1つを忘れていることに気づきました。FlaskとDjangoの違いに戻りましょう。両方とも明らかにバックエンド優先です。しかし、これが彼らの違いです。Djangoは非常に「バッテリー同梱」型です。Flaskは非常に最小限です。多くのプリミティブを持っていません。FlaskはExpress.jsに近いものです。
Flaskがネクストよりもバッテリー同梱型だというのは公平な指摘です。チャットさん、いい指摘です。それらは同じ位置にあります。フロントエンドとバックエンドの優先順位が異なるだけです。
NextとFlaskがそのスペクトル上では全く同じ場所にありながら、もう一方のスペクトルでは完全に逆であると言うのは面白いことです。そしてElixirの世界からPhoenixがあります。
Phoenixについてすでにご存知の方は、Railsで起こっているクールなものからインスピレーションを得て、さらに一歩進めることを目的としていると言えます。フロントエンドとバックエンド間の同期など、すべてがElixirエコシステムのすべての利点を生かしています。これはクールなフレームワークです。私は楽しんできました。フロントエンドではまだReactを使うことを好みますが、PhoenixとElixirは本当に楽しいです。
私はElixirが大好きです。ここでLive Viewを使用しているのがわかります。これはフロントエンドの更新を行う方法で、LaravelのLivewireはLive Viewにインスパイアされています。HTMLをレンダリングし、更新をトリガーする割り当てをバインドするのが非常に簡単です。
マウントするとき、Twitterへのサブスクリプションを作成します。これはこのコードベースですでに構築されているプリミティブです。そしてElixir Phoenixに更新があるたびに、ソケットをその値からのツイートに割り当て、それらがメッセージとして送信されます。これがあなたが書かなければならないコードすべてであり、フロントエンドは自動的に更新されます。これは本当にクールで、彼らはこれらのタイプのことを考えるのに多くの時間を費やしています。
しかし、彼らもInertiaのようなツールについては真剣ではありません。PhoenixでもInertiaは機能しますが、それは彼らが積極的に推進しているものではなく、彼らのものに含まれているわけでもありません。
だから、私はそれらを少し低く、かつバッテリー同梱の度合いも低く配置します。なぜなら、LaravelのようなStripe統合などを多く持っていないからです。Laravelのサイトに行くと、彼らが構築したものの量はすごいです。エコシステムを見ると、それらすべてを見るためにどれだけスクロールする必要があるかを見てください。
これはこの世界に存在する多くの部分です。その点では非常に異なりますが、全体的には似ており、絶対的にバックエンドフレームワークを傾けつつも、かなりフロントエンド重視です。
この図があれば、問題がわかるかもしれません。人々がフルスタックについて話すとき、彼らはしばしばこれらの軸の1つだけを考えています。フルスタックがこの軸だけを意味すると考える人もいるかもしれませんし、この軸上にある限り、それらはフルスタックだと考えるかもしれません。
一部の人々は、フルスタックとはフロントエンドについて多く考えるがバックエンドのプリミティブを提供するものだと考えるかもしれません。一部の人々は、フルスタックとはバッテリーをたくさん提供することを意味すると考えるかもしれません。なぜなら、フルスタックについて考えるとき、彼らはフロントエンドとバックエンドだけでなく、アプリのすべてについて考えているからです。
ある人はこれがフルスタックだと思うかもしれません。そして「バッテリー同梱」を追加すると、それはもはやフルスタックフレームワークではなく、アプリケーションフレームワークになると。
これらのことをどのように考え、これらの範囲をどのように拡大・対比するかによって、フルスタックは人によって非常に異なるものを意味します。一部の人はフルスタックがここにあるすべてのものだと考えるかもしれません。一部の人はフルスタックがここにあるすべてのもの、あるいはここ、またはその他すべての異なる場所だと考えるかもしれません。
そして誰かがLaravelは本物のフルスタックフレームワークであり、Nextはそうではないと言うとき、彼らが言っているのは、これが彼らが信じているボックスであり、こちら側にあるものは、これらはフルスタックフレームワークではないということです。
これが現代の混乱の多くが来るところだと思います。これらのスペクトルが存在し、異なるツールがそれらの中の異なる場所に構築されており、彼らが構築し優先するものの違いによって異なる前提が生まれてくるということです。
しかし、これから発展する興味深い特性もあります。Next.jsのような非常に最小限のものを見ると、Next.jsの周りに作成される他のものがあります。Blitz.jsのようなものです。
Blitz.jsについては、どれくらい活動停止しているのかわかりません。かなり終わっているように見えますが、Blitz.jsはNextの周りに構築されたフレームワークです。ある時点では、実際にNextの完全なフォークでした。
彼らはTRPCに非常に似た独自のRPC層と、クライアント側での更新を行うためのReact Queryを導入しています。彼らは独自の認証層を導入しています。データベース層にはPrismaを導入しています。彼らはこれらすべてのツールを導入しています。
つまり、決断をする必要がありません。単にインストールするだけです。人々が配布したり販売したりする同様の方法で構築するためのキットもあります。例えばKent C. DoddsのEpic Stackです。これは、Remixで異なる構築方法を始めるのに役立つ、Kentが作成したさまざまな出発点のセットです。
そして私の個人的なお気に入りである、create T3 appなら、もっとバッテリーを提供しますが、すべてではありません。これは更新を受ける管理されたフレームワークではなく、単なる出発点です。
しかし、Nextについてはクールなことで、私たちが追加のことを構築したり、その周りに出発点を構築したりできる出発点です。これを考える別の方法は、フロントエンドとバックエンドの2つの懸念事項があるとすれば、認証、キューイング、データベース管理、支払い処理など、他の懸念事項もあるということです。
Next.jsはフロントエンドとバックエンドをカバーします。バックエンドを完全にカバーしていないと主張することもできますが、それは図を悪く見せます。そして、Blitz.jsのようなものを取ることができます。これはカバーする範囲を拡大し、今ではこのようになります。Blitzはより大きな部分をカバーしますが、まだすべてをカバーしてはいません。
しかし、Laravelのようなものを取ると、これらすべてをカバーします。これは、ツールがカバーする円の大きさを考慮することが重要であるという点です。これは一つの意味で素晴らしいことです。キューイング、支払い処理、データベース管理、認証などの周りで決定を下す必要がなく、届けようとしているソフトウェアの提供に集中できるからです。
しかし、その問題に対する彼らのソリューションがあなたのユースケースに完璧にフィットしない場合、より多くの作業をする必要があるかもしれません。しかし、もしNextでこれを構築するなら、好きなようにできます。認証はClerkにすることもできますし、多くのオープンソースソリューションのいずれかにすることもできます。JSエコシステムの現在の認証状態についての動画がもうすぐ公開されます。
これらすべてを動画やコンテンツで常に把握する必要があるのは少し面倒ですが、満足しているソリューションを選んでそれについての決断を止めるか、単にLaravelを使うこともできます。それも全く問題ありません。
データベースにはDrizzleやPrismaなどのいずれかを使用できます。他にも多くのオプションがあります。同期化や他の機能を備えたSupabaseクライアントも存在します。
これらの異なるソリューションは互いに単なるドロップイン置換ではありません。なぜなら、そのSupabaseクライアントを追加すると、それは完全に異なる動作をします。バックエンドとフロントエンドの間でウェブソケットを使用して自動的に同期化を追加します。Laravelでそれを持つには、Livewireを使用する必要があります。しかし、Inertiaを通じてフロントエンドのものを使用しているためLivewireを使用したくない場合、今やその結合を独自の方法で構築する必要があります。
支払い処理にはStripeとティアがあります。そしてキューイングにも多くのオプションがあります。trigger.devのようなものがあります。Netlifyが彼らのデプロイメントプラットフォームに構築した新しいキューイングシステムがあります。それは本当にクールです。前に話したIngestもあります。そこにはたくさんのオプションがあります。KFKAの上に自分でスピンアップすることもできます。
これはクールです。それはあなたがより多くのアーキテクティングをしていることを意味します。これらの物事の関係についてより多くの決定を下しています。間違った決定を下す可能性もあります。決定を下したくない可能性もあります。3年前に下した決定が、あなたのコアシステムの一部として廃止されたソフトウェアになってしまったという問題に遭遇する可能性もあります。
これらのことが起こる可能性は多くあります。しかし、それはまた、これらの個別の部分を交換できることを意味します。これらの個別の部分を構築している企業と協力できます。貢献できます。これらのことを交換できます。より多くの制御権を持っています。しかし、すべての人がその制御を望んでいるわけではありません。
これがツールの違いを視覚化する良い方法だと思います。Laravelはフロントエンドとバックエンドをカバーするだけでなく、これらすべての部分もカバーしています。いくつかについては別の方法を提供しています。フロントエンドでは、Inertia+Reactを導入できます。Vueも導入できます。彼らは実際にVueを非常によくサポートしています。しかし、残りについては、彼らが提供するものを使うことになっています。
これらのものを分けるためのより良い用語があればと本当に思います。なぜなら、「バッテリー同梱」ではこれらがどれほど異なるかを正確に説明していないからです。そして「フルスタック」はこれら両方のソリューションを正確にカバーしていません。
実際にチャット投票をします。「フルスタック」はORMなどが組み込まれていることを意味すべきでしょうか？はい、いいえ、どちらでもない。
以前「JavaScriptにはなぜLaravelがないのか」という動画を作りました。もしまだ見ていなければ、そこで本当に言いたかったのは構築に関する哲学についてです。好きな小さなフレーズがあります。Unix哲学は、組み合わせることができる個々のブロックを構築するという考えを表す素晴らしい用語です。
それは、開発者がその作成者以外の人によって簡単に維持され再利用できる、シンプルで、コンパクトで、明確で、モジュール式で、拡張可能なコードを構築することを強調しています。この部分はJSには適用されないかもしれません。冗談です。実際には適用されると思います。
古いReactコードベースに戻っても、クラスコンポーネントだらけでも、すべてがうまく動作することに驚かされてきました。モデルの十分な部分が同じです。むしろ、エコシステムとしてReactをより理解するようになったので、コードベースはまだ動作するだけでなく、クリーンアップもできます。パッケージロックがある限り、すべてがうまく動作します。
しかし、この構成可能性の考え方は、JSについて素晴らしいことだと思います。「宇宙で最も重いオブジェクト」という誰もが好きなミームがあります。それは公平な指摘ですが、一方で、それはエコシステムをクールにしている部分です。
Claudeに質問します。Ubuntuの新規インストール時に依存関係はいくつありますか？この数字を得る簡単な方法があるかどうかわかりません。
見てください？新しいUbuntuデスクトップインストールには、デフォルトで1500〜2000のパッケージがあります。Unixへようこそ。
特定の問題を解決する小さな部品を持つコストの一部は、それらが多いということです。多くの依存関係があります。比較すると、最小限のUbuntuサーバーインストールには300〜400しかありません。サーバーをセットアップするのに300〜400のパッケージです。それはそれほど悪いことだとは思いません。
WindowsやmacOSのような他のOSと比較すると、同じような意味でベンダーのパッケージという概念がないため、実際に計算できる数字ではありません。DLLは確かに奇妙なものですが、Laravelのような何かの内部を見れば、彼らが頼っている多くの内部的なものもあるでしょう。
言おうとしているのは、やっていることに非常に焦点を当てた個々のブロックがあり、他のものに交換できるこの構築方法は素晴らしいということです。そして、それはLinuxが素晴らしい理由の一部です。より良いものが来たとき、または現在使用しているものが私たちが持っている問題を解決しないとき、個々の部品を交換できるからです。
そして私はそれが好きです。そして、最もUnix哲学に基づいた言語が圧倒的にJavaScriptであることは面白いです。Rustも近いです。なぜなら、Rust世界も必要なときにパッケージをインストールすることにかなり満足しているからです。しかし、ここで重要な詳細は、これらの部品をどのように構成するかです。これらのフレームワークの構成の性質は本当に、本当にクールです。
それが昔、DjangoよりもFlaskが好きだった理由です。最小限の出発点が好きでした。なぜなら、それは始めるのが簡単で、あなたのシステムを理解するのが簡単だったからです。
もう一つ非常に重要な詳細があります。ここで私たちのサービスがキューイングを必要としないとしましょう。削除。無料サービスだとしましょう。削除。
コードベースのサイズ、管理している複雑さ、行っていることの量は、解決している問題に直接比例してスケールします。これは、現代のソフトウェア開発で十分に話し合われていないと思うことです。
最高のツールは、コードベースが常に本当にシンプルに見えるものではありません。なぜなら、現実は複雑だからです。私の意見では、最高のツールは、コードベースの複雑さが解決している問題の複雑さに比例してスケールするものです。
これら2つのソリューションの出発点を見るだけでも、Nextアプリを初期化することとLaravelアプリを初期化することを比較すると、ファイルの数だけでもこれがどれほど異なるかを示しているはずです。そしてそれはLaravelが何か悪いことや間違ったことをしているとは言っていません。
Laravelは、初期化するとすぐに、ほとんどのアプリケーションに必要なもののほとんどを提供します。しかし、これら2つのソリューションで始めるとき、一方はもう一方よりもはるかに明確です。そして、私たちが十分に話し合っていないと思う別のことがあります。それは、これらの部分がどのようにルーティングされるかの複雑さです。
もしすべてがフレームワークによってつなぎ合わされている場合、バックエンドとInertiaの関係、それが認証層とどのように通信するか、ORMがどのようにデータベース層に入るか、支払い処理がデータベースとどのようにリンクするか、それがどのようにバックエンドを通過するか、そしてユーザーの認証を検証するか、またはバックエンドに達したとき、彼らが何かに支払うことがキューをトリガーし、それがデータベースを更新し、それがフロントエンドの変更をトリガーすることを認識するのかを私たちはどのように知るのでしょうか。
これはすべてLaravelがあなたがするのを助けるものですが、あなたはLaravelがあなたがすでに理解している方法でそれを行っているか、あなたが解決しようとしている問題に対して十分にシンプルな方法でそれを行っていることを望まなければなりません。Nextはこれらのことをあなたに提供しようとしません。Nextはこれをあなたの問題にします。それはあなたがより多くのこのコードを見ることを意味します。
あなたは異なるものの間を行くこれらの矢印を見るでしょう。一方、Laravelでは見るのが難しいです。Laravelアプリに取り組んでいたときに遭遇した一例は、誰がツイートを編集できるかの権限がどこにあるのかを理解しようとしていたことです。
権限を扱える場所はいくつかあります。ルートファイルでは、どのpost、put、get、updateメソッドが許可されるかを選択できます。そこで受け入れられるモードを選択できます。権限ファイルの中では、ユーザーがアクセスすべきフィールドとアクセスすべきでないフィールドを選択できます。モデルファイルでは、更新されるものの所有者を定義する方法を選択します。コントローラーファイルでは、更新をトリガーする前に入力の検証を行います。
そして今、私は結果が起こる前にユーザーのリクエストが通過する層を頭の中で知る必要があります。私はその分離が好きではありません。なぜなら、ユーザーがリクエストで何をしているのかを実際に処理する前に、それらすべての層を理解する必要があるからです。そして、Nextで同様に複雑なものを設定できないとは言っていません。
私が言っているのは、あなたがそれを設定する必要があるということです。パーツがどのように動作するかを知る必要があります。なぜなら、それらを互いにつなぐ必要があるからです。そして、それが私がこの構築方法を愛する理由の一部です。なぜなら、最小限のものから始めて、必要なときに必要な部品を追加できるからです。
これはまた、T3スタックを始めたとき、テンプレートリポジトリを作ることを拒否した理由でもあります。なぜなら、そうすれば、人々がブログにデータベースや認証層、分析ツールなどをセットアップするだろうと知っていたからです。そして、ブログはこれらすべての異なるものを必要としません。
それがcreate T3 appがとても素晴らしかった理由です。なぜなら、初期化するときに何が必要で何が必要でないかを選択するからです。そしてLaravelの人々もその方向に進んでいます。それを見るのはクールです。
私はNextとLaravelの出発点が同様に最小限であり、両方に層を追加することが同じくらい簡単である未来を見たいと思っています。
「npx v0 add clerk」というコマンドを実行できて、それが正確にclerkをセットアップし、「npx v0 add upload thing」で今やファイルのアップロードと管理がアプリケーションで処理されるようになるなど、そういうことができたらいいのにと思います。これらすべてのタイプのことは本当に素晴らしいでしょうし、このエコシステムはゆっくりとその方向に進んでいます。
Laravelはすでにその部分を持っています。なぜなら、それらすべての問題に対するソリューションを持っており、その多くはファーストパーティだからです。これらは単に異なる構築方法ですが、LaravelがMVCから離れるような日が来れば、それらはますます似てくると思います。それはありそうもないことですが、もしそうなればクールでしょう。
はい、私はまだここの分離のためのより良い用語が必要です。考えていたのは、フル対フラーに戻ると、アプリケーションスタックまたはアップスタックかもしれません。特に他の紛らわしいツールがあるので難しいです。
別のスペクトルを作ります。このスペクトルでは、一方にサーバーがあり、もう一方にユーザーがいます。サーバーとは言いません。ベアメタルと言いましょう。どこかにデータベースがあります。
そして、データベースなどと実際に連携するAPIなどのサービス層があります。次にクライアントAPIがあります。次にフロントエンドフレームワークがあります。次にコンポーネントライブラリ、つまりデザインシステムがあります。そして最後にユーザーがいます。
そして、私たちが完全なスタックやより完全なスタックと言っているほとんどのものはそうではありません。それらはしばしばこれだけです。彼らはデザインシステムには入りません。あなたのものをどうデザインするかは教えません。コンポーネントライブラリは付属していません。また、彼らはしばしばこちら側にも行きません。
ORMは持っているかもしれませんが、データベースはあなたに含まれていません。そして興味深い製品があります。たとえばConvexのようなものです。もし知らなければ、Convexはバックエンドの唯一の選択肢です。関数とデータベースのものを単一のファイルとして書く方法であり、それをフロントエンドコードから直接呼び出すことができます。
そしてConvexのようなものを見ると、それはここにあります。ConvexはデータベースからクライアントAPIまでの全範囲をカバーしています。しかし、それをLaravelと比較すると、ORMを使ってデータベースの半分まで行き、フロントエンドフレームワークの半分まで行きますが、それ以上は行きません。
そしてNext.jsを見ると、それは文字通りこれだけです。そして実際に定義して使用するクライアントAPIの量もあなた次第です。このようにNextを使用することもできます。BFFパターン（フロントエンドのためのバックエンド）を活用します。たとえ他の何かで書かれた別のAPIを呼び出すだけであっても、彼らのバックエンドを使用します。それも大丈夫です。しかし、それはそれがあなたに与える柔軟性の一部です。
「完全なスタック」をLaravelの用語として作り出し、それをここと定義するとしたら、誰かがLaravelのようなものを作って、Material UIを付属させたらどうなるでしょうか？それは「より完全なスタック」になるのでしょうか？誰かがそれをフォークして、Convexを追加したらどうなるでしょうか？それは「最も完全なスタック」になるのでしょうか？
これ全体は範囲であり、スペクトルであり、どの用語もここの異なるセクションを適切に包含することができません。そして、それが混乱とフラストレーションの源だと思います。「フルスタック」にはバックエンドからフロントエンドへの複数の軸があり、また最小限からバッテリー同梱までの軸もあります。そしてそれらのバッテリーが含まれていることは、それらがものにどれだけの所有権を持つか持たないかという範囲でありえます。
「フルスタック」という用語を引退させたいです。これは残念なことです。なぜなら私は「フルスタック」のYouTuberのようなものだからです。しかし、本当にこれをBFスタックのような、これがただバックエンドとフロントエンドだということを強調するような何かと呼びたいです。
「ザ・スタック」と呼びたいですが、みんなが怒りすぎるでしょう。Mabelは「センタースタック」という良い提案をしました。実際、40 Hzさんのこのポイントが好きです。なぜなら、これは私が歴史的にそれを使ってきた方法だからです。
私は個人的に、バックエンドとフロントエンドを考慮するものはすべてフルスタックと考えてきました。つまり、このスペクトル上のどこにあっても、私が個人的にフルスタックと考えるものです。なぜならスタックはフロントエンドとバックエンドであり、フルスタックは両方を行うときだからです。
私はウェブスタックを見ます。それの問題は、バックエンドについて全く考えたくないウェブ開発者がたくさんいることです。そして、ウェブスタックが何らかの形でバックエンドを行う必要があると彼らに言えば、彼らは動揺するでしょう。
でもバックエンドはいいですね。そう思います。バックエンドが好きです。フロントエンドに移行したバックエンド開発者です。だから、Nextのようなものが最小限で、私が望むようにバックエンドを行わせるという事実が好きです。単なる意見の違いです。
そして、もう一度明確にしたいのは、Rails以外のこれらのものが悪いとは言っていないということです。私が言っているのは、これらは異なる構築方法であり、現在私たちが持っている用語は、これらの異なるものの間の違いを十分に説明していないということです。
コメントで誰かがより良い用語を思いついてくれることを願っています。そして、このビデオのコメントをたくさんチェックして、誰かがこれらのものを分離するためのより良いものを持っているかどうかを確認します。しかし、これらの間に明確な線を描く方法が本当に欲しいです。私はどちらにも「フルスタック」が正しい用語だとは思いません。
ここ左側に何か、ここ右側に何かが欲しいですが、また、こちら側にもさらに成長する余地があるという事実も考慮してください。MVCを使用しないこれらの1つも見てみたいと思いますが、それは別の日の夢です。
これについてはもう何もありません。「フルスタック」という用語を理解し、なぜ私がもはやそれが好きではないのかを理解するのに役立つことを願っています。あなたがどう思うか教えてください。そして、より良い用語を思いつくのを手伝ってください。
コメント