Drupalにリモートデータ構造を統合するためのいくつかの戦略を見てきました。特定のモジュールが安定し、ユースケースが試されたため、戦略は進化しているようです。

REST APIを介して公開されるいくつかのデータ型（market、market_hours、vender、stall、produce）などで表されるデータ構造「ファーマーズマーケット」があるとします。外部サービスのIDはDrupalで関連付ける必要があります。つまり、「market」をロードするときに、「market_hours」と「stall」からデータを取得する必要があります。それを定期的に同期されるDrupalの読み取り専用コンテンツとして表現するための最良の方法は何でしょうか？

私はこれを次の基準で評価しようとしています：

Drupalのデータ構造：

ノードとカスタムエンティティ

私が見たWebサービスに関連するいくつかのシナリオでは、カスタムエンティティを使用しています。CRUD操作を簡素化します。ただし、これらのアイテムは一般に表示されるという点で「コンテンツ」です。

ストレージ（ローカルvsリモート）：

サービスがリモートエンティティとして読み込まれる例をいくつか見てきました。このモジュールはhttps://drupal.org/project/wsdataのライブラリを作成します。これは最も魅力的に聞こえますが、多くのユースケースは見ていません。カスタムコードの例もあります：https : //drupal.org/sandbox/fago/1493180

データの同期：

フィードvs移行vsグズルvs「Webサービスクライアント」vs「Webサービスデータ」

いくつかのオプションがあります。フィードでエンティティがサポートされるようになりました。特にカスタムシナリオの場合、移行はフィードよりもずっとクリーンに見えます。また、リモートサービスとの同期を取得するためにguzzleクライアントを使用している人々も目にしました。 inc＃l273。また、WSクライアントモジュールhttps://drupal.org/project/wsclientが、レストクライアントとして特別に作成されたオプションを提供していることにも気付きました。Webサービスデータはサービスから直接読み込まれ、ローカルにキャッシュされます。

ご意見をお寄せいただきありがとうございます。

1.質問を再定式化する

あなたの例は、データがDrupal側でのみ読み取られ、一方向の同期のみであると示唆しています。ローカルキャッシングがDrupalデータベースのエンティティになったとしても、実装するソリューションは実際にはリモートストレージ、同期、ローカルキャッシングのバリアントになるため、これはここで検討する最も重要な要素だと思います。

したがって、「ローカルストレージとリモートストレージ」ではなく、次のような疑問が生じます。

• データをローカルでキャッシュする必要があります。
• データを実際のエンティティとしてキャッシュし、フィード（または同様のもの）を使用してデータを定期的に同期する必要があります。または
• 同期とキャッシングを提供するカスタムメイドのモジュールを使用する必要があります。

興味のある記事は、「Drupal 7のリモートエンティティ」にあります。

2.データをキャッシュする

一般に、データをキャッシュすることは良い考えです：

• 他のサービスの停止、または接続のタ​​イムアウトから保護されます。

• Drupalデータベースにデータが存在すると、操作が高速化されます。

• Drupalデータベースにデータが存在することは、ビューなどの他のモジュールと統合される可能性が高くなることを意味します（これは保証されません）。

データをキャッシュしない唯一の利点は、古くなったデータを取得しないことです。これは、場合によっては望ましいことです。古くなったデータではなく、データを表示しない方が望ましい場合もあります。これは、あなたが挙げた例ではメリットとは言えないので、ローカルキャッシュを使用するソリューションに焦点を当てます。

3.ローカルエンティティ+同期

ローカルエンティティを用意して自分で同期するオプションを選択すると、元の質問に戻ります。

• ノードまたはカスタムエンティティを使用する必要があります。

• 同期に最適なモジュール。

3.1ノードとカスタムエンティティ

• 正確にノードとは何かの定義は、非常にオープンなものです。ノードのドキュメントページは、ノードがサイトに「保存」される「投稿」であることを示唆しています-どちらもデータに適用されません。

• Drupal開発者として、何かがノードであれば、サイト自体でそれを操作できるはずだと思います。

• Drupalユーザーとして、同様にノードを編集できることを期待します。

• このDrupal 8の問題https://drupal.org/node/2019031は、「読み取り専用」の概念は、バンドルレベルではなくエンティティレベルで適用される概念であることを示唆しています。これが実装された場合、このルートをたどったことにより、その恩恵を受けることができます。

要約すると、データは読み取り専用でリモートに保存されるため、カスタムエンティティタイプを使用してデータを表す方が理にかなっています。

3.2同期

2番目の部分では、このための2つの主要モジュールは、ご提案のとおり、FeedsとMigrateです。

FeedsとMigrateの違いは、Feedrateはコンテンツを定期的にインポートするために構築されているのに対し、Migrateはコンテンツをある場所から別の場所に1回だけ移植するために構築されていることです。Migrateは既存のデータの更新をサポートしていますが、両方のモジュールが十分にサポートされていることを考えると、当面のタスク用にビルドされたモジュールを使用する方が理にかなっています。フィードの方が適しています。

両方のモジュールを自分で使用した（同期のためのフィード、移行のための移行）私は、フィードが移行よりも厄介だとは思いません。サイト全体を移行することは、単一のコンテンツタイプをインポートするよりも複雑であるため、私の経験では移行により多くのカスタムコードが必要になったため、比較するのは困難です。

4.リモートストレージ、同期+キャッシュ用のカスタムモジュール

このタスクに役立つモジュールがいくつかあります。

あなたはウェブサービスのデータモジュールに言及し、他の人はデータモジュールに言及しました。考慮すべきもう1つのオプションは、リモートエンティティAPIモジュールです。私が経験した唯一のものはデータモジュールであることに注意してください。

• Webサービスデータモジュールにはまだリリースがありません。コードがまだ安定していない、APIが変更されているなどの可能性があります。（そのプロジェクトページによると）エンティティフィールドクエリはサポートされていません。コードリポジトリをすばやく参照しても、ビューがサポートされているという証拠はありません。そのため、ビューを使用してエンティティを表示することはできません。

• 私の経験では、Dataモジュールは、テーブルにデータがあり、それをビューに公開したい非開発者向けです。Drupal 6バージョンを使用するのは非常に苛立たしいことがわかりました。ただし、それ以降は変更されている可能性があります。

• リモートエンティティAPIモジュールは非常に有望に聞こえます。リモートエンティティのフェッチとキャッシュをサポートし、ビューをサポートしています。これはアルファ版リリースのみです-したがって、APIは変更される可能性があります。一見、エンティティフィールドクエリもサポートされていないようで、1種類のリモートサービスしかサポートしていないため、独自のサービスを実装する必要があります。

結論

どのリモートストレージモジュールもエンティティフィールドクエリをサポートしていないため、実際のエンティティ+フィードを使用することが、Drupalサイトとの最適な統合を実現するソリューションです。

ビューのサポートが十分であり、エンティティフィールドクエリを介して他のモジュールとの統合の可能性を心配していない場合は、リモートエンティティAPIを使用する方法が考えられます。ただし、独自のリモートインターフェースを実装する必要があります。

ビュー、ルール、トークン、クッドフック、検索API、およびシステムの統合が間違いなく必要な場合、それらはノードとは見なされませんが、データベースに「エンティティID」と「外部ID」関係と、「エンティティプロパティ」にカプセル化された取得情報呼び出し。最後に、データを同期するために選択したツールが何であれ、私はそれをcronキューで処理します。

データを時間どおりに取得して公開する必要がある場合は、外部データを取得するためのインターフェイスクラスを作成し、「ファーマーズマーケット」構造から情報を取得するクラスを使用してこのインターフェイスを実装することをお勧めします。

よろしく

デフォルトのデータベースエンジン以外のプラグイン可能なストレージバックエンドを可能にするField Storage APIがあります。