私たちのチームは、ユーザーがデータの特定の部分を取得するために呼び出す特定のマイクロサービスや、それらを関連付けて組み合わせる方法を気にすることなく、単一のインターフェースを介して企業のドメインモデルにクエリを実行できるようにする単純な宣言型DSLを実装するという考えを持っています。
推奨される構文はSQLに基づいていますが、次のとおりです。
例:
_SELECT entityTypeOne.name, entityTypeTwo.value, entityTypeTwo.date
WHERE entityTypeOne.name LIKE 'Sample%'
AND entityTypeTwo.date BETWEEN (2015-05-01, 2015-05-31)
_
期待される結果:
_╔════════╦═══════╦════════════╗
║ name ║ value ║ date ║
╠════════╬═══════╬════════════╣
║ London ║ 1000 ║ 01/05/2015 ║
║ London ║ 2000 ║ 02/05/2015 ║
║ London ║ 3000 ║ 03/05/2015 ║
║ Moscow ║ 2000 ║ 02/05/2015 ║
║ Moscow ║ 9000 ║ 05/05/2015 ║
║ Tokyo ║ 1000 ║ 30/05/2015 ║
╚════════╩═══════╩════════════╝
_
基になるエンティティリレーションスキーマは、エンティティが次のように関連していることを認識しています。_entityTypeOne.id = entityTypeTwo.parentId
_暗黙的な結合を作成します。
「クエリエンジン」は、最初にサーバーに日付範囲フィルタリングを適用してentityTypeTwoマイクロサービスをクエリし、次にentityTypeOne以前のクエリの結果に基づいてidフィルタリングを適用するマイクロサービス。
現在確認されている問題:
これが既知の問題であり、チェックするアルゴリズム(グラフ理論からの何か)があるかどうか疑問に思っていましたか?
これは私がこれまでに見つけた最も近いものです:
それが物事をより単純にする場合、マイクロサービスがODataを介してデータを公開していると想定できます。
あなたがしようとしていることが多くのAPIへの単一のエンドポイントを提供している場合、Netflixの Falcor プロジェクトに何らかの価値があるかもしれません。
Falcorはクエリエンジンではありません。 「効率的なデータフェッチ」のためのライブラリです。これは、「 Demand Driven Architectures 」を提供するツールセットの増加の一例です。これは、クライアントツールの作成者が正規データに関連して必要なものを指定できるようにする、従来のRESTサービスの代替手段です。これにより、バックエンドと連携してUI(要求)を開発する必要がなくなります。 「フェッチ」ツールは、正規モデルを個々のレストサービスへの呼び出しに変換します。ブラウザ内キャッシュとリバースプロキシキャッシュの組み合わせにより、同じデータに対するデータサービスへの以降の呼び出しを回避することで、効率が向上します。
Falcorの筆頭著者Jafar Huseinを言い換えると、サービスグラフを個別のサービスの束ではなく、単一の大規模なJSONグラフドキュメントとして描きます。これが、ユーザーが要求していると感じていることです。Falcorは、効率化に必要なキャッシュ、バッチ処理、ルーティングを処理します。
これらのツールがSELECTおよびWHERE句の動作をREST APIのコレクションにもたらすかのようです。そして、それはRESTの上に効率的なクエリAPIを構築することとはまったく同じではありませんが、同じ利点-率直に言うと数年かかる可能性のある効率的なクエリプロセッサを発明する必要がありません。