Photo by Priscilla Du Preez on Unsplash

Local First Entwicklung im Frontend

Einleitung

Gewöhnliche Front-End-Anwendungen müssen fast immer Daten von anderen Datenlieferanten konsumieren, meistens von einem Backend-System. Oft sind jedoch die Backends schwer-gewichtig, stehen nicht sofort zur Verfügung oder können generell nicht von der lokalen Entwickler-Umgebung angesprochen werden.

Motivation

Wenn man sich nun fragt, wozu derartiges Vorgehen nötig ist oder der Mehrwert generell fraglich erscheint, möchte ich folgende kritische Projekt-Situationen als Indikatoren kurz benennen:

  • Du musst ständig auf DEV- oder andere Umgebungen ausrollen, um die Integrität mit der REST-API zu prüfen.
  • Dein Javascript-Code muss einen komplizierten Token-Refresh-Workflow implementieren, den du nur manuell, durch HTTP Request-Manipulation im Debugger und nur auf externer Umgebung nachstellen kannst.
  • Deine Backend-API befindet sich parallel in Entwicklung, es ist unklar ob diese zeitlich fertig wird.
  • Du erwartest Freischaltungen von anderen Unternehmensabteilungen, bis die API verfügbar wird.
  • Du musst lokal ein Backend lange aufsetzen, diesen täglich updaten oder sogar deine Backend-Kollegen um Hilfe fragen, damit dein Frontend überhaupt dagegen entwickelt werden kann.
  • Obwohl das Storybook Framework eingesetzt wird und Komponenten teilweise gerendert werden, gibt es keinen Weg um die Gesamtanwendung schnell auszuführen
  1. Halte den Build kurzläufig: mit einer schnell integrierbaren Kopie der externen Umgebung, reduziert sich dein Build auf reine Javascript-Build-Updates.

Umsetzung

Zur Umsetzung ist vor allem zu sagen, dass es einfacher geht als es klingt, denn gute Werkzeuge gibt es bereits, wahrscheinlich hast du schon einige auch selbst gesehen.

  • das Schema der Domänen-Objekte (Attribute, Ihre Typen und Beziehungen zu anderen Datensätzen ), mittels JSON-Standard definiert

Grundlegendes zu JSON

Generell hat es sich bewährt JSON-Strukturen von vorne rein dynamisch aufzubauen.

Backend-Server

Nach der Datenverwaltung, möchte ich auf die eigentlichen Server-Lösungen eingehen, die unser Backend replizieren werden. Die Anforderung an dieser Stelle, ist es die Anwendung wie der Endbenutzer lokal auszuführen zu können, somit handelt es sich um einen manuellen End-User-Test, der am Ende der Test-Pyramide liegt. Wichtig ist es ausschliesslich HTTP Server zu nutzen um eben möglichst realitätsnah zu arbeiten. Die Mock-Bibliotheken wie „Nock“, halte ich an dieser Stelle für unpassend, weil Sie einen anderen Test Fokus haben und leider auch durch sich selbst sofort Komplexität erzeugen.

JSON-Server

Das Projekt JSON-Server ist der erste bewährte Kandidat eines lokalen HTTP-Servers. Dieser benötigt nur JSON-Dateien um schnell einen vollen REST-Service nachzubilden.

npm install -g json-server
{"posts": [
{ "id": 1, "title": "json-server", "author": "typicode" }
],
"comments": [
{ "id": 1, "body": "some comment", "postId": 1 }
]}
json-server --watch db.json
json-server --watch db.json –port 3004
json-server --watch db.json –port 3004 --routes routes.json

Middlewares

Auch eine Middleware kann angehängt werden, mit der du dann sehr viel Kontrolle über deine HTTP-Requests gewinnst. Mehr dazu findet man hier.

Express.js

Ist am Anfang klar, dass es ein grosses Projekt wird, man viele HTTP-Abläufe lokal nachstellen möchte, volle Kontrolle über Routing und Middleware braucht, so steht einem vollständigem Express.js als Server nichts im Weg. Dieser ist etwas grösser beim Aufsetzen, danach jedoch erfüllt es alle notwendigen Anforderungen und hat vollständige Funktionalität eines REST-Servers.

Frontend einbinden

Der Standard: Storybook

Ist unser Backend bereit, so müssen wir auch das Frontend selbst lokal ausführen. Der verbreitete Standard an dieser Stelle ist sicherlich das Storybook. Dieser ist meiner Meinung nach fast immer empfehlenswert. Sogar wenn man eine Single Page Application bauen muss, ermöglicht es Navigationspfade und Komponenten-Zustände zu definieren, ohne zu diesen immer wieder bei der Entwicklung navigieren zu müssen. Unschlagbar ist Storybook bei der Entwicklung von Komponenten-Bibliotheken, in Kombination mit dem Knobs-Plugin macht es ein Interaktives entwicklen mit sehr vielen Properties möglich.

Webpack-Dev-Server

Als das Standard Werkzeug zum Bündeln von Artifakten, bietet auch Webpack einen lokalen Server zur Entwicklung.

Simple HTTP Server

Natürlich kann ein beliebiger HTTP Server ebenfalls das Frontend lokal einbinden, mein eigener Favorit ist http-server. Dieser lässt sich sehr leicht installieren und starten.

Umgebungen definieren

Ein letzter Punkt den ich erwähnen möchte, ist die Praxis, die Laufzeit-Umgebungen von vorne rein klar zu definieren, dabei kann es bereits lokal, mehr als eine sein.

  • LOCAL-DEV — diese Umgebung geht direkt von dem Entwickler-Rechner gegen eine externe DEV-Umgebung somit variieren alle URLs und Konstanten
  • DEV, INT und PRD sind dann gewöhnliche Umgebungen die man aus anderen Projekten kennt, die sensitiven Konstanten hierfür werden dann auf der jeweiligen Umgebung separat eingebunden.

Überblick

Zusammenfassend entsteht in etwa die folgende Struktur bezüglich Umgebungen, JSON-Definition und API-Beziehungen. Bitte hier beachten dass es sich hierbei nur um eine abstrakte Skizze und kein valides UML handelt.

Fazit

Betrachtet man lokal-zuerst, so bietet es trotz des einfachen Prinzips einige Vorteile. Aus meiner Erfahrung war ich oft froh, den lokalen Setup einfach bei mir zu haben und betrachte es als die „Geheimwaffe“ eines vorausschauenden Entwicklers.