WPGraphQL : Le héros dont la pile de sites statiques a besoin

L'API REST de WP a été passionnante en 2016 pendant environ 5 minutes, jusqu'à ce que vous commenciez à l'utiliser. Bien qu'il soit agréable de pouvoir demander des données brutes à Wordpress, faire les requêtes imbriquées requises pour obtenir une page de base avec des articles connexes m'a fait déplorer l'âme sombre de l'homme.

Heureusement, WPGraphQL nous a permis d'interroger Wordpress en utilisant GraphQL comme des hominidés modernes, et a restauré ma foi en la capacité de l'humanité à surmonter l'ennui.

Mais WPGraphQL ne se contente pas de vous libérer d'une verbosité écrasante, il est également utile pour la construction de sites web et de logiciels.

Je suppose donc que nous devrions aborder ce sujet également.

Sortir de la caverne : Le modèle Wordpress-via-API arrive à maturité

Nous construisons des sites web et des applications en utilisant Wordpress REST API depuis 4 ans maintenant, et GraphQL sur d'autres projets depuis 2017. Ce n'est que récemment que nous avons eu l'opportunité de "fusionner" les deux (Wordpress et GraphQL). Cette combinaison est une évolution extrêmement bienvenue.

D'ailleurs, si vous avez besoin d'une introduction plus générale à GraphQL, le WPGraphQL a mis en place un bon walkthrough.

Nous avons construit des sites web et des applications en utilisant plusieurs saveurs de frontaux React, du React "vanille" à Gatsby et Next.js, et nous avons pris l'habitude de dire que cette pile (c'est-à-dire : un CMS solide, GraphQL et un frontal React / similaire) est ce qu'ils voulaient dire lorsqu'ils ont dit pour la première fois "site web", il y a de cela des années.

La pile offre la meilleure expérience de bout en bout :

• Le développeur obtient l'expérience qu'il a toujours voulue (qu'il le sache ou non).
• Le client bénéficie d'un développeur réactif qui peut littéralement faire tout ce qu'il peut imaginer avec facilité.
• Et l'utilisateur final obtient des pages HTML statiques rendues incroyablement rapides qui offrent toujours des expériences riches et interactives.

C'est pourquoi WPGraphQL joue un rôle si important dans la pile de développement web moderne : si vous voulez utiliser cette pile avec Wordpress, c'est tout simplement une pièce essentielle de votre infrastructure.

Bien que WPGraphQL en soit encore à ses débuts, il est déjà remarquablement robuste et complet. L'équipe est compétente, et aussi réactive que je l'ai vu pour les logiciels libres et l'open source en ce qui concerne les retours d'information, les rapports de problèmes et de bogues, et les réponses aux questions.

Pourquoi l'appelons-nous le héros dont la "pile de sites statiques" a besoin ? En d'autres termes, pourquoi une approche aussi large ou agnostique ?

Nous percevons la valeur et la pertinence de WPGraphQL comme étant si large parce qu'il y a de fortes chances que vous utilisiez Wordpress comme CMS. Et si ce n'est pas le cas, réfléchissez-y.

Alors que front-end le templating avec Wordpress a le même charme qu'une promenade dans une ville fantôme du vieil ouest, il est également presque aussi engageant, robuste et innovant.

Cependant, WP Admin est excellent et les clients adorent l'utiliser. De plus, il n'est pas prêt de disparaître.

Pour les projets internes et personnels, nous nous sommes éloignés de Wordpress pendant un certain temps, il y a 5 ou 6 ans. Mais l'évolution de l'API nous a fait revenir, et pour la plupart des projets (mais certainement pas tous), il reste notre choix.

Nous pensons que la plupart des grands sites robustes continueront à utiliser Wordpress, et qu'au fur et à mesure que WPGraphQL deviendra plus populaire, même les développeurs de more choisiront de l'utiliser pour leurs projets. Même l'avant-garde trop cool pour l'école.

Outre les défauts de Wordpress, c'est le CMS le plus développé au monde, et avec une solide API GraphQL disponible, il n'y a tout simplement pas de contre-argument pour la plupart des projets qui relèvent du domaine général du "site web".

A quel point WPGraphQL est-il complet ?

D'après notre expérience, il n'y a rien que nous voulions faire que nous ne puissions pas faire avec la dernière version. Cela ne veut pas dire qu'il ne manque rien, mais au fur et à mesure que nous avons utilisé le logiciel, il a progressé jusqu'à ce que tous les points de terminaison dont nous avons besoin soient couverts.

Cela signifie les posts, les pages, les commentaires, les catégories, les tags, les types de posts personnalisés, les paramètres, les menus, les plugins, tout.

Différence dans l'expérience de développement

Pour entrer dans le vif du sujet, voyons ce qu'il en est de travailler avec l'API REST par rapport à WPGraphQL.

Comme nous l'avons mentionné précédemment, nous utiliserons l'exemple de l'extraction des données d'un simple article, ainsi que de certains articles de tags ou de catégories connexes, ce qui est peut-être le cas d'utilisation le plus courant.

Une requête de contenu de base via l'API REST

Je vous épargnerai le spam du code pour faire des requêtes, mais cela ressemble essentiellement à ceci :

• Demander l'article, récupérer le titre, le contenu, la date de publication, etc.
  • A partir de la réponse, analyser l'URL + les informations d'ID pour l'image en vedette et les tags et/ou catégories
    • Demander le point de terminaison de l'image, qui vous indiquera où se trouvent les images.
      • Demander les points de terminaison de l'étiquette et/ou de la catégorie. Disons les 10 premiers.
        • Demandez les articles à ces points de terminaison. Cela fait 10 requêtes API.
          • Demandez les images pour chacun de ces articles (10 requêtes API supplémentaires ! Chacune !!)

Et ceci est la version simple. En réalité, vous finirez par gérer des cas particuliers comme un ancien billet sans image, etc., toutes choses que le modèle WPGraphQL gère pour vous.

Oh, et n'oubliez pas de faire la même chose pour l'auteur et toutes les métadonnées attachées que vous voulez obtenir de l'article !

Une requête de contenu de base via WPGraphQL

Faisons maintenant la même requête avec WPGraphQL - mais ici nous avons déjà inclus l'auteur et les métadonnées :

query GET_POSTS {
  posts {
    edges {
      node {
        id
        title
        date
        someCustomMetaData # some custom meta data
        author {
          firstName
          lastName
          email
          avatar {
            url
          }
        }
        featuredImage {
          mediaDetails {
            sizes {
              sourceUrl
            }
          }
        }
        categories(first: 10) {
          edges {
            node {
              name
              slug
              posts(first: 10) {
                edges {
                  node {
                    id
                    title
                    date
                    featuredImage {
                      mediaDetails {
                        sizes {
                          sourceUrl
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
        tags(first: 10) {
          edges {
            node {
              name
              slug
              posts(first: 10) {
                edges {
                  node {
                    id
                    title
                    date
                    featuredImage {
                      mediaDetails {
                        sizes {
                          sourceUrl
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Pour mémoire, il s'agit de one query avec tout ce que nous voulons. Et il a fallu environ 30 secondes pour l'écrire.

Que préférez-vous ? Laquelle préférez-vous maintenir ? Laquelle va vous donner plus d'agilité de développement et d'enthousiasme pour faire plus de magie pour vos clients ?

Encore plus puissant lorsque plusieurs applications consomment ces données.

Réfléchissez un instant à ce cas de figure. En utilisant l'API REST, vous auriez environ double du code à maintenir. Vous vous souvenez des cas limites évoqués dans la section sur l'API REST ci-dessus ? En utilisant l'API REST, chaque consommateur est responsable de sa propre logique de récupération, d'analyse et d'aller-retour.

Alors qu'avec WPGraphQL, tout le travail est fait, vous pouvez simplement passer la même requête ou quelque chose de complètement nouveau sans avoir à créer un nouveau câblage (ht WPGraphQL creator @jasonbahl).

Attachez votre cape

Si vous n'utilisez pas WPGraphQL pour construire des sites web statiques avec Wordpress, vous le ferez bientôt. Faites-vous une faveur et commencez dès aujourd'hui.

C'est un super pouvoir de développement web.