Team Isotopes: Die Speed Demons des Engineerings

Damian Frizzi sitzt auf den von der Sonne gewärmten Betonsteinen vor den digitec Offices. Sonnenbrille, graues T-Shirt. Er wirkt entspannt, spricht langsam, scherzt dann und wann wieder, schweift vom Thema ab. Sein Thema sind Millisekunden, Technologie und etwas Orakelei.

Damian ist der Leiter des Frontend Engineering und Mitglied des Teams namens «Isotopes», benannt nach der Baseball-Mannschaft des fiktiven Springfields aus «The Simpsons». Er und sein Team, acht Engineers, arbeiten jeden Tag daran, den Shop noch schneller zu machen. Dabei suchen sie nicht das eine Ding, das Verzögerungen von zehn Sekunden beseitigt, sondern Millisekunden. Wenn ein Prozess nicht so verschlankt wurde, dass keine Millisekunde Rechenzeit verschwendet ist, dann summiert sich das auf digitec.ch.

Aktuell arbeiten die Isotopes an einem Mammutprojekt: Sie wollen den ganzen Shop umstellen.

Ein Blick in die Geschichte: Wie Shops anno dazumal funktionierten

«In den prähistorischen Zeiten des Web 1.0 funktionierten Webseiten anders als heute», sagt Damian mit einem verschmitzten Grinsen auf dem Gesicht. Denn damals, etwa Ende der 1990er-Jahre, hat dieses Zeitalter geendet. Prähistorisch? Mitnichten. Aber trotzdem schon weit entfernt. Menschen, die 1999 geboren wurden, dürfen seit vergangenem Jahr die Autoprüfung ablegen. 1999 ist auch zum ersten Mal der Begriff «Web 2.0» gefallen.

Webseiten von damals funktionieren so: Du schickst einen Request, auf Deutsch: eine Anfrage, an eine Website, der Server rechnet, der Server schickt dir eine komplette Seite zurück. Dann klickst du einen Link, der Server berechnet dir die Seite wieder neu, schickt dir wieder eine komplette Seite. Das bedeutet, dass bei jedem Klick auf einer Website eine neue Seite geladen wird. Dieser Vorgang nennt sich Page Reloads oder Server Side Rendering (SSR) und führt unter Umständen dazu, dass dem Benutzer Daten erneut geschickt werden, die er bereits angefragt hat. Dies führt zu längeren Ladezeiten beim Navigieren auf der Webseite.

Zu langsam für den User und viel zu langsam für die Isotopes.

Dieses sogenannte Server-Side-Rendering war lange die beste Möglichkeit um Webseiten umzusetzen, da JavaScript noch nicht so weit entwickelt war wie heute. JavaScript, dessen Zweck die erweiterte Dynamik von Webseiten ist, ermöglichte zu Beginn des Web 2.0 jedoch nicht viel mehr als Bild-Diashows oder Datumsauswahl-Widgets.

Die Jahre vergingen und die Entwicklung von immer leistungsfähigeren Webseiten und Darstellungen haben das traditionelle Web an seine Grenzen gebracht. Heutzutage erwarten Kunden vollständig ausgestattete Anwendungsplattformen. Mit schnellen JavaScript-Laufzeiten und HTML5-Standards, die reichhaltige Anwendungen anzeigen. Sprich: All das, was du dich vom Internet gewöhnt bist. Denn JavaScript und HTML5 sind schon lange kein Luxus mehr, sondern die Basics.

«Das war der Moment, als Entwickler ihren Fokus geändert haben», sagt Damian. Immer mehr sei die Rechenleistung vom Server zum Client, also zu deinem Computer gewandert. Sogenannte Single Page Applications mit Client Side Rendering ermöglichen die direkte Interaktion mit der Website ohne Umweg via Server.

Damian kommt ins Erklären: «Single-Page-Applications sind Anwendungen, welche auf einer minimalen HTML-Struktur aufbauen und Daten – auf den User und seine Umgebung massgeschneidert – asynchron im Browser nachladen.»

So weit klingt das gut, aber hier setzt die Arbeit der Isotopes ein. Selbst asynchroner Datentransfer, obwohl schneller als kontinuierliches Server Side Rendering, bringt Hindernisse, Herausforderungen und Eigenheiten. Damian erwähnt den Google Crawler, ein kleines Programm, das das Web nach neuen Inhalten durchsucht. Der kann client-seitig laufende Sites nur bedingt verarbeiten. Die offizielle Empfehlung von Google ist, den relevanten Inhalt der Seite direkt mit auszugeben und nicht nachzuladen. Ansonsten droht eine Herabstufung der Relevanz und die Seite erscheint weiter unten in den Suchresultaten.

Ebenfalls kritisch ist die initiale Performance. Da auf dem Client der gesamte Document Object Model (DOM), die Architektur einer Site, aufgebaut wird, braucht es eine gewisse Zeit, bis die Daten beim Server angefragt, verarbeitet und gerendert wurden.

«Das kann vor allem bei Clients mit wenig Rechenleistung, alten Smartphones zum Beispiel, oder bei einer schlechten Internetverbindung, zu langen Ladezeiten führen», sagt Damian.

Dabei entstehen die schier endlos dauernden Ladeanimationen beim ersten Laden der Seite.

Der isotopische Weg

Die Isotopes bewegen sich in diesem Spannungsfeld zwischen Anforderungen der Nutzer – also deinen Anforderungen – und jenen der Technologie. Zudem: Google. Der Suchmaschinengigant darf natürlich auch ein Wörtchen mitreden, ob es den Isotopes passt oder nicht.

«Wir wollen eine Mischung aus dem neuen und dem traditionellen Ansatz: Wir wollen bei der initialen Anfrage ein vollwertiges HTML-Dokument vom Server zurückliefern damit die Ladezeit so gering wie möglich bleibt und Google und Co. weiterhin unsere Inhalte vollständig crawlen können», Damian holt kurz Luft. Er ist in seinem Element, redet schnell und atmet weniger ein. «Zusätzlich wollen wir aber bei der weiteren Navigation innerhalb unserer Applikation von dem Performance Boost einer SPA profitieren.»

Die Isotopes haben sich hingesetzt und mit universell renderbaren Anwendungen experimentiert. Sprich: Egal ob Mensch oder Crawler, die Seite ergibt Sinn und kann von einer Maschine gelesen, kategorisiert und bewertet werden. Dazu muss die Darstellungslogik sowohl auf einem Server als auch einem Client einwandfrei funktionieren. Das hat seine Vorteile.

«Wir sparen uns nicht nur den Mehraufwand, der durch die Entwicklung für eine Umgebung entsteht, sondern können auch gezielt steuern, welche Inhalte wann geladen werden sollen», erklärt Damian.

Um dieses Ziel zu erreichen, müssen grundsätzlich zwei grössere Probleme gelöst werden:

1. Isomorphic Universal Frontend: Die Isotopes müssen ein Frontend aufbauen, das sowohl von einem Server als auch von einem Browser verarbeitet, gerendert und als unabhängige Einheit in die Cloud deployed werden kann
2. Daten nachladen: Sie müssen im Frontend Daten von einer beliebigen unabhängigen Schnittstelle konsumieren, temporär persistieren und darstellen können

Nach den Experimenten und der Definition der Anforderungen, Wünsche und Grenzen, geht es für das Team um Damian Frizzi ans Eingemachte. Zeit, einen Webshop neu zu erfinden.

Universal Frontend

Die Isotopes stürzen sich in den Kampf. Die Rendering Engine steht schnell fest: React, von Facebook entwickelt. Sowohl Facebook als auch Instagram nutzen die JavaScript Library und performen dort sehr gut. React, manchmal auch React.JS oder ReactJS genannt, unterstützt Rendering auf der Seite des Clients und des Servers, hat eine grosse Community hinter sich und wird breit von Mensch wie Maschine akzeptiert. Dazu löst es genau nur ein Problem: Das Rendering und damit die Interaktion mit dem DOM.

«Zu allerletzt, React ist sehr effizient. Mit virtuellem DOM und gezielten Patches.»

Zu React gesellt sich Node.js auf der Serverseite. Das sei naheliegend, sagt Damian. So können die Isotopes in JavaScript programmieren und profitieren von bestehendem Know-How.

Daten nachladen

APIs, also Programmschnittstellen sind beim Nachladen von Daten der Schlüssel zum Erfolg. Die Isotopes um Damian haben hier erstmal die Gegenwart einzuholen.

«Aktuell stellen wir alle Schnittstellen auf Web APIs um», sagt er. Den Seufzer kann er kaum unterdrücken. Denn die Umstellung gestaltet sich nicht ganz einfach. Es entsteht eine Vielzahl an Schnittstellen, die vom Client angefragt werden müssen. Um zu verhindern, dass jeder User eine Unmenge von Anfragen an die digitec-Backend-Server schicken muss, haben wir uns für einen GraphQL Layer zwischen Frontend und Backend entschieden.

Die Vorteile sind klar: Der Client – also der Computer des Users – muss nur einen Endpoint anfragen und die Frontend-Entwickler müssen sich nicht mit der Implementierung der Schnittstellenanfragen auseinandersetzen. Der GraphQL-Server nimmt anhand von Queries und Schema Resolvers eine Reduzierung der Daten auf ein Minimum vor. Dadurch werden zwischen Client und GraphQL Server nur die wirklich benötigten Daten ausgetauscht. Dies ist vor allem bei langsamen Internetverbindungen ein Vorteil. Damian blickt in die Zukunft: «Wir werden später die Daten auf der GraphQL-Ebene cachen.» So werden die Anfragen an die Schnittstellen reduziert und der Client erhält noch schneller Antwort.

Geschwindigkeit. Die Isotopes suchen sie.

Damian fasst den Kern des aktuellen Technologiestacks digitecs zusammen:

1. JavaScript (ES2015, ES2016)
2. Node.js
3. React
4. Next.js
5. GraphQL
6. Apollo
7. Enzyme
8. Jest
9. Docker
10. Azure
11. Kubernetes
12. ASP.NET Web API

Daraus entsteht ein Prototyp, also der Ort, wo die Sache spannend wird.

Ein Blick auf den Prototypen

«Verwirrt? Kein Problem. Schau dir mal diesen Prototypen an», sagt Damian. Die verbesserte Performance werde erst offensichtlich, wenn sie gesehen werde.

Damian ist stolz: «Und genau das machen die Isotopes.»

Das Resultat aus dem Prototypen wird demnächst online gehen.

Apropos: Team Isotopes will dich wissen lassen, dass unser Engineering Verstärkung sucht. Wenn du mitmischen willst, dann sieh dir doch bitte folgende offene Stellen an:

• Junior Software Engineer
• Software Engineer
• Senior Software Engineer
• Technical Lead / Cloud Architect
• Teamleader Software Engineering

Zusätzlich gibt es noch weitere Stellen im Engineering hier.

Wenn du noch mehr dazu erfahren möchtest wie bei uns entwickelt wird dann schau doch noch hier rein.