SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Remixを通じてWebを学ぶ

Remixで古き良き通信体験を取り戻そう──データ取得とデータ更新について解説

Remixを通じてWebを学ぶ 第4回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 Remixは気持ちのよい開発体験を目指しつつも、Web標準で十分に良い体験が得られるものについてはWeb標準に寄り添うフレームワークです。本記事では、サーバーに対してデータを送受信する処理について解説しながら、Web標準にも触れていきます。

  • X ポスト
  • このエントリーをはてなブックマークに追加

対象読者

  • Reactの基本を修めている方
  • 通信回線が弱いユーザーにも高速に表示できるサイトを作りたいエンジニア
  • WebブラウザとNode.jsという異なるランタイムをそれぞれキャッチアップするのが辛くなってきたエンジニア

前提環境

 筆者の検証環境は以下の通りです。

  • macOS Ventura 13.4.1
  • Node.js 20.4.0
  • NPM 9.7.2
  • Remix 1.18.1

Webサイトと通信の歴史

 これまでの連載で、Remixの基本的な考え方や、頻出する使い方について解説してきました。今回からは、個別の機能にフォーカスして解説していきます。今回は、通信に関する機能の解説として、データ取得とデータ更新について解説します。

 さて、Web標準とプログレッシブエンハンスメントを大切にするRemixは、通信においても可能な限り、ブラウザの基礎的な機能に肉付けする形でユーザー体験をよくするための機能を作り込んでいます。そのため、Remixの挙動を理解するには、ブラウザとサーバーの古き良き基礎的な関係を学ぶことが重要です。順番に見ていきましょう。

1998年のWeb

 まずは、20世紀末、1998年ごろのWebにおける通信がどんなものだったかを見てみましょう。ちなみに1998年を選んだのは、JavaScriptが非同期通信を行うための機能である XMLHttpRequest が生まれたのが1998年頃である説があり、ブラウザが最も素朴な通信方式を採用していた最後の時代だからです。Remixのドキュメント内でも、Remixで実装できる最も素朴なデータ送信環境について「ようこそ1998年へ(Welcome to 1998.)」というジョークが記載されています。

 さて、この時代のWebについて、システム的な特徴を確認してみましょう。1998年には、Webサーバーが別の言語に処理を委譲して動的にHTMLを生成する仕組みである、CGIが整備されていました。つまり、あるページ表示のリクエストに対して、データベースに保存されているデータを動的に埋め込んだHTMLをレスポンスとして返し、表示することができました(図1)。

図1:動的なWebページを表示するイメージ図
図1:動的なWebページを表示するイメージ図

 その一方で、ブラウザにはまだJavaScriptで動的に通信する仕組みは無かったため、ユーザーによる操作の結果をサーバーに伝えるには、<form> 要素によるsubmit処理を行うしかありませんでした(図2)。

図2:フォームによるデータ送信のイメージ
図2:フォームによるデータ送信のイメージ

 submit処理の後には、新しいデータを表示したいですよね。シングルページアプリケーションの時代であれば、レスポンスデータを使って動的に画面を更新して、となるところですが、1998年のブラウザにそんなことはできません。

 では、どうやって最新のデータを表示していたのかと言うと、図2の③にある通り、submitの完了後に自動でページをリロードするのがデフォルトの挙動だったのです。JavaScriptランタイムから見れば、サーバーへのデータ送信が1回発生するごとにシステムが再起動して、あらゆるものがやり直しになる挙動なので、当時のJavaScriptがどれだけ不遇だったのかがわかりますね。

[コラム]preventDefaultが妨げていたもの

 シングルページアプリケーションでフォームのsubmit処理をハンドリングしたことがある人であれば、Event.preventDefault()というAPIに見覚えがあるのではないでしょうか。読んで字のごとく、デフォルトの挙動が発生しないように妨げるためのAPIです。

 このAPIがフォームのsubmit後に妨げていた「デフォルトの挙動」こそが、前述した、ページのリロードなのでした。JavaScriptのメモリ内情報を継続させることでリッチな動作を可能にしているシングルページアプリケーションで、ページのリロードが発生するのは致命的なことです。ブラウザの標準の挙動とアプリケーションとしての動作の自然さの合間で、折り合いをつけるために preventDefault() は実行されていたわけですね。

Ajaxでアプリケーションとして振る舞えるようになったWeb

 1998年ごろにInternet Explorerが独自実装する形で、JavaScriptが非同期通信を行うためのAPIである XMLHttpRequest が発明されました。その後、後追いで標準化される形で他のブラウザにも実装され、非同期通信に関する機能は2005年からAjax(エイジャックス)と呼ばれるようになりました。

 その後、UIの状態管理とDOMツリーの更新を得意とする、Reactのようなフレームワークと組み合わせることで、シングルページアプリケーションと呼ばれるWebサイトが構築できるようになりました(図3)。

図3:シングルページアプリケーションのイメージ
図3:シングルページアプリケーションのイメージ

 一度HTMLを表示したら、そのあとはブラウザ側で動的にAPIサーバーと通信を行い、その結果を使って動的に画面を更新し、基本的にHTMLとしてはリロードしないままで情報が描き変わっていきます。リロードが発生しないことで、JavaScriptのメモリ内の情報が継続するため、リッチかつスムーズなUIが作成しやすくなりました。

シングルページアプリケーションの通信の課題

 ただ、何年かこの方式が流行った後に、課題も浮き彫りになってきました。その一つとして、APIサーバーの設計次第で、ブラウザからの通信回数が多くなることが挙げられます。

 理想的には、1つのユーザーアクション(画面表示やデータ送信)に対して画面を構築するために必要な通信の回数が1回で済むAPIサーバーを設計したいですよね。しかし、メンテナンスコストなどの事情から、データベースのテーブルと1対1で対応したエンドポイントを持つREST APIを設計してしまうことも少なくないでしょう。そういった場合、1つのユーザーアクションに対して、数回から場合によっては10回以上の通信を行わないと、画面を構築するためのデータが用意できないかもしれません。

 ここはソフトウェアエンジニアの悪い癖で、まあ10回くらいなら大した時間ではないだろう、と考えてしまいがちなのですが、この判断には悪いバイアスがかかっています。ソフトウェアエンジニアの労働環境に整備されているインターネットは、世間一般から見ると高速な部類に入りがちなのを忘れているのです。

 ユーザーは、そのWebサイトを、さほど高速ではない通信キャリアのモバイル通信回線で、スマートフォンから見ているかもしれません。パソコンから見ているのだとしても、固定回線ではなくモバイルルーターを据え置き型にした、事実上のモバイル通信回線でアクセスしているのかもしれません。何にせよ、ソフトウェアエンジニアのデバッグ中の体感速度よりも、ユーザーは遥かに遅い通信回線で、画面のローディングUIを長時間眺めているケースは、少なからず存在していると思っておいたほうがよいでしょう。

 大きいサイズのデータを取得することも、高頻度の通信を行うことも、どちらもユーザー体験を損ないます。そして、ユーザーのネットワーク環境は、自社で契約しているサーバーと違い、多少のお金をかけた程度では改善することは困難です。通信の回数を減らすこと、通信のサイズを減らすことは、Webサービスの提供者にとっても大きな関心ごとになってきているのです。

 また、副次的な話題ではありますが、開発体験の観点でも問題があります。一般論として、非同期処理は扱いが少し難しいものです。Promiseやasync/await構文などによって、扱いやすくなってきたものの、やはり10回以上の非同期通信の結果を、適切に待ち合わせてUIへ反映する処理を組み立てる作業は、開発者の脳を酷使します。

 ユーザー体験や開発体験を向上するためには、ブラウザが行う通信の回数やサイズを減らせる仕組みが必要になってきているのです。

次のページ
Remixが再定義するWeb

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Remixを通じてWebを学ぶ連載記事一覧

もっと読む

この記事の著者

WINGSプロジェクト 中川幸哉(ナカガワユキヤ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書記事多数。 RSS X: @WingsPro_info(公式)、@WingsPro_info/wings(メンバーリスト) Facebook

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/18232 2023/09/06 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング