Logo
Interagir avec l'API GraphQL
Interagir avec l'API GraphQLMigrer votre application de WordPress vers un autre framework ou CMS PHP

Migrer votre application de WordPress vers un autre framework ou CMS PHP

Le schéma GraphQL fourni par Gato GraphQL contient des champs pour récupérer des données WordPress : articles, utilisateurs, commentaires, étiquettes, catégories, etc.

Le code dans les resolvers PHP qui récupère les données WordPress dépend de WordPress ; ce code ne peut pas s'exécuter dans une application non WordPress.

Cependant, Gato GraphQL a chacun de ces resolvers implémentés via 2 paquets :

  1. Un paquet PHP « vanilla », contenant tout le code générique
  2. Un paquet spécifique à WordPress, contenant les invocations réelles aux méthodes WordPress qui satisfont ce resolver

Par exemple, dans cette requête GraphQL :

{
  posts {
    id
    title
  }
}

...la logique pour récupérer les articles est composée de :

  1. Le champ Root.posts : il réside dans le paquet générique posts
  2. Sa résolution pour WordPress via la méthode get_posts : elle réside dans le paquet spécifique à WordPress posts-wp.

La répartition du code entre les paquets non-WordPress/WordPress est d'environ 80/20 %, ce qui signifie que 80 % du code est réutilisable avec un autre framework/CMS, et seulement 20 % du code devrait être réimplémenté.

De plus, toutes les fonctionnalités de Gato GraphQL sont livrées via des modules, et les modules peuvent être activés/désactivés à volonté.

Modules du schéma
Modules du schéma

Modules est une fonctionnalité implémentée à des fins de sécurité : si vous n'avez pas besoin d'exposer les données utilisateur dans votre API publique, vous pouvez désactiver le module Users, et les champs correspondants (comme Root.users) ne seront jamais ajoutés au schéma.

Les modules sont directement mappés aux paquets PHP sous-jacents. Ainsi, lors de l'exécution de Gato GraphQL en tant qu'application autonome, nous pouvons charger sélectivement les modules/paquets dont nous avons besoin, et aucun des autres.

Par exemple, si votre application n'affiche que des données d'articles, de catégories et d'étiquettes, alors seuls les paquets posts-wp, categories-wp et tags-wp (ainsi que leurs dépendances) doivent être chargés.

Ainsi, lors de la migration depuis WordPress (par exemple, vers Laravel ou Symfony), seuls ces 3 paquets spécifiques à WordPress devraient être réimplémentés pour le nouveau framework/CMS, et rien d'autre.