LiveView、Svelteと最も相性の良い技術

 (blog.sequin.io)
2 ポイント 投稿者 GN⁺ 2024-04-05 | 1件のコメント | WhatsAppで共有

LiveViewとSvelteの組み合わせ

  • LiveViewは、Webアプリケーションを構築する独特な方法を提供する。
  • サーバーが状態を保持し、フロントエンドの動作をバックエンドで処理して、DOMを段階的に更新する。
  • SPAの複雑さは分散システムの複雑さに起因しており、LiveViewはフロントエンドのマイクロサービスなしでリッチなクライアント体験を提供する。

LiveViewの難しい点

  • クライアント側の状態は避けられず、サーバーとユーザー間のレイテンシも回避できない。
  • LiveViewは多くのDOM変更をサーバーが担うが、すべてを制御できるわけではない。
  • LiveViewには、LiveViews、LiveComponents、Componentsの3種類のコンポーネントがある。
  • LiveViewとLiveComponentsの間でのリファクタリングは、予想以上に煩雑である。

LiveViewの曖昧な方向性

  • LiveViewは、しばしば何かが欠けているような感覚を与える。
  • LiveViewは現代的なフロントエンドフレームワークと多くの共通点を持つが、その違いを認識し、問題に異なる方法で取り組む必要がある。

LiveView + Svelte

  • LiveSvelteは、LiveViewでSvelteコンポーネントをレンダリングできるようにする。
  • バックエンドがフロントエンドコンポーネントのpropsを制御し、フロントエンドとバックエンドの両方が状態を持つ。
  • フロントエンドとバックエンドの間には、プライベートで双方向の通信チャネルがある。

LiveSvelteの革新的な特性

  • バックエンドとフロントエンドの責任分担が明確で、複雑さはサーバー側に集中している。
  • LiveViewはバックエンドのためのフロントエンドとして最も真価を発揮し、フロントエンドコンポーネントをレンダリングして状態を維持するバックエンドプロセスを提供する。

GN⁺の見解

  • LiveViewとSvelteの組み合わせは、サーバーとクライアント間の状態管理を効率的に分離し、開発者がより速く直感的にアプリケーションを構築できるようにする。
  • この技術は、特にリアルタイムな相互作用が重要なWebアプリケーションで有用となる可能性があり、ユーザー体験の向上に寄与しうる。
  • ただし、サーバーとのレイテンシがユーザー体験に影響する可能性があるため、パフォーマンス最適化と地域ごとのサーバー配置が重要な検討事項となりうる。
  • LiveViewとSvelteの組み合わせは、従来のSPA開発方式に慣れた開発者に新しいパラダイムを提示し、学習コストを下げて開発効率を高める可能性がある。
  • この技術が提供するリアルタイムな状態同期と双方向通信は、特にコラボレーションツール、ダッシュボード、またはリアルタイムデータを扱うアプリケーションにとって魅力的な選択肢となりうる。

関連記事

1件のコメント

 
GN⁺ 2024-04-05
Hacker Newsのコメント

  • マルチプレイヤーのビデオゲームで使われるパターンのひとつは、クライアントとサーバーの両方で基本的に実行されるコードがあること。

    • クライアント側のコードは、サーバーの状態を予測して実行される。
    • サーバーの状態を受信したら、クライアントの状態を強制的に適用する。
    • ゲームにおける「予測」は適切な表現で、クライアントは入力の結果をかなりうまく推測できるが、他のプレイヤーの入力はわからないため確実ではない。
    • このパラダイムは、公式なサーバー状態を待つあいだにクライアント入力へ即座に反応するためにも使える（例: ドロップダウンの有効化/無効化、ローディングスピナーの表示）。
    • サーバーでは実行されないクライアント状態も多い（例: パーティクルシステム、ラグドール - 全クライアントで正確に同じである必要がなく、他プレイヤーの入力や物理と相互作用しないもの）。

  • LiveViewとSvelteを組み合わせる方法について ElixirConf 2022 で発表したことがあり、live_svelte のコントリビューターたちがそれを現実のものにするのに貢献した。

    • クライアント側の状態は、特にリッチなUXを持つアプリでは常に必要になる。
    • ニューヨーク市では、特に移動中はネットワーク接続が保証されない。
    • Phoenix の pubsub を使って、他サーバーで発生したサーバー側状態の変更をクライアントへリアクティブにプッシュできるのは非常に強力。

  • 新しい行が入ると LiveView がクライアントを更新するので、テーブルにプッシュするだけでよい。

    • ただし、対話的な行がある業務アプリではこの方法を使わないことを勧める。
    • ユーザーが誤ったものをクリックしたり、誤った顧客にメールを送ったり、誤った取引を払い戻したりするなどの認知的な遅延が起こりうる。
    • データが変更されたことを知らせるスティッキーバナーを使うか、緊急時にはスクロール位置を変えずに新しい行を追加するだけにするのがよいUX。

  • BeaconCMS では Svelte と LiveView を併用している。

    • クライアントでUIをより細かく制御したい場合には、良いユースケースがある。
    • Phoenix を使っていても、常に LiveView が答えとは限らず、静的レンダリングのページで十分なこともある。
    • 何事にもオール・オア・ナッシングで取り組まないよう助言する。
    • 記事が指摘しているように、「LiveView流」から外れるいくつかの良いユースケースがある。
    • 1000ms のラウンドトリップがあるなら別の考慮事項も出てくるが、地理的に近いサーバーをコストなどの理由で使えないこともあるため、クライアント側の状態管理を追加するのが解決策になりうる。

  • クライアントで状態を管理する代わりに、クライアントとサーバーの両方で状態を管理することになる。

    • これを改善と見るのは難しい。別のAPIを構築する必要がなくなるのは確かだが、だからといって改善されたとは言えない。

  • このアプローチの限界は光速にある。サーバーがユーザーにどれだけ近づけるかには限界がある。

    • 次のステップは、サーバーを WebAssembly にコンパイルしてクライアントへ送り、実際のサーバーから応答が返るまで楽観的にレスポンスをレンダリングすること。
    • 少し狂気じみて聞こえるかもしれないが、実際にプロジェクトでこれをうまく実現しており、魔法のような体験だった。

  • LiveSvelte の作者として、質問があれば知らせてほしいとのこと。

  • 一般に、このモデルでアプリを作りたかった。イベント指向、双方向のリアルタイム更新とサーバー、順序づけられたイベント、ローカルおよびリモート状態……

    • LiveView のことは知らず、Erlang 系言語も使ったことはなかったが、彼らは明らかに何かを掴んでいる。
    • 従来のリクエスト/レスポンスモデルは、一貫性や古いデータに関する問題を数多く引き起こす。
    • 希望的ではあるが、おそらく議論を呼ぶ考えとして、過去10年が主流言語にFPの概念を統合する時代だったのなら、次の10年は状態を持つメッセージ指向（リアクティブ？）プログラミングを主流のフルスタック全体へ統合する時代になってほしい。

  • アプリでは LiveView と一緒に再利用可能な Stimulus コントローラーを使っており、これもまたスムーズに動作している。

    • 一般に LiveView で構築するのは楽しいが、実際のシナリオで使うほど、ステートレスなHTTPフレームワークの利点をより強く実感する。
    • Hotwire のようなフレームワークは、より優れたパフォーマンスと再接続への耐性を提供し、ユーザーに近いサーバーを配置する必要性を避けられる。

  • すばらしいプロジェクト！ これについての Svelte Radio のエピソードをちょうど公開した。