データベースを構築するのをやめよう

 (sqlsync.dev)
5 ポイント 投稿者 GN⁺ 2023-12-02 | 1件のコメント | WhatsAppで共有

データ管理の複雑さ

  • フロントエンドエンジニアは、APIデータをキャッシュする必要性に気づくようになる。
  • 最初は単純なデータ保存から始まるが、機能要望が増えるにつれて、データキャッシュ、手動インデックス、楽観的ミューテーション（optimistic mutations）、再帰的なキャッシュ無効化などを実装することになる。
  • これらの機能はデータベースの内部動作に似ており、複雑なフロントエンドアプリケーションでは、結局ドメイン特化型のデータベースを作ることになる。

キャッシュの基本

  • APIリクエストの結果をローカル変数に保存することから始まる。
  • 宣言的フレームワークを使うWebアプリケーションでは、不要なAPIリクエストを防ぐためにデータを変数に保存する。
  • キャッシュをより高いレイヤーに移したり、UIツリーの外部に移動したりすることが次の段階となる。

インデックスによる高速化

  • データを特定の方法で整理することで、アプリケーションの作業を減らし、ユーザー体験を向上させられる。
  • フロントエンドのデータ最適化が、データベースストレージの内部動作に似ていることに気づく。
  • IDごとにデータを保存し、日付ごとに項目を素早く取得できるインデックスを作成して、データ構造を改善する。

楽観的ミューテーション

  • サーバーの応答を待たずに、ローカルで特定の操作の効果をシミュレートすること。
  • ユーザーインターフェースが即座に反応しているように見せられるが、サーバーと異なる結果になった場合は、UIが変更をロールバックしなければならない。
  • クライアントとサーバー間でロジックを複製すること、非同期エラーを処理すること、アプリケーションの再起動をまたいで変更を調整することなどの課題がある。

再帰的なキャッシュ無効化

  • データはキャッシュの複数箇所に現れるため、更新後にサーバーと一致するようキャッシュを正しく無効化する必要がある。
  • UIは、キャッシュのどの部分が各ミューテーションに関連しているかを把握していなければならず、これは規模が大きくなるほど脆くなりうる。
  • 楽観的ミューテーションと組み合わせると、クライアント側でサーバー変更を予測するためにサーバーロジックを複製することがさらに難しくなる。

データベースを構築中？

  • 十分に複雑なフロントエンドアプリケーションでは、結局多くのデータ管理機能を自前で構築することになり、その結果、ユーザーを喜ばせビジネス課題を解決するための時間が奪われる。
  • フロントエンドに最適化されたデータベーススタックという代替案を提示する。

SQLSync の紹介

  • SQLiteをベースにした、フロントエンドに最適化されたデータベーススタックであるSQLSyncを開発した。
  • SQLSyncは、データ管理の問題を解決し、開発者がアプリケーション独自の機能に集中できるよう設計されている。
  • SQLSyncは、耐久性のあるキャッシュ、SQLiteのフル機能、楽観的ミューテーション、スマートなキャッシュ無効化、リアクティブクエリを提供する。

GN⁺の意見

この記事で最も重要なのは、フロントエンドアプリケーションの複雑さが増すにつれて、開発者がデータベースに似た機能を自前で実装するようになる現象です。こうした作業は開発者の時間を消耗させ、実際にユーザーへ価値を提供する機能開発から遠ざけてしまいます。SQLSyncのようなフロントエンド最適化データベーススタックは、こうした問題を解決しようとする革新的なアプローチを提示しています。この記事が興味深いのは、既存のデータ管理方式にある根本的な問題を指摘し、開発者がより効率的に作業できる新しい解決策を模索している点です。

関連記事

1件のコメント

 
GN⁺ 2023-12-02
Hacker News の意見

  • プロジェクト制作者である友人への理解

    • SQLsync は、フロントエンド開発者がブラウザ内でリモートデータベースをクエリし、更新できるようにするツール。
    • WASM の力を使って SQLite データベースをブラウザへ転送する方式で動作する。
    • 複数クライアント間の同期のためにリアクティブなアルゴリズムを使用する。
    • 開発者のデータ同期作業を革新的に解決するアプローチ。

  • 過去の会社でのプロジェクト管理ソフトウェア経験

    • チェックイン／チェックアウトの仕組みでデータを同期していたが、リアルタイム更新アプリの登場により時代遅れと見なされるようになった。
    • 10年間 SPA Web アプリを構築してきた経験から、こうしたデータ同期メカニズムは時代を先取りしていたように感じる。

  • SPA を捨てれば消える問題

    • Hotwire や htmx のようなソリューションを使えばサーバークエリは単純化され、それを高速化する問題はよりよく理解されている。

  • SQLSync 制作者の意見

    • 多くの質問に答え、見落とした質問も定期的に確認する予定。
    • SQLSync を作った動機に焦点を当てた最初の投稿について議論できてうれしい。
    • 次の投稿では SQLSync の動作方式を説明する予定。

  • ユーザーに現実と異なるメンタルモデルを与えないこと

    • データベース同期はクライアント・サーバーモデルより複雑になり得る。
    • 高速な UI が必要なときは、CRDT の基本要素を使うほうが安全だと感じる。

  • 測定できるものは管理されるという原則とサンクコストの誤謬

    • データベースの複雑さが問題。
    • SQL の構文が問題であり、基本的なリレーショナルデータベースの利用が快適な体験であれば、独自データベースを作る代わりに DB を使いたくなる誘惑が強まるだろう。
    • 優れたデータベースは SQL を使い、効率のためにはデータベース言語を使う必要がある。

  • クライアントとサーバー間の状態同期の問題

    • PHP/SSR モデルに戻れば、UX を犠牲にすることで問題を回避できる。
    • SPA は良いが、multipart フォーム投稿も依然として機能する。
    • すべての状態をサーバーに置き、クライアントを単純なターミナルとして扱うことが開発体験を向上させる。

  • ORM ライブラリとの比較

    • ブラウザ対応の TypeORM と SQL.js を直接使う場合と SQLsync を比較する質問。

  • フロントエンドとバックエンドのデータベースの違い

    • フロントエンドのデータベースはバックエンドとは異なる可能性があり、クライアント側でリアルタイム状態をより適切に管理する必要がある。
    • react query と WebSocket を使ってキャッシュ無効化を検討中。
    • SQLsync のアイデアも検討する価値がある。

  • SignalDB による類似の試み

    • SignalDB は、シグナルを使ったリアクティブ性と、フレームワーク非依存の MongoDB に似たクエリ構文を使用する。