React Server Componentsに感じたフロントエンドの消失

はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで

[joker1007]

概ね同意するんですが、製品レベルでクライアントから直接DBを参照するのが主流になることは流石に無いだろうと思っている。そんな安全にDB設計及び参照設計が出来る程人間は賢くない。

[programmablekinoko]

ウェブのフロントとバックの疎結合は回線上のHTTP対向で余儀なくされた疎結合で、プログラミングのメンタルモデルとしてはかなり不自然なので透過的にコンポーネントで機能分割をする方向にいくだろう

[ustam]

現状、FEはデザイン寄りとサーバー寄りに分かれていて、サーバー寄りのFEは元々BEから滲み出てきたような人たちじゃん。CSSを汚す人たち。BEへお帰り。デザイン寄りのFEは、これまで通りFEとして残る。

[hadakadenkyu]

ヤフージャパンでは伝統的にコントローラより手前をフロントと呼んでいて昔は変だと思っていたが今となっては先見の明があったんじゃないかと思い直した。

[kako-jun]

「フロントエンド==クライアント、バックエンド==サーバサイド」Reactの話をしてるのだから===にしてほしかった、と目Lintが反応してます

[teppeis]

この辺興味ある人はまず Isomorphic Survival Guide を読んでみるのがおすすめ。フロントエンド/バックエンド、クライアント/サーバーについては2015年時点で整理されてる https://speakerdeck.com/koichik/isomorphic-survival-guide

[dev0000_1]

かつてのVBクラサバ時代ってクライアントでSQL記述できる一方、ストアド全盛だった気がする。

[foofuga]

前世紀のDCOM/RMIまで螺旋が戻ってる感じだな。技術の進歩と合わせれば感覚的にはありな気がする

[nakag0711]

クライアントアプリが一種類で済むのかどうかという観点もある

[for-my-internet-demo]

おもしろい文章だった。疎結合派閥のI/oでしょうもない楽すんじゃねーよおじさんですが推移は見守る

[YassLab]

“疎結合の方が拡張性や保守性は高いのですが基本的にめんどくさいので 分業不要な規模でかつ性能問題が無い ならば常に密結合を選んできたのが人類”

[ducktoon]

フロントエンドエンジニアと名乗る人が続出して、フロントしかできん、しない、専門？ ってどゆこと？？？ ってずっと思ってたので共感が多かった

[berlysia]

“最近のFFBやSSRの流れを見てインフラを境界にするのは合ってないなと思い 「フロントエンドはプレゼンテーション、バックエンドはビジネスロジック」 と認識を改めてた”

[surume000]

分かる

[uehaj]

"React Server ComponentsやBlitz.jsが普及すればフロント領域とかフロントエンドエンジニア という言葉も無くなる"

[knjname]

ブラウザで実質的にJavaScript以外動かない以上、Javaがこれの代わりになるとかは今のタイミングでは無理だと思ってる。

[minamishinji]

面白そう。

[progfay]

"少なくとも私の思っていた 「フロントエンドエンジニア」 というロールは無いあるいは最前線には居ない"

[diveintounlimit]

zennにもポエムが投下されるようになったか

[NOV1975]

ユースケースがはっきりしないとなんともって話ではあるよね

[baronhorse]

JSでバックエンドとか苦行だわ

[kazuau]

最近はそんな感じなのは知ってるんだけど、クライアント-サーバー-バックエンドの3層で発想しちゃうのでバックエンドの役割用語定義がぶつかっちゃう。

[Keisuke69]

同意するしないは置いておいて色々考える人がいるんだなーと。技術についてこういう視点から物事考察できるようになってみたい

[t-murachi]

フロントとバックを分ける意味合いが希薄しているってのはわかるけど、じゃあRoRで良いじゃん、ってのは流石に乱暴だと思う(´・ω・`)。少なくともパフォーマンスに対する考え方は随分と変遷しとるような…(´・ω・`)

[youko03]

名文の数々。

[hatsuett]

ふ

[yoiIT]

“フロントエンドとバックエンドの境界なんてどうでも良いのです。UIの記述性が高くロジックも問題なく書けるReact/Vue.jsを使って 「ビジネスロジックも書いてしまった方が効率的」 。このくらいの感覚”

[otherworld]

コンポーネント指向なのでサーバサイドとかクライアントサイドのような特定の技術的なレイヤーを対象にしたものではなくて、コンポーネントという考えで抽象化できるものがスコープという認識。iframeみたいに

[proverb]

例の人の記事が参照されてるだけで不快感ある…

[sgo2]

webはちょっと噛じっただけの組込み屋だけど、最近は組込み分野でもwebサーバ搭載するケース(当然サーバよりクライアントの方が遥かに高性能)が出てきてる事も視野に入れた方が良いかと。

[ryoma_robo]

“最初はスタートアップで密結合なシステムを作り、その会社が業界のリーダーポジション程に大きくなったころに性能問題か分業体制強化のために疎結合システムに移行して成功。他の会社も近いステージの会社が増えて

[takezaki]

“GraphQLも レガシーなインフラに対しての汎用的なラッパーという側面もあるんじゃないかと思っています。GraphQLもイマイチ使いどころが見えてなかったのでこの考え方にそうと結構しっくりくる”