2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

JSP/Servlet時代からのエンジニアの現代Web開発大迷走記

Posted at

はじめに

どうも。JSP/Servletで自作DAOをゴリゴリ書き、オンプレサーバーのラックの匂いを嗅いでその横で夜間障害対応ごに爆睡していた、自称フルスタックエンジニアです。

Javaの世界を離れた後は、情シスとして転職し、会社が借りているレンタルサーバー上で動くPHPをメインに、自作フレームワークで社内システムを開発してきました。ほんの15年前、Tomcatのログを追いかけたり、MVCフレームワークを自作したりしていたあの頃が、今では遠い昔のように感じます。

そんな私が最近、モダンな猫の手道具箱でReact開発に触れお試しにとremix.jsやnext.jsにふれる機会があり、まるで浦島太郎のような気分を味わいました。この技術の進化はめまぐるしく、かつての常識が全く通用しない世界のようです。

これは、そんなロートルエンジニアが、過去の経験を携えながら現代Web開発の広大なマップを大迷走した、その旅の記録です。

第1章:司令塔の交代劇 - クライアントが主導権を握る時代

最初のカルチャーショックは、Webページの表示における「司令塔」が交代していたことでした。

  • 昔の常識(サーバーが司令塔): URLがリクエストされれば、サーバーが対応するファイルを返す。シンプル。
  • 今の常識(クライアントが司令塔): 一度Reactアプリが読み込まれると、History APIによってルーティングの主導権がクライアントサイド(React Router)に奪われる。サーバーに問い合わせることなく、アプリ内でURLが処理されてしまう。

ブラウザがサーバーの許可なくURLを書き換えてページ遷移をハンドリングできるなんて…。このクライアントサイドが主役というパラダイムシフトが、全ての混乱の始まりでした。

第2章:歴史は繰り返すのか? SSRへの回帰

SPAのクライアントサイドルーティングを理解したのも束の間、今度はNext.jsやRemixといったフレームワークが**SSR(サーバーサイドレンダリング)**を引っ提げて主流になっていると知ります。

「結局、昔のJSPやPHPと同じことをしているのでは?」

最初はそう思いました。しかし、これは単なる先祖返りではなく、「螺旋階段を登るような進化」だったのです。

  1. 第一世代 (SSR): SEOと初期表示は強いが、UXが悪い(画面がチラつく)。
  2. 第二世代 (SPA/CSR): UXは最高だが、SEOと初期表示に致命的な弱点があった。
  3. 第三世代 (Modern SSR): 初回アクセスはSSRでSEOと表示速度を担保し、その後の遷移はSPAとして動作する**「いいとこ取り」**。

かつての弱点を克服するための、合理的な進化でした。技術選定の前提知識として、この歴史的背景の理解が不可欠だと痛感しました。

第3章:コストの罠 モダンインフラの現実

「ならばRemixだ!」と意気揚々とVPSを契約し、いざ動かしてみると、今度はもっと現実的な壁にぶつかります。

  • メモリ消費量: Node.jsサーバーは「常駐」モデル。リクエストごとに処理が終われば消滅するPHPとは違い、メモリを食い続ける。安いVPSプランでは心もとない…。
  • 費用: 安価な共用レンタルサーバーの何倍ものコストがかかる。サーバー管理の手間もすべて自分持ち。

「ならばVercelのようなPaaSだ!」と舵を切れば、今度は次の罠が待ち構えていました。

「フロントエンドは安いけど、データベースどうするんだ…?うわ、高っ!」

フロントエンドPaaSは「ステートレス(状態を持たない)」だから安い。しかし、データベースは「ステートフル(状態を持つ)」だから本質的にコストがかかる。この分離によって、インフラ全体のコストが跳ね上がるという罠。この気づきには天を仰ぎました。

この複雑なコスト構造と隠れた管理タスクは、驚くべき流れを生み出しています。それは、大規模サービスにおいてはコストが予測しやすく、究極的に自由なオンプレミスへの回帰、そして多くのサイトでは、適切にチューニングされたPHPとレンタルサーバーの圧倒的なコストパフォーマンスが、全くもって合理的で現実的な選択肢として見直されている、という事実です。

第4章:生成AIが見せる未来(と過去)

この複雑怪奇なモダン開発も、生成AIの登場でまた変わっていくのでしょう。興味深いことに、AI支援でコードを書かせると、ある事実に気づきます。

「AIは、最新のRemixよりも、枯れたLaravelやJSの方が精度の高いコードを生成してくれる」

これは、AIが「学習データの量」に依存するからです。15年以上かけてインターネットに蓄積された膨大なコードや議論が、古い技術スタックをAIにとって得意科目にしているのです。

この事実は、未来のフレームワークが「AIに最適化された、より宣言的でシンプルな構造」へ進化していく可能性を示唆しているように思えます。

まとめ:現代における「フルスタタックエンジニア」という言葉の重み

この旅は、私にWeb開発の広大さと、フルスタックエンジニアという言葉の重みの変化を教えてくれました。

  • かつてのフルスタック: 一本道の技術スタック(LAMP, J2EE, SQLチューニング, SQLサーバーチューニング)を深く知ること。
  • 現代のフルスタック: 無数の技術選択肢のマップを読み解き、予算と要件に合わせて最適なルートを設計するアーキテクトであること。

Reactも、Remixも、VPSも、PaaSも、そして古き良きPHPやオンプレミスも、全てはそのマップ上の一つの地点に過ぎません。それぞれの長所と短所、そしてコストを理解し、プロジェクトにとって最適な組み合わせを選択する。その判断能力こそが、経験の価値なのだと信じています。

学習コストは本当に大変です。しかし、この複雑で変化の激しい世界で、それでも全体を俯瞰しようともがくこと自体が、エンジニアとしての面白さなのかもしれませんね。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?