GraphQL APIとのインタラクション
GraphQL APIとのインタラクションWordPressから別のPHPフレームワークまたはCMSへのアプリ移行

WordPressから別のPHPフレームワークまたはCMSへのアプリ移行

Gato GraphQLが提供するGraphQLスキーマには、WordPressのデータを取得するためのフィールドが含まれています:投稿、ユーザー、コメント、タグ、カテゴリーなど。

PHPリゾルバーがWordPressのデータを取得するコードはWordPressに依存しており、そのコードはWordPress以外のアプリでは実行できません。

しかし、Gato GraphQLでは、これらのリゾルバーはそれぞれ2つのパッケージで実装されています:

  1. 「バニラ」PHPのもの(汎用コードをすべて含む)
  2. WordPress固有のもの(そのリゾルバーを満たすWordPressメソッドへの実際の呼び出しを含む)

たとえば、次のGraphQLクエリでは:

{
  posts {
    id
    title
  }
}

...投稿を取得するロジックは次のように構成されています:

  1. Root.postsフィールド:汎用のpostsパッケージに存在します
  2. get_postsメソッドによるWordPress向けの解決:WordPress固有のposts-wpパッケージに存在します。

非WordPress/WordPressパッケージ間のコード分割はおよそ80/20%であり、コードの80%は別のフレームワーク/CMSでも再利用可能で、再実装が必要なのはコードの20%のみです。

さらに、Gato GraphQLのすべての機能はモジュールを通じて提供されており、モジュールは自由に有効化・無効化できます。

スキーマモジュール
スキーマモジュール

モジュールはセキュリティ目的で実装された機能です:パブリックAPIでユーザーデータを公開する必要がない場合は、Usersモジュールを無効化することで、対応するフィールド(Root.usersなど)がスキーマに追加されることはありません。

モジュールは基盤となるPHPパッケージに直接マッピングされています。 そのため、Gato GraphQLをスタンドアロンアプリとして実行する場合、必要なモジュール/パッケージだけを選択的に読み込み、それ以外は読み込まないようにできます。

たとえば、アプリケーションが投稿、カテゴリー、タグのデータだけを出力する場合、読み込む必要があるのはposts-wpcategories-wptags-wpパッケージ(およびその依存関係)のみです。

その後、WordPressから(たとえばLaravelやSymfonyへ)移行する際、新しいフレームワーク/CMS向けに再実装が必要なのはその3つのWordPress固有パッケージだけで、それ以外は何も必要ありません。