Case Study: Gatsby API Sourcing
Gatsby als Static Site Generator ist für mich bei den meisten Projekten immer auch meine erste Wahl.
Ein besonderer Vorteil von Gatsby ist es - unter vielen anderen - dass es bereits zahlreiche "Source-Plugins" gibt. Das bedeutet, dass man unterschiedliche Content-Quellen ganz einfach in seine Website integrieren kann.
Aber was soll man machen, wenn es für eine Datenquelle mal keine Erweiterung gibt?
Individuelle Source-Funktion
Der Jamstack-Ansatz ist einer meiner favorisierten Ansätze, wenn ich einen neue Website erstellen soll. Warum das so ist, erfährst du in diesem Blogbeitrag.
Kurz und knapp geht es beim Jamstack-Ansatz ja darum, die Daten für die Website über eine API auszulesen und daraus das Markup für deine Seite zu erstellen. Dabei ist die Anzahl der API-Schnittstellen natürlich nicht begrenzt. Du kannst mehrere APIs verwenden, um deine Website mit Daten zu füttern. Theoretisch könntest du so deinen Blog und deine Inhalte über WordPress verwalten und deine Produkte über Shopify bereitstellen. Alles kein Problem.
Wenn du einen Static-Site-Generator verwendest, benötigt man für diesen Ansatz dann ein Build-Step, bei welchem die Daten ausgelesen und das Markup erstellt wird. Bei Gatsby kann man zum Auslesen der Daten meistens sogenannte Source-Plugins verwenden.Für die meisten gängigen Datenquellen - wie zum Beispiel WordPress, Shopify, Prismic, Strapi, .. - gibt es bereits diese vorgefertigten Plugins. Man muss ihnen lediglich API-Zugang geben und der Build läuft automatisch.
Ein Kunde von mir hatte das Problem, dass es für eine seiner Datenquellen kein solches Build-Plugin gegeben hat. Konkret sollten alle offenen Stellen über eine externe API ausgelesen und auf der Jamstack-Website integriert werden. Die verwendet API war dazu etwas .... umständlich .... weshalb mehrere unterschiedliche API-Calls nacheinander durchgeführt und kombiniert werden mussten.
Zuallererst habe ich dazu im Gatsby-Build-Prozess eine fetch-Funktion entwickelt. Diese Funktion hat dann die einzelnen API-Aufrufe nacheinander durchgeführt und so aus den zurückgegebenen Daten jeweils mein Datenobjekt gebaut. Damit im Build-Prozess festgestellt werden kann, ob eine API-Schnittstelle nicht erreicht werden kann, werden entsprechende Logs ausgegeben.
Sobald das Daten-Objekt vollständig ist, wird dieses in der Gatsby Node weiterverarbeitetet. Aus den einzelnen Elementen werden nun neue Seiten erstellt. Jeder Job erhält also seine eigene Job-Übersichts-Seite. Diese wird mit den Daten befüllt. Außerdem wird auch eine Job-Übersichts-Seite erstellt.
Projekt-Details
- JAMStack-Website mit Gatsby als SSG
- Axios-Fetch-Calls im Gatsby Build Prozess
- Page Creation mit erhaltenen Daten
Nur noch einen Klick davon entfernt ...
... mit mir zusammen zu arbeiten. Schreibe mir einfach eine E-Mail oder ruf mich an. Dann können wir über dein (unser?) nächstes Projekt sprechen.
Ich bin gespannt!
Lieber Social Media? Klar, hab ich auch:
