Die avocado Webseite ist umgezogen! Während die bisherige Implementierung mit Hilfe des bekannten CMS WordPress erfolgte, sind wir nun auf einen Jamstack-Ansatz auf Basis von Angular, Scully und Strapi umgestiegen. In diesem Blogbeitrag wird näher auf die einzelnen Technologien eingegangen und erläutert, welche Vorteile der Jamstack-Ansatz für uns mit sich bringt.
Was ist Jamstack?
Der Begriff beschreibt einen modernen Architektur-Ansatz in der Webentwicklung. Als dieser Ansatz 2016 vorgestellt wurde, stand JAM für JavaScript, APIs und Markup. Inzwischen ist der Jamstack nicht mehr auf diese Technologien beschränkt und die Ausgestaltung der Technologien kann sehr unterschiedlich sein. Dennoch geht es bei allen Jamstack Ansätzen darum, die Vorteile von statischen Websites zu nutzen. Im Gegensatz zu klassischen Websites werden die Seiten nicht zur Laufzeit, sondern schon vorab gebaut (prerender).
Vorteile von Jamstack
Vorteile gegenüber herkömmlichen Websites liegen hierbei vor allem in den Bereichen Performance, Skalierbarkeit und Sicherheit.
Performance
Dadurch dass nur statische Seiten ausgeliefert werden, fällt der Request zum Server weg. Das Bereitstellen von statischen Seiten bietet somit den schnellsten Weg der Auslieferung einer Webseite an einen Client. Eine hervorragende Performance erhöht außerdem die User Experience enorm.
Saklierbarkeit
Wie bereits erwähnt ist im Gegensatz zu anderen Ansätzen zur Laufzeit kein Rendering mehr nötig, um das HTML einer Webseite zu erstellen. Die Gefahr der Überlastung eines Servers durch zu viele gleichzeitige Requests ist somit um ein vielfaches reduziert, da lediglich die fertigen HTML-Seiten ausgeliefert werden. Darüber hinaus wird dadurch auch die Skalieung auf mehrere Server denkbar einfach.
Sicherheit
Ohne eine eigene Datenbank oder einen Server, auf die deine Website direkt zugreift, entfallen gleich mehrere Angriffsvektoren, wie z.B. SQL Injection oder DDoS Attacks.
Developer Experience
Für den Einsatz bei avocado ist der Jamstack-Ansatz vor allem von Vorteil, da die Implementierung im gewohnten Angular-Umfeld stattfinden kann. Dort profitieren wir von der Erfahrung und den Kenntnissen aus unserer täglichen Arbeit, der Entwicklung von Individualsoftware. Somit gleicht auch der Workflow vom Setup des Projektes bis hin zum Pull Request bei einer Änderung sowie dem Rollout anderen Projekten bei avocado. Wir können für uns dann auf jeden Fall von einer deutlich gesteigerten Developer Experience sprechen. Das hängt aber natürlich immer vom Team ab, welches sich um die Umsetzung kümmert.
Wieso der Umzug?
WordPress bietet vor allem Nutzern mit wenig Programmierkenntnissen die Möglichkeit, aus zahlreichen Themes und Plugins auszuwählen und so seine eigene Website zu erstellen. Wenn es allerdings darum geht individuelle Bedürfnisse abzudecken, liefert WordPress nur eine mäßige Developer Experience. Der einst moderne PHP-Technologie-Stack wurde mittlerweile von Frontend Frameworks wie React und Angular abgelöst. Bei der Vielzahl an Plugins kann es zu Kompatibilitätsproblemen kommen und außerdem wird das Projekt dadurch unübersichtlich. Nicht zuletzt fühlen wir uns als Softwareentwickler im gewählten Umfeld einfach deutlich wohler und können mehr unsere Stärken einbringen.
Umsetzung
Um auch die Entwicklung der Webseite optimal in unseren bestehenden WorkFlow zu erreichen, war eine Entwicklung mit Angular wünschenswert. Daher haben wir uns für den Static Site Generator Scully entschieden. Zur Ablösung des bisherigen CMS WordPress dient das moderne Headless CMS Strapi.
Strapi
Headless bedeutet in diesem Fall, dass das CMS keine Vorschau in Form eines Frontends bietet und nur zur Verwaltung des Contents im Backend dient. Dadurch wird das Framework sehr leichtgewichtig und flexibel. Das Open Source Framework gibt Nutzern die Möglichkeit, eigene Content-Types zu erstellen und diese mit individuellen Feldern und Relationen zu anderen Content-Types zu versehen. Auch durch die Zunahme von Plugins kann Strapi speziell auf den Anwendungsfall individualisiert werden. Mit Blick auf die Implementierung der Webseite ist Strapi für das Verwalten von Blogbeiträgen und Medien zuständig. Der Zugriff auf diese Inhalte in Scully bzw. Angular erfolgt über die Strapi API, welche die Inhalte als klassische REST-Schnittstelle aber auch per GraphQL bereitstellt. In puncto Interoperabilität bleiben hier als keine Wünsche offen.
Scully
Scully ist ein Framework das den Jamstack und Angular vereint. Durch das Hinzufügen von Scully zu einem Angular Projekt, ist es möglich statische Seiten aus der Applikation zu generieren. Scully liest dabei die Routen aus der Applikation aus und generiert für jede Route eine Index.html-Datei und falls erforderlich eine data.json-Datei. In dieser speichert Scully die Antworten eines API-Requests, wie bspw. die Daten eines Blogbeitrags.
Um Scully mitzuteilen eine data.json zu erstellen, wird der Service Call innerhalb des ScullyTransferStates aufgerufen.
public getBlogPosts(): Observable<Blog[]> {
return this.transferState.useScullyTransferState(
'posts',
this.apiClient.get(`blogs?populate=*&pagination[pageSize]=50`)
).pipe(
map((list) => {
return Serializer.createArray(list?.data, Blog)?.sort((a, b) =>
new Date(b.attributes!.publishDate).getTime() - new Date(a.attributes!.publishDate).getTime());
})
)
}Somit wird dieser Request nicht mehr länger zur Laufzeit gebraucht und es muss des Weiteren nicht für jeden Blogbeitrag eine eigene Komponente erstellt werden.
Deployment
Ein möglicher Nachteil am gewählten Ansatz ist, dass man auf dynamische Inhalte im Live-System weitestgehend verzichtet. Das wäre nicht zwangsläufig der Fall, da man ja immer im Einzelfall entscheiden kann, ob man eine Abfrage an beispielsweise die Strapi-API im ScullyTransferState aufruft, oder nicht. Tut man das nicht, wird auch vom Live-System aus versucht, den Inhalt dynamisch zu beziehen. In unserem Anwendungsfall war es aber eine bewusste Entscheidung die Strapi-API überhaupt nicht öffentlich zur Verfügung zu stellen. Um das nicht zum Problem werden zu lassen, haben wir einen leichtgewichtigen Rollout-Prozess in unserer CI-Plattform Jenkins aufgesetzt. Auch hier erleichtet es uns den Alltag, wenn wir auf gewohnte Tools und Umgebungen aus anderen Projekten zurückgreifen können. Um den Lebenszyklus abzurunden gibt es selbstverständlich im lokalen Netz eine Staging-Version der Website, auf der vorab der aktuelle Stand getestet werden kann. Im Rahmen eines Jenkins-Rollouts wird dann der Inhalt mit Hilfe von Scully vorgeneriert und als einfache HTML-Seiten ausgespielt.
Fazit
Der Umstieg auf eine Jamstack-Architektur hat gezeigt, dass dieser Ansatz einige Vorteile mit sich bringt. Die beiden Technologien Scully und Strapi eigneten sich optimal in diesem Anwendungsfall und erweiterten den bestehenden avocado-Tech-Stack. Wir freuen uns auch in Zukunft immer wieder neue Herangehensweisen zu evaluieren und bleiben neugierig. Auch der Jamstack hält sicher noch einiges bereit für uns.
