Frontend Integration
Benjamin Otto & Jörg Adler
Mercateo Gruppe
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
valid
commit
Event with Session ID
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
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
Frontend Integration
By joergadler
Frontend Integration
talk for https://meetup.com/de-DE/Softwerkskammer-Leipzig/events/254247591/
