Postgresqlストアドプロシージャを呼び出すクライアント側Javascript

Question

私はデータベースとしてPostgresqlを持つデスクトップアプリケーションを持っています。ビジネスロジックは主にストアドプロシージャ内にあります。したがって、ストアドプロシージャはデスクトップアプリケーション用のAPIとして機能します。

ここでは、ユーザーが携帯端末でアプリを実行できるように、アプリのサブセットのウェブベースのバージョンを作成したいと考えています。しかし、クライアントサイドのJavaScriptはデータベースに直接アクセスすることができないので、HTTP Webサービスを開発する必要があります。これはLANアプリケーションなので、私は、通常のWeb APIを開発して、最大5人のユーザーが消費するのは過度だと思います。だから私は、JavaScriptを使ってHTTP経由で送られてきたストアドプロシージャー文字列を解析し、JSON形式のテーブルを返すWebサービスを作ることを考えています。ここで

は、それが動作する方法は次のとおりです。Webブラウザ+ Javascriptを - > Webサービス - > DB +ストアドプロシージャ

このフォーマットを使用してWebサービスの文字列に渡すクライアント側のJavaScript：

storproc_name; dbtype1, arg1; dbtype2, arg2; dbtype3, arg3; ... and so on 

を

Webサービスがに文字列を解析します

storproc_name(arg1, arg2, arg3, ...) 

とJSONメッセージを返します。

を

{ 
    { 
     { column_name: value} 
     { column_name: value} 
     { ... } 
    } 
    { 
     ... 
    } 
} 

例：Webサービスによって解析

fn_login; varchar(32), admin; varchar(50), password; 

へ：

fn_login('admin', 'password') 

戻るこれ：

{ 
    { 
     { code: 1 } 
     { session_token: 'theusertokenusedtoaccessotherstoredprocedures' } 
    } 
} 

し、ユーザーがセッションに他の操作を行うことができますトークン

fn_list_products_by_category_id; varchar(50), theusertokenusedtoaccessotherstoredprocedures; integer, 2; 

fn_list_products_by_category_id('theusertokenusedtoaccessotherstoredprocedures', 2) 

{ 
    { 
     { product_id: 101 } 
     { product_name: "book" } 
    } 
    { 
     ... 
    } 
} 

私はこれが非標準的な方法であることを知っています。私はこのアプローチに明らかな落とし穴は見られません。しかし、どんなインプットも高く評価されます。

Answer 1

がhttps://github.com/brianc/node-postgres.git

--edit--

を見てください、それは、サーバー側であるが、あなたは本当にも、そのLANアプリ場合は、クライアント上の接続の資格情報を望んでいません。 node-Postgres（見る人がたくさんあります）のようなものでは、あなたのクライアントは単にあなたのdbサーバにhttpリクエストを出さなければなりません。これにより、「ストアドプロシージャ文字列を解析する」という手間が省け、手動ですべてを設定しようとします。私は数ヶ月前に同様のもので遊んでいたし、コンセプトの証明で協力した：https://github.com/OrlandoPg/listen-notify。それはあなたがしたいことではありませんが、それを出発点として使用すれば、あなたは非常に迅速に目標を達成することができます。

1）ご使用のDBサーバーまたはdbに接続する接続プーラーにノードおよび依存関係をインストールします。 2）ノードサービスを設定して、すべてのSP呼び出しをプロキシします。 3）クライアントからの照会と結果の処理。

Nodeとsocket.ioは、必要な場合は認証を含め、すべての配管工事を担当します。私のように単一のリスニングクエリを発行する代わりに、イベント名などに基づいてストアドプロシージャを実行することができます。このようなアプローチは、クライアント側のコードを大幅に軽くし、クライアント側のすべてを行うよりもセキュリティリスクが低くなると考えています。