Du bist nicht mit dem Internet verbunden.
Corporate logo
ComputingNews & Trends 1537

Team Isotopes: Die Speed Demons des Engineerings

Wenn es um rohe Geschwindigkeit geht, bewegt sich das Engineering Team Isotopes in einem Spannungsfeld aus Mensch, Maschine und Zukunft. Sie geben einen Einblick in ihre Arbeit.

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.

Aus den Archiven: Unser alter Shop

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.

Nur durch gutes Überlegen und Planen schaffen die Isotopes Geschwindigkeit

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.»

Wegbereiter: Die Isotopes machen sich auf in unbekannte Gewässer und erfinden den digitec-Shop neu

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.

Damian Frizzi (vorne) und die Isotopes vor dem Go-Live am Ende eines Sprints. Die Spannung steigt

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:

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.

User
Journalist. Autor. Hacker. Ich bin Geschichtenerzähler und suche Grenzen, Geheimnisse und Tabus. Ich dokumentiere die Welt, schwarz auf weiss. Nicht, weil ich kann, sondern weil ich nicht anders kann.

15 Kommentare

Bitte melde dich an.

Du musst angemeldet sein, um einen neuen Kommentar zu erfassen.


User Anonymous

Cool, bei meinem Auftrag hab ich fast das gleiche Setup am laufen..

07.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User Anonymous

Der Unterschied liegt nur an der Rest API und Openshift.
Was macht ihr mit eurer ...ich rate mal.. elastic search suche..eurer Power Suche? Integriert ihr auch ML und wie geht Ihr um mit SEO? Ist PWA auch im Fokus?

07.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User removetere

ja neu setzen wir auf Elastic Search und auch ML ist ein Thema, allerdings noch am Anfang. SEO ist uns auch sehr wichtig, weshalb SSR (server side rendering) ein absolutes killer kriterium für unsere Evaluation war. Der Stack ist so aufgebaut dass wir in Zukunft immer mehr in Richtung PWA gehen können - das finden wir auch sehr spannend.

08.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User Anonymous

Danke für dein Feedback. An der Google IO und Microsoft Build wurden und wird noch PWA gezeigt. Scheint im kommen zu sein.Alle Major Browser unterstützen es.. gemäss was die sagen.
Werde ihr auch react-native verwenden/ausprobieren?

09.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User Anonymous

Ich hab mir schon überlegt anstatt einen reinen ML und elastic zu verwenden ein RNN zu erstellen. Wo man für die suche und dann für einen Intelligenten Assistent brauchen könnte. Hab da ein paar Ideen, bin aber noch nicht dazu gekommen. Zuerst muss ich einen grossen und qualitativ guten Katalog finden.

09.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User removetere

wow klingt interessant was du da baust :) ich bin selber kein profi in diesem umfeld welches du da beschreibst - aber wenn du zu uns kommst, hätten wir sicher einen qualitativ guten Katalog für dich :P Und ja, react-native ist definitiv auch auf unserem Radar - allerdings haben wir noch alle Hände voll zu tun den Online-Shop selbst auf den neuen Stack zu hieven bevor wir uns damit beschäftigen werden.

09.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

Antworten
User pcganzclaus

an eurem nerd-look müsst ihr aber noch arbeiten!

abercrombie and fitch ... pfff ... da passt doch kein echter IT-ler rein ... der junge isst eindeutig zu viel obst und gemüse ...

also aussortieren! shirt oder mitarbeiter oder speiseplan ... :)

07.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User pcganzclaus

das ganze team sieht mir nach verdächtig viel freizeit aus ... :p

07.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User removetere

work hard, party hard ;)

07.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

User Anonymous

Wir haben 2018... die 90er sind vorbei. Just FYI

08.05.2018
Missbrauch melden

Du musst dich anmelden um einen Missbrauch zu melden.

Antworten