フレームワークについてはコメントできません。
あなたはすでに、これの主な弱点、特にインターネット上でのセキュリティであることに言及しました。問題は認証だけではありません。問題は基本的に、クライアント (この場合は Web ブラウザー) のオープン性と、プロトコル (特に JSON や XML を使用した HTTP、またはその他のプレーンテキスト プロトコル) にあります。
一例を考えてみましょう。とても簡単です。SQL クエリを受け取り、行を表す JSON のコレクションを返す HTTP サービスを想像してみてください。これは簡単に書くことができます。RDBMS への SQL アクセスを可能にする任意のツールを使用して、最初から 1 時間もかからずに初期のものを打ち出すことができます。
ほぼ間違いなく、クライアント サーバー開発の黄金時代にさかのぼると、これはまさに人々が行ったことであり、HTTP を介してトンネリングされた一部のデータの代わりに、DB 固有のドライバーを使用し、SQL テキストを DB の背後に直接送信しました。
今日の問題は、プロトコルがオープンすぎることです。上記の SQL サービスを実装すると、基本的にアプリケーション全体が SQL インジェクション ベクトルになります。
そのようなものを野生で確保することはできません。このプロトコルは、アプリケーションのすべてのソース コードとともに、簡単に観察することができます (すべてのブラウザには、事実上、パケット スニファが組み込まれています)。データを暗号化しようとする場合、それはすべてクライアント上で行われます。プロセスへのソースと関連するすべてのキーが含まれます。
たとえば、CouchDB はこの方法では保護できません。サーバーに対する権利を持っている人は、すべてのデータに対する権利を持っています。すべてのデータ。見せたいものと見せたくないもの。
当然のことながら、ソリューションはサービス層です。単なる生データ ストリームよりも高いレベルで話すもの。セキュリティで保護でき、クライアントから秘密を守ることができるもの。しかし、当然のことながら、それを可能にするにはサーバー側のプログラミングが必要であり、表面上はより多くの作業、より多くのレイヤー、より多くのデータ変換、より多くの苦痛を伴います。
昔は、DB 内のストアド プロシージャだけを使用してシステム全体を作成していました。プロシージャーには、それらを呼び出すユーザーが持っていない権限があるため、ユーザーが表示または変更できるもの、またはできないものをサーバーで制限できます。おそらく、制限されたビューで無制限の SELECT 機能を与えることができますが、ストアド プロシージャには、実際にデータを変更したり、非表示の列の一部にアクセスしたりする権限があります。
ストアド プロシージャは、ほとんどがアプリケーション レイヤーとアプリケーション サーバーに置き換えられ、DB はますます「ダム ストレージ」に追いやられています。しかし、コンセプトは似ています。
分析の例のように、データを直接 Web に公開するシナリオには価値があります。それは特定の、重いニッチを読んでいます。しかし、それを超えると、コンセプトがうまく機能しないのではないかと心配しています。難読化された JS は読みにくいですが、安全ではありません。
これが、そのようなフレームワークを見つけるのが少し難しい理由かもしれません (私自身はまったく見ていません)。