WPGraphQL: L'eroe di cui lo stack di siti statici ha bisogno

L'API REST di WP è stata entusiasmante nel 2016 per circa 5 minuti, finché non si è iniziato a usarla. Sebbene sia bello poter richiedere dati grezzi a Wordpress, l'esecuzione delle query annidate necessarie per mettere insieme una pagina di base con i post correlati mi ha fatto rimpiangere l'anima oscurata dell'uomo.

Per fortuna è arrivato WPGraphQL, che ci permette di interrogare Wordpress usando GraphQL come moderni ominidi, e mi ha restituito la fiducia nella capacità dell'uomo di superare la noia.

Ma WPGraphQL non si limita a liberare l'utente dalla verbosità che lo schiaccia, ma è anche utile per costruire siti web e software.

Quindi suppongo che dovremmo parlare anche di questo.

Emergere dalla caverna: Il modello Wordpress-via-API raggiunge la maturità

Sono ormai 4 anni che costruiamo siti web e app utilizzando Wordpress REST API e GraphQL su altri progetti dal 2017. Solo di recente si è presentata l'opportunità di "fondere" le due cose (Wordpress e GraphQL). La combinazione è un'evoluzione estremamente gradita.

A proposito, se avete bisogno di un'infarinatura più generale su GraphQL, il WPGraphQL ha messo insieme una buona guida.

Abbiamo costruito siti web e applicazioni utilizzando diversi tipi di front-end React, da React "vanilla" a Gatsby e Next.js, e ci siamo affezionati a dire che questo stack (cioè: un solido CMS, GraphQL e un front-end React o simile) è ciò che intendevano quando hanno detto "sito web", tanti anni fa.

Lo stack fornisce la migliore esperienza end-to-end:

• Lo sviluppatore ottiene l'esperienza che ha sempre desiderato (che lo sapesse o meno).
• Il cliente ottiene uno sviluppatore reattivo che può letteralmente fare tutto ciò che può immaginare con facilità
• E l'utente finale ottiene pagine HTML statiche e incredibilmente veloci che forniscono comunque esperienze ricche e interattive.

Ecco perché WPGraphQL gioca un ruolo così importante nel moderno stack di sviluppo web: se si vuole usare questo stack con Wordpress, è semplicemente un pezzo fondamentale della vostra infrastruttura.

Sebbene WPGraphQL sia ancora agli inizi, è già notevolmente robusto e completo. Il team è competente e molto reattivo come quello del software libero/open source che ho visto per quanto riguarda i feedback, le segnalazioni di problemi e bug e le risposte alle domande.

Perché ci riferiamo a lui come all'eroe di cui ha bisogno lo "stack di siti statici"? Perché è così ampio o agnostico?

Riteniamo che il valore e la rilevanza di WPGraphQL siano così ampi perché è probabile che stiate utilizzando Wordpress come CMS. E se non lo state facendo, consideratelo.

Sebbene front-end templating con Wordpress abbia lo stesso fascino di una passeggiata in una città fantasma del vecchio West, è anche quasi altrettanto coinvolgente, robusto e innovativo.

Tuttavia, WP Admin è fantastico e i clienti lo usano volentieri. Inoltre, non sta andando da nessuna parte.

Per i progetti interni e personali, ci siamo allontanati da Wordpress per qualche tempo, forse 5-6 anni fa. Ma l'evoluzione delle API ci ha riportato indietro e per la maggior parte dei progetti (anche se non tutti) rimane il nostro punto di riferimento.

Prevediamo che la maggior parte dei siti grandi e robusti continuerà a usare Wordpress e che, man mano che WPGraphQL diventerà più popolare, anche more sviluppatori sceglieranno di usarlo per i loro progetti. Anche le avanguardie troppo cool per la scuola.

A parte le eventuali carenze di Wordpress, è il CMS più sviluppato al mondo e, con la disponibilità di una solida API GraphQL, non ci sono controargomenti per la maggior parte dei progetti che rientrano nel concetto generale di "sito web".

Quanto è completo WPGraphQL?

Nella nostra esperienza, non c'è stato nulla che abbiamo voluto fare che non sia attualmente possibile fare con l'ultima versione. Ciò non significa che non manchi nulla, ma solo che, man mano che abbiamo utilizzato il software, esso è progredito fino al punto in cui tutti gli endpoint di cui abbiamo bisogno sono coperti.

Questo significa post, pagine, commenti, categorie, tag, tipi di post personalizzati, impostazioni, menu, plugin, tutto.

Differenza nell'esperienza di sviluppo

Venendo al sodo, diamo un'occhiata a cosa significa lavorare con l'API REST rispetto a WPGraphQL.

Come accennato in precedenza, useremo l'esempio di estrarre i dati di un semplice post, insieme ad alcuni post di tag o categorie correlate, forse il caso d'uso più comune.

Una richiesta di contenuti di base tramite l'API REST

Vi risparmierò lo spam del codice per effettuare le richieste, ma essenzialmente si presenta così:

• Richiedere il post, ottenere titolo, contenuto, data di pubblicazione, ecc.
  • Dalla risposta, analizzare l'URL + le informazioni sull'ID dell'immagine in primo piano e i tag e/o le categorie.
    • Richiedere l'endpoint dell'immagine, che indica dove si trovano le immagini.
      • Richiedere gli endpoint dei tag e/o delle categorie. Diciamo i primi 10.
        • Richiedere i post a quegli endpoint. Sono 10 richieste API.
          • Richiedere le immagini per ciascuno di questi post (altre 10 richieste API! Ciascuna!)

Questa è la versione semplice. In realtà, si finisce per gestire casi limite, come un vecchio post privo di immagine, ecc.

Oh, e non dimenticate di fare lo stesso per l'autore e tutti i metadati allegati che volete ottenere dal post!

Una richiesta di contenuto di base tramite WPGraphQL

Ora facciamo la stessa richiesta con WPGraphQL, solo che qui abbiamo già incluso l'autore e i metadati:

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

Per la cronaca, questa è ** una query** con tutto quello che vogliamo. E ci sono voluti circa 30 secondi per scriverla.

Quale preferite? Quale preferireste mantenere? Quale vi darà più agilità di sviluppo e più entusiasmo per fare più magia per i vostri clienti?

Ancora più potente quando ci sono più applicazioni che consumano questi dati.

Considerate questo caso per un momento. Usando l'API REST avreste circa doppio del codice da mantenere. Ricordate i casi limite della sezione sull'API REST? Bene, utilizzando l'API REST ogni utente è responsabile della propria logica di fetch / parse / round-trip.

Mentre con WPGraphQL fa tutto il lavoro pesante, si può semplicemente passare la stessa query o qualcosa di completamente nuovo senza dover creare alcun nuovo cablaggio (ht WPGraphQL creator @jasonbahl).

Allacciate il mantello

Se non state usando WPGraphQL per costruire siti web statici con Wordpress, presto lo farete. Fatevi un favore e iniziate oggi.

È un superpotere dello sviluppo web.