Frontend Integration

Benjamin Otto & Jörg Adler

Mercateo Gruppe

Europas führende Beschaffungsplattform (B2B-Onlineshop)
mehrere Tausend Lieferanten
hunderte Millionen Artikel

zur Zeit Neuaufbau der Transaktionsplattform
komplett AWS
komplett losgelöst vom Bestandssystem
We hire!

Wer sind wir

Jörg Adler, Softwareentwickler

joerg.adler@mercateo.com

@joerg_adler

Benjamin Otto, Softwareentwickler

benjamin.otto@mercateo.com

@_otbe_

Fragen

Wer programmiert im Unternehmen Microservices?

Wer setzt auf Frontend - Monolithen?

Wer verteilt die (fachliche) Frontend - Verantwortung auf mehrere Teams?

Scenario

Wir erstellen einen neuen Business-Shop
neben Name und Beschreibung sind auch Abwicklungsinformationen für Bestellungen nötig
Bestellungen und Businessshops sind in verschiedenen Teams implementiert
Abwicklungsinformationen enthalten zunächst nur Mailadresse
Business-Shops wird später um einen Kontakt erweitert (Pflicht)

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

ShopId

Prinzip Hoffnung

Frontend aus einer Hand

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

ShopId

Prinzip Hoffnung Änderung

Frontend aus einer Hand

Frontend implementiert Kontakt

Backend implementiert

Kontakt

Sprint/Release Koordination

Pros

schnelle Erstimplementierung
einheitliches UX/UI

Cons

inkonsistente Daten
- "verteilte Transaktion" am Client
- Tunneleffekt
Kommunikation zwischen allen beteiligten Teams

Prinzip Hoffnung

Frontend aus einer Hand

Backend for Frontend

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

Frontend aus einer Hand

BFF

BFF Änderung

Frontend aus einer Hand

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

BFF

Frontend implementiert Kontakt

Backend implementiert

Kontakt

Sprint/Release Koordination

Backend for Frontend

Frontend aus einer Hand

Pros

Usecase bezogene Ressourcen
Legacy Systeme können eingebunden werden
nichtfunktionale Anforderungen (Auth) im BFF umgesetzt
im BFF nur Ablauflogik
Schutz des Clients vor Breaking Changes im Backend
einheitliches UI/UX

Cons

inkonsistente Daten (geringere Wahrscheinlichkeit)
höherer Kommunikation- und Releaseaufwand

Eigener Microservice

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

Eventstore

Event

Frontend aus einer Hand

Eigener Microservice

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

Eventstore

Event

Frontend aus einer Hand

Frontend implementiert Kontakt

Backend implementiert

Kontakt

Backend versteht Event in mehreren Versionen

Eigener Microservice

Frontend aus einer Hand

Pros

Kapselung des Usecases in einem Service -> Daten sind immer konsistent
Anforderungen von Außen an das Formular sind schneller umgesetzt
Entkoppelung der Backend-Services vom Formular

Cons

höherer Kommunikation- und Releaseaufwand
- Änderungen in den Abhängigen Services ziehen Änderungen in mind. 3 Komponenten nach sich
- wo "lebt" das Domainmodell (technisch/personell)

Verteiltes Frontend

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

ShopId

Verteiltes Frontend

Submit

Transaction Settings

General Information

BusinessShop Service

Transaction Service

Session-Data

Eventstore

Session-Data

valid

commit

Event with Session ID

Transaktionen

Verteiltes Frontend

Pros

Team mit dem meisten Verständnis für die Domain kann auch den Formularteil pflegen
Nach anfänglichem Einbinden der Komponenten weitestgehend unabhängige Entwicklung möglich

Cons

Protokoll muss von allen verstanden werden
alle nötigen Schritte müssen ins Formular eingebunden werden

Transaktionen

Verteiltes Frontend

Serverside includes (über Links)
Clientside includes (über Links)
Problematisch bei verschiedenen Versionen und kompletter Teamautonomie
- kleinster gemeinsamer Nenner: Plain JS und HTML
- Einigung auf Framework und Aussehen nötig

Integration

Frontend

Welche Faktoren sprechen für eine gute Integration?

einheitliches UI
einheitliche UX Flows
unabhängige Entwicklung in den Teams
...

-> mindestens für Customer facing Apps

Was können wir beeinflussen?

Wie wird UI gebaut?
- Komponentenbasiert?
- Wo wird welche Komponente in welcher Version verwendet?
- Wer baut diese Komponenten?
Ladeverhalten
- first hit
- wechsel zwischen mehreren Teilanwendungen

Maximale Unabhängigkeit

app1

app2

app3

button

1.0.0, 1.1.0, 2.0.0

icon

1.0.0, 1.1.0, 2.0.0

dropdown

1.0.0, 1.1.0, 2.0.0

Wir @ 2014

Maximale Unabhängigkeit

Teams sind unabhängig in jeder Hinsicht

jeder Domainwechsel lädt alle Abhängigkeiten nochmal
Update von Komponenten mühsam; jede App/Komponente hat ihre eigene CI
Welche Komponente wird wo in welcher Version verwendet? (UI)
Wer hat den Hut für UI auf? Wer darf Komponenten ändern?

Pros

Cons

AppShell & Monorepo

app1

app2

app3

button

1.0.0, 1.1.0, 2.0.0

icon

1.0.0, 1.1.0, 2.0.0

dropdown

1.0.0, 1.1.0, 2.0.0

Wir @ 2017

AppShell & Monorepo

Frameworks werden nur einmal geladen
Domain Code wird ondemand nachgeladen
weniger Permutationen an Abhängigkeiten als vorher möglich

Teams müssen sich koordinieren (CI/CD)
Wer hat den Hut für UI auf? Wer darf Komponenten ändern?

Pros

Cons

AppShell & Monorepo v2

app1/

app2/

app3/

button/

icon/

dropdown/

Wir @ 2018

AppShell & Monorepo v2

Frameworks werden nur einmal geladen
Domain Code wird ondemand nachgeladen
überall wird der selbe "Button" verwendet
update von Frameworks geschieht an einer Stelle
ein dediziertes Team gibt Basiskomponenten und UX Flows vor

Teams müssen sich koordinieren (CI/CD)

Pros

Cons

Q & A

We hire!

Lizenz

Diese Folien stehen unter CC BY-SA 4.0 Lizenz

https://creativecommons.org/licenses/by-sa/4.0/

Bildernachweis

https://upload.wikimedia.org/wikipedia/commons/4/42/Subway_train_in_tunnel.jpg