WPGraphQL: De held die de static-site stack nodig heeft

De WP REST API was in 2016 ongeveer 5 minuten lang opwindend, totdat je hem ging gebruiken. Hoewel het leuk is om ruwe gegevens van Wordpress op te kunnen vragen, moest ik bij het maken van de vereiste geneste query's om een basispagina met gerelateerde berichten samen te stellen, klagen over de donkere ziel van de mens.

Gelukkig kwam WPGraphQL langs om ons Wordpress te laten bevragen met GraphQL als moderne hominiden en herstelde mijn geloof in het vermogen van de mensheid om eentonigheid te overwinnen.

Maar WPGraphQL is meer dan alleen het bevrijden van zielverpletterende verbositeit, het is ook nuttig voor het bouwen van websites en software.

Dus ik denk dat we het daar ook over moeten hebben.

Opduiken uit de grot: Het Wordpress-via-API patroon wordt volwassen

We bouwen al 4 jaar websites en apps met behulp van de Wordpress REST API, en GraphQL op andere projecten sinds 2017. Pas onlangs was er de mogelijkheid om de twee (Wordpress en GraphQL) samen te voegen. De combinatie is een zeer welkome evolutie.

Trouwens, als je een meer algemene inleiding nodig hebt over GraphQL, de WPGraphQL heeft een goede walkthrough samengesteld.

We hebben websites en apps gebouwd met verschillende smaken React front ends, van "vanilla" React tot Gatsby en Next.js, en we zijn er dol op om te zeggen dat deze stack (dat wil zeggen: een solide CMS, GraphQL en een React / vergelijkbare front-end) is wat ze bedoelden toen ze al die jaren geleden voor het eerst "website" zeiden.

De stack biedt de beste ervaring van end-to-end:

• De ontwikkelaar krijgt de ervaring die hij altijd al wilde (of hij het nu wist of niet)
• De klant krijgt een responsieve ontwikkelaar die letterlijk alles met gemak kan doen wat hij zich kan voorstellen
• En de eindgebruiker krijgt waanzinnig snelle, statisch gerenderde HTML-pagina's die nog steeds een rijke, interactieve ervaring bieden.

Daarom speelt WPGraphQL zo'n belangrijke rol in de moderne webontwikkelingsstack: als je deze stack met Wordpress wilt gebruiken, is het gewoon een essentieel onderdeel van je infrastructuur.

Hoewel WPGraphQL nog in de kinderschoenen staat, is het nu al opmerkelijk robuust en volledig. Het team is kundig en zo ontvankelijk als een vrije software / open source team als ik heb gezien voor feedback, probleem- en bugrapporten en het beantwoorden van vragen.

Waarom noemen we het de held die de "static-site stack" nodig heeft? D.w.z. waarom zo breed of agnostisch?

We zien de waarde en relevantie van WPGraphQL zo breed omdat de kans groot is dat je Wordpress als CMS gebruikt. En als dat niet zo is, denk er dan eens over na.

Hoewel front-end templating met Wordpress dezelfde charme heeft als een wandeling door een spookstad in het oude westen, is het ook bijna net zo boeiend, robuust en innovatief.

WP Admin is echter geweldig en klanten gebruiken het graag. Bovendien gaat het nergens heen.

Voor interne en persoonlijke projecten zijn we eigenlijk 5-6 jaar geleden een tijdje weggegaan van Wordpress. Maar de evoluerende API bracht ons terug en voor de meeste soorten projecten (maar zeker niet alle), blijft het onze go-to.

We verwachten dat de meeste grote, robuuste sites Wordpress zullen blijven gebruiken en dat naarmate WPGraphQL populairder wordt, zelfs more ontwikkelaars zullen kiezen om het voor hun projecten te gebruiken. Zelfs de te-cool-voor-school avant-garde.

Alle tekortkomingen van Wordpress daargelaten, het is het meest ontwikkelde CMS ter wereld en met een solide GraphQL API beschikbaar, is er simpelweg geen tegenargument voor de meeste projecten die onder de algemene noemer 'website' vallen.

Hoe volledig is WPGraphQL?

In onze ervaring is er niets dat we wilden doen dat we niet kunnen doen vanaf de laatste release. Dat betekent niet dat er niets ontbreekt, maar gewoon dat we de software hebben gebruikt en dat alle eindpunten die we nodig hebben er nu in zitten.

Dit betekent posts, pagina's, comments, categorieën, tags, aangepaste posttypes, instellingen, menu's, plugins, alles.

Verschil in ontwikkelingservaring

Laten we eens kijken hoe het is om te werken met de REST API vs. WPGraphQL.

Zoals eerder vermeld, gebruiken we het voorbeeld van het ophalen van de gegevens van een eenvoudige post, samen met enkele posts van gerelateerde tags of categorieën, misschien wel het meest voorkomende gebruik.

Een basisverzoek om inhoud via de REST API

Ik zal je de code-spam van het maken van verzoeken besparen, maar het ziet er in wezen zo uit:

• Vraag de post op, krijg de titel, inhoud, publicatiedatum, enz. terug.
  • Uit het antwoord, parseer de URL + ID info voor de uitgelichte afbeelding en tags en / of categorieën
    • Vraag het eindpunt van de afbeelding op, dat je zal vertellen waar de afbeeldingen zijn
      • Vraag de tag en/of categorie eindpunten op. Laten we zeggen de eerste 10.
        • Vraag de berichten op die eindpunten op. Dat zijn 10 API verzoeken.
          • Vraag de afbeeldingen voor elk van die berichten op (nog eens 10 API-verzoeken! Elk!!)

En dit is de eenvoudige versie. In werkelijkheid moet je randgevallen afhandelen zoals een oud bericht dat geen afbeelding heeft, etc., allemaal dingen die het WPGraphQL model voor je afhandelt.

Oh, en vergeet niet om hetzelfde te doen voor de auteur en alle bijgevoegde metadata die je uit het bericht wilt halen!

Een basisverzoek om inhoud via WPGraphQL

Laten we nu hetzelfde verzoek doen met WPGraphQL - alleen hebben we hier de auteur en metagegevens al toegevoegd:

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
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Voor de goede orde, dat is één query met alles wat we willen. En het duurde ongeveer 30 seconden om te schrijven.

Welke heb je liever? Welke zou je liever onderhouden? Welke geeft je meer ontwikkelruimte en opwinding om meer magie te doen voor je klanten?

Nog krachtiger als je meer dan één applicatie hebt die deze gegevens gebruikt

Overweeg dit geval even. Als je de REST API zou gebruiken, zou je ongeveer -dubbel de code moeten onderhouden. Herinner je je die randgevallen uit het REST API gedeelte hierboven? Nou, bij gebruik van de REST API is iedere gebruiker verantwoordelijk voor zijn eigen fetch / parse / round-trip logica.

Terwijl WPGraphQL al het zware werk doet, kun je gewoon dezelfde query of iets compleet nieuws doorgeven zonder nieuwe bedrading te hoeven maken (ht WPGraphQL creator @jasonbahl).

Maak je cape vast

Als je WPGraphQL nog niet gebruikt om statische websites met Wordpress te bouwen, zul je dat binnenkort wel doen. Doe jezelf een plezier en begin vandaag.

Het is een superkracht voor webontwikkeling.