Frontend Integration
Benjamin Otto & Jörg Adler
PRISMA European Capacity Platform GmbH
PRISMA Platform
- Europe’s leading gas capacity trading platform.
- We connect the European gas market.
- We provide a single platform through which infrastructure operators and shippers may auction transmission gas capacity
- 17 connected markets, 1700 network points, 40+ network operators
- we're insourcing our whole IT at the moment
- complete platform build on AWS
- We hire!
Wer sind wir
Jörg Adler, Senior Backend Developer
joerg.adler@prisma-capacity.eu
@joerg_adler
Benjamin Otto, DevOps Engineer
benjamin.otto@prisma-capacity.eu
@_otbe_
Fragen
Wer programmiert im Unternehmen Microservices?
Wer setzt auf Frontend - Monolithen?
Wer verteilt die (fachliche) Frontend - Verantwortung auf mehrere Teams?
Scenario
- Usecase: Registrierung einer neuen Firma
- nebst Namen ist auch Rechnungsadressen nötig
- Kundenstammdaten und Rechnungsstellung sind von verschiedenen Teams betreut
- Zunächst gibt bei der Rechnungsadresse keine Telefonnummer
- später soll die Telefonnummer der Buchhaltung verpflichtend für Rückfragen hinzugefügt werden
Submit
Company
Service
Invoice Service
CompanyId
Prinzip Hoffnung
Frontend aus einer Hand
Address
General Information
Submit
Address
General Information
Company
Service
Invoice Service
CompanyId
Prinzip Hoffnung Änderung
Frontend aus einer Hand
Frontend implementiert Telefonnr.
Backend implementiert
Telefonnr.
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
Address
General Information
Company
Service
Invoice Service
Frontend aus einer Hand
BFF
CompanyId
BFF Änderung
Frontend aus einer Hand
Submit
Transaction Settings
General Information
Company
Service
Invoice Service
BFF
Frontend implementiert Telefonnummer
Backend implementiert
Telefonnr.
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
Address
General Information
Company Service
Invoice Service
Eventstore
Event
Frontend aus einer Hand
Eigener Microservice
Submit
Address
General Information
Company Service
Invoice Service
Eventstore
Event
Frontend aus einer Hand
Frontend implementiert Telefonnr.
Backend implementiert
Telefonnr.
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
Company
Service
Invoice Service
CompanyId
Address
General Information
Verteiltes Frontend
Submit
Address
General Information
Company Service
Invoice Service
Session-Data
Eventstore
Session-Data
valid
valid
commit
Event with Session ID
Event with Session ID
Transaktionen
Ein Team implementiert Telefonnummer
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
- Erweiterung durch andere Teams bedeutet mehr Aufwand
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 @ 2019
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 JUG Saxony Day 2019
