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
Made with Slides.com