WPGraphQL: Der Held, den der Static-Site-Stack braucht

Die WP REST API war im Jahr 2016 für etwa 5 Minuten aufregend, bis man anfing, sie zu benutzen. Es ist zwar schön, Rohdaten von Wordpress abrufen zu können, aber die erforderlichen verschachtelten Abfragen zu machen, um eine einfache Seite mit verwandten Beiträgen zusammenzustellen, ließ mich die verdunkelte Seele des Menschen beklagen.

Glücklicherweise ist WPGraphQL aufgetaucht, um uns dazu zu bringen, Wordpress mit GraphQL wie moderne Hominiden abzufragen, und hat meinen Glauben an die Fähigkeit der Menschheit, Mühsal zu überwinden, wiederhergestellt.

Aber WPGraphQL ist mehr als nur eine Erleichterung für die Seele, es ist auch nützlich für den Aufbau von Websites und Software.

Das sollten wir also auch noch erwähnen.

Aus der Höhle aufgetaucht: Das Wordpress-via-API-Muster erreicht seine Reife

Wir bauen seit 4 Jahren Websites und Apps mit der Wordpress REST API und seit 2017 GraphQL in anderen Projekten. Erst vor kurzem hat sich die Möglichkeit ergeben, die beiden (Wordpress und GraphQL) zu "verschmelzen". Die Kombination ist eine äußerst willkommene Entwicklung.

Übrigens, wenn Sie eine allgemeinere Einführung in GraphQL benötigen, hat die WPGraphQL einen guten Walkthrough zusammengestellt.

Wir haben Websites und Anwendungen mit verschiedenen Varianten von React-Frontends gebaut, von "Vanilla"-React bis Gatsby und Next.js, und wir haben uns angewöhnt zu sagen, dass dieser Stack (d.h. ein solides CMS, GraphQL und ein React- oder ähnliches Frontend) das ist, was man meinte, als man vor all den Jahren zum ersten Mal "Website" sagte.

Der Stack bietet die beste Erfahrung von Ende zu Ende:

• Der Entwickler erhält die Erfahrung, die er schon immer haben wollte (ob er es wusste oder nicht)
• Der Kunde erhält einen reaktionsschnellen Entwickler, der buchstäblich alles, was er sich vorstellen kann, mit Leichtigkeit erledigen kann
• Und der Endbenutzer erhält wahnsinnig schnelle, statisch gerenderte HTML-Seiten, die dennoch reichhaltige, interaktive Erfahrungen bieten.

Das ist der Grund, warum WPGraphQL eine so wichtige Rolle in der modernen Webentwicklung spielt: Wenn Sie diesen Stack mit Wordpress nutzen wollen, ist es einfach ein wichtiger Bestandteil Ihrer Infrastruktur.

Obwohl WPGraphQL noch in den Kinderschuhen steckt, ist es bereits bemerkenswert robust und voll funktionsfähig. Das Team ist sachkundig und so reaktionsschnell wie kein anderes Team für freie Software/Open Source, das ich kenne, wenn es um Feedback, Problem- und Fehlerberichte und die Beantwortung von Fragen geht.

Warum bezeichnen wir es als den Helden, den der "static-site stack" braucht? D.h., warum so breit oder agnostisch?

Wir sehen den Wert und die Relevanz von WPGraphQL als so breit gefächert an, weil die Wahrscheinlichkeit groß ist, dass Sie Wordpress als Ihr CMS verwenden. Und wenn Sie das nicht tun, sollten Sie das bedenken.

Während front-end Templating mit Wordpress den gleichen Charme hat wie ein Spaziergang durch eine Geisterstadt im alten Westen, ist es auch fast so einnehmend, robust und innovativ.

WP Admin ist jedoch großartig, und die Kunden nutzen es gerne. Außerdem wird es nicht verschwinden.

Für interne und persönliche Projekte haben wir uns vor 5-6 Jahren für einige Zeit von Wordpress abgewandt. Aber die sich entwickelnde API brachte uns zurück, und für die meisten Projekte (wenn auch definitiv nicht für alle) bleibt es unsere erste Wahl.

Wir gehen davon aus, dass die meisten großen, robusten Websites weiterhin Wordpress verwenden werden, und dass mit zunehmender Popularität von WPGraphQL auch more Entwickler sich dafür entscheiden werden, es für ihre Projekte zu verwenden. Sogar die Avantgarde, die zu cool für die Schule ist.

Abgesehen von allen Mängeln, die Wordpress haben mag, ist es das am weitesten entwickelte CMS der Welt, und mit einer soliden GraphQL-API gibt es einfach kein Gegenargument für die meisten Projekte, die unter den allgemeinen Begriff "Website" fallen.

Wie umfangreich ist WPGraphQL?

Unserer Erfahrung nach gibt es nichts, was wir uns gewünscht haben, was wir mit der aktuellen Version nicht tun können. Das heißt nicht, dass nichts fehlt, sondern dass die Software im Laufe der Zeit so weit entwickelt wurde, dass alle von uns benötigten Endpunkte abgedeckt sind.

Das bedeutet Beiträge, Seiten, Kommentare, Kategorien, Tags, benutzerdefinierte Beitragstypen, Einstellungen, Menüs, Plugins, alles.

Unterschiedliche Erfahrungen bei der Entwicklung

Um zur Sache zu kommen, lassen Sie uns einen Blick darauf werfen, wie die Arbeit mit der REST-API im Vergleich zu WPGraphQL aussieht.

Wie bereits erwähnt, verwenden wir das Beispiel des Abrufs der Daten für einen einfachen Beitrag zusammen mit einigen Beiträgen aus verwandten Tags oder Kategorien, dem vielleicht häufigsten Anwendungsfall.

Eine einfache Inhaltsabfrage über die REST-API

Ich erspare Ihnen den Code-Spam für die Abfrage, aber im Wesentlichen sieht er so aus:

• Abfrage des Beitrags, Rückgabe von Titel, Inhalt, Veröffentlichungsdatum, etc.
  • Analysieren Sie aus der Antwort die URL + ID-Informationen für das vorgestellte Bild und die Tags und/oder Kategorien
    • Fordern Sie den Bild-Endpunkt an, der Ihnen sagt, wo sich die Bilder befinden.
      • Fordern Sie die Tag- und/oder Kategorie-Endpunkte an. Sagen wir, die ersten 10.
        • Fordern Sie die Beiträge an diesen Endpunkten an. Das sind 10 API-Anfragen.
          • Fordern Sie die Bilder für jeden dieser Beiträge an (10 weitere API-Anfragen! Jede!!)

Und das ist die einfache Version. In Wirklichkeit müssen Sie Randfälle behandeln, z. B. einen alten Beitrag ohne Bild usw., alles Dinge, die das WPGraphQL-Modell für Sie erledigt.

Oh, und vergessen Sie nicht, dasselbe für den Autor und alle angehängten Metadaten zu tun, die Sie aus dem Beitrag erhalten möchten!

Eine einfache Inhaltsabfrage über WPGraphQL

Lassen Sie uns nun die gleiche Anfrage mit WPGraphQL stellen - nur haben wir hier bereits den Autor und die Metadaten mit einbezogen:

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

Fürs Protokoll, das ist eine Abfrage mit alles, was wir wollen. Und es hat etwa 30 Sekunden gedauert, sie zu schreiben.

Was ist Ihnen lieber? Welche würden Sie lieber beibehalten? Welche wird Ihnen mehr Flexibilität bei der Entwicklung bieten und Sie dazu anregen, mehr Magie für Ihre Kunden zu schaffen?

Noch leistungsfähiger, wenn Sie mehr als eine Anwendung haben, die diese Daten nutzt

Betrachten Sie diesen Fall einen Moment lang. Mit der REST-API hätten Sie etwa doppelten Code zu pflegen. Erinnern Sie sich an die Randfälle aus dem obigen Abschnitt über die REST-API? Bei Verwendung der REST-API ist jeder Verbraucher für seine eigene Abruf-/Parse-/Roundtrip-Logik verantwortlich.

Während WPGraphQL die ganze Arbeit übernimmt, können Sie einfach die gleiche Abfrage oder etwas völlig Neues übergeben, ohne eine neue Verdrahtung erstellen zu müssen (ht WPGraphQL creator @jasonbahl).

Fasten your cape

Wenn Sie WPGraphQL noch nicht nutzen, um statische Websites mit Wordpress zu erstellen, werden Sie es bald tun. Tun Sie sich einen Gefallen und beginnen Sie noch heute.

Es ist eine Superkraft der Webentwicklung.