Dynamisk utvidelse av Enonics headless-API

Jeg er Enonics CTO, Thomas Sigdestad. Jeg hadde nylig en presentasjon om den nye versjonen av Guillotine 7 – en utvidelse av vårt GraphQL-skjema. Som tittelen antyder, går det forbi headless CMS. Dette er neste iterasjon av CMS, og vi synes det er skikkelig kult. Dere er de første som får en live demo av det, og jeg håper dere vil like det.

Hva er Guillotine?

Hvis du ikke er kjent med Guillotine, er det i bunn og grunn Enonics headless-API. Vi tar headless seriøst, og det er derfor det heter Guillotine. Det er et GraphQL-API, noe som betyr at det er sterkt typet og automatisk genererer API-et basert på din innholdsmodell.

Hver gang du definerer innholdstyper og andre skjemaer, reflekterer API-et automatisk disse endringene. Guillotine er tilgjengelig som en app på Enonic Market, så du kan enkelt installere det og få alt ut av boksen. Som nesten alt annet vi gjør, er det åpen kildekode, så du kan dykke dypt inn i det hvis du er interessert. 

Selv om dette er versjon 7, er det en større omskriving. Vi måtte gjøre betydelige endringer for å muliggjøre funksjonaliteten jeg skal demonstrere. Den store nyheten er dynamiske utvidelser, som vi vil fokusere på her. Hva betyr det? Vi viser deg i demoen.

Forbi headless CMS

Hva mener jeg med "forbi Headless CMS", og hvorfor er dette viktig? Tradisjonelle CMS-er prøvde å gjøre alt: frontend-rendering, innholdsforvaltning, personalisering, og mer. Så kom headless CMS, som reduserte CMS til bare å være en database. Dette skiftet påvirket både redaktører og utviklere. Utviklere kunne bruke sine favoritt-rammeverk, men måtte ta på seg mer ansvar, ofte å gjenoppfinne ting for å få alt til å fungere sammen.

Den neste iterasjonen, som jeg kaller universelt CMS, kombinerer det beste fra headless og tradisjonell CMS. Det tilbyr de visuelle redigeringsmulighetene og funksjonaliteten som redaktører liker, samtidig som utviklere kan velge sine egne frontend-rammeverk. CMS-et tar på seg en mer betydelig rolle, og leverer ikke bare HTML, men også JSON og mer.

Vanligvis inkluderer et headless CMS et forfattergrensesnitt, et API og en innholdsmodell. Dette er hvor det vanligvis stopper, uten rom for utvidelse. Men med Enonic XP får du en komplett plattform med backend-kontroll, et JavaScript-rammeverk for serverside-koding, sikkerhet, lagring og mer, noe som gjør det til en full applikasjonsstakk. På toppen av dette har du Content Studio og Guillotine API.

Når disse elementene kommer sammen, har du en digital opplevelses-backend. Dette betyr at du kan integrere dine egne systemer og data gjennom XP. For eksempel kan du hente sanntidspriser eller akseptere og lagre brukergenerert innhold gjennom API-et. XPs generelle datalagring lar deg persistere data uten behov for tilleggstjenester eller databaser, og du kan levere innhold i hvilket som helst format eller plattform.

Live Demo

La oss starte fra bunnen av. Jeg har Enonic CLI installert. Jeg skal lage en sandbox, som er et lokalt utviklingsmiljø, som kjører alt på maskinen min. Vi kaller det "min sandbox" og bruker "essential"-malen, som forhåndsinstallerer noen applikasjoner.

Etter å ha satt opp sandboxen, bygger jeg min egen app ved å bruke en annen kommando, og lager en app kalt "minapp" ved å bruke repo-tutorial-intro og kobler den til sandboxen jeg nettopp opprettet. Nå går jeg inn i mappen og begynner å kompilere. Denne første kompileringen tar litt tid fordi det innebærer å laste ned avhengigheter fra NPM.

Mens det kjører, la oss se på den lokale versjonen av XP. Dette er hele plattformen, akkurat som å kjøre en server i skyen. Det finnes snarveier for å logge inn på admin, og noen apper ble automatisk installert da jeg satte opp sandboxen, inkludert den jeg nettopp bygde. Jeg hopper rett til Content Studio, hvor jeg nå bør ha noen eksempler på data, inkludert filmer, bilder og personer.

Fordi jeg har Guillotine installert og har superbruker-roller, kan jeg begynne å kjøre spørringer umiddelbart fra Content Studio. Jeg har en spørring som søker etter innhold med teksten "Morgan" og sjekker innholdstypen "Person". Den henter visningsnavnet, fødselsdatoen og bilder, som er referanser til annet innhold. Å kjøre denne spørringen henter dataene.

La oss forbedre dette eksemplet ved å legge til funksjonalitet for å vise Morgan Freemans alder uten manuell beregning. I appen jeg opprettet, legger jeg til en mappe kalt Guillotine og en TypeScript-kontrollerfil.

For å utvide API-et legger vi til et felt ved å bruke en opprettelsestilbakeringing. Dette manipulerer og oppdaterer skjemaet, og legger til et "age" felt til "Person" datatypen. Resolveren beregner og returnerer alderen basert på fødselsdatoen.

Jeg skal distribuere appen igjen for å sikre at Guillotine oppdager endringene. Ved å oppdatere spørringsverktøyet, legger jeg til "age"-feltet i spørringen for Morgan Freeman. Å kjøre det viser den beregnede alderen. Dette demonstrerer hvordan du kan utvide API-et for å inkludere tilleggsdata, potensielt fra andre systemer eller aggregert innen XP.

Deretter vil jeg vise et mer sofistikert eksempel ved å installere tilleggs-testdata og SEO meta fields-appen. Ved å bytte til et annet datasett, en blogg, legger jeg til SEO-appen, konfigurerer den med et fallback-bilde og andre innstillinger, og publiserer den. Denne appen legger til et forhåndsvisningspanel og tilleggsfelt for overstyring på hvert innholdselement. I forhåndsvisning injiserer appen de nødvendige metaeiendommene.

For hodeløs bruk utvider appen API-et dynamisk. En ny spørring henter nettstedet, forsiden og blogginnlegget, sammen med de nylig lagt til metafeltene. Å kjøre denne spørringen henter metafeltene, slik at frontenden kan bruke dem direkte. Dette viser de dynamiske mulighetene til CMS-et, og gir en robust backend for dine frontend-behov.

Dette er det vi også gjør med alle våre standardapper nå. Enten du bruker vårt rammeverk eller headless, får du samme funksjonalitet og muligheter. Du kan bygge enda kulere ting. For nettstedet vårt bruker vi Next.js med headless, og vi bruker også sitemap-appen og SEO-appen. Alt blir injisert dynamisk i skjemaet. Du har sett dette live nå. Vi bruker de samme appene, sitemaps og hva annet for å gjøre det, og dette kjører på Next.js.

Q&A

Spørsmål 1: Jeg vet at vi noen ganger tar data fra visualiseringen. For dette bruker vi Guillotine, tror jeg. Kan du utdype sikkerhetsprotokollene for å ta data fra visualiseringen?

Svar: Når du kjører en spørring og kanskje ikke er autentisert, vet Guillotine dette og utfører det i konteksten av dine tillatelser. For eksempel, hvis det er et hemmelig felt eller prisdata, vil det ikke vises med mindre det er autorisasjon. Du kan sette opp virtuelle verter for å beskytte API-et, bruke autoinnlogging, eller benytte tjenestekontoer i XP8, som lar deg logge inn med en spesifikk tjenestebrukertoken. Guillotine er åpen, men dataene er ikke nødvendigvis åpne. Hvis et innholdselement krever at man er medlem av en utviklergruppe, vil det ikke vises med mindre autentisering er oppgitt med forespørselen. Så ja, du kan kontrollere og beskytte dataene tilsvarende.

Spørsmål 2: Det er fint å kunne legge til tilpassede felt til Guillotine API. Men hva om to forskjellige apper bestemmer seg for å legge til det samme feltet, for eksempel? En app legger til et felt, og den andre sletter det samme feltet. Hva skjer da?

Svar: Kortversjonen: det er udeterministisk. Hvis to apper implementerer det samme feltet, som alder-feltet, er utfallet tilfeldig basert på hvilken app som starter først eller endrer sist. Beste praksis er å ikke introdusere to apper som gjør det samme. Bruk navngivning eller andre metoder for å unngå konflikter.

Men med XP er alt navngitt ut av boksen. Hvis du har tre apper med samme innholdstype "person", vil de ha forskjellige navn fordi navnet inkluderer appen og innholdstypen. Du har kontroll over dette selv.