Slide 1

Slide 1 text

Wait, what? Our microservices
 have actual human users? Stefan Tilkov, innoQ @stilkov

Slide 2

Slide 2 text

μS μS μS μS μS μS Frontend So you want to do microservices … What is this thing? What is this line? Is it the same as this one? Where does it run?

Slide 3

Slide 3 text

Challenging Assumptions

Slide 4

Slide 4 text

Assumption: Orchestration is cheap No.

Slide 5

Slide 5 text

“Really remote” vs. “almost local” μS μS μS μS μS μS Inside DC;
 Latency: μs Frontend Typically Internet;
 Latency: ms

Slide 6

Slide 6 text

“Backend for Frontend” μS μS μS μS μS μS BFF Frontend http://samnewman.io/patterns/architectural/bff/

Slide 7

Slide 7 text

Assumption: Channels matter Not as much as you think

Slide 8

Slide 8 text

Multiple BFFs for different clients μS μS μS μS μS μS BFF Frontend BFF Frontend BFF Frontend Imagine more arrows here

Slide 9

Slide 9 text

Multiple channels – facing every user Browse product Pick recommendation Buy Check status Comment

Slide 10

Slide 10 text

Users expect a seamless experience across channels
 – everything accessible, everywhere.

Slide 11

Slide 11 text

Build services that actually do something Process Flow Presentation Domain Logic Data JDBC in disguise Useful and specific Re-usable and low- level

Slide 12

Slide 12 text

Assumption: Services matter most (a.k.a. “SOAs Original Sin”) UIs matter more.

Slide 13

Slide 13 text

μS μS μS μS μS Frontend μS Frontend + services in a backend architect’s mind μS μS μS μS μS Frontend μS Frontend + services in the real world

Slide 14

Slide 14 text

Redundancy with Multiple BFFs μS μS μS μS μS μS Frontend A Frontend B Frontend C

Slide 15

Slide 15 text

Ideal world UI componentization μS μS μS μS μS μS FE μS μS FE Not all μS need a UI “Vertical”
 Responsibility

Slide 16

Slide 16 text

SCS: Self-contained Systems http://scs-architecture.org

Slide 17

Slide 17 text

Assumption: Frontend technology is an implementation detail Not at all.

Slide 18

Slide 18 text

Backend Platform More than one platform μS μS μS μS μS μS Frontend Platform FE μS μS FE

Slide 19

Slide 19 text

Microservices backend platform goals > As few assumptions as possible > No implementation dependencies > Small interface surface > Based on standards > Parallel development > Independent deployment > Autonomous operations Backend Platform

Slide 20

Slide 20 text

What’s the frontend platform analogy? > As few assumptions as possible > No implementation dependencies > Small interface surface > Based on standards > Parallel development > Independent deployment > Autonomous operations Backend Platform Frontend Platform

Slide 21

Slide 21 text

Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App Frontend, we’ve got frontends Frontend Hybrid

Slide 22

Slide 22 text

Web UI Integration: Links System 1 System 2

Slide 23

Slide 23 text

Web UI Integration: Redirection System 1 System 2

Slide 24

Slide 24 text

Web UI Integration: Transclusion System 1 System 2

Slide 25

Slide 25 text

Web UI Integration: Web Components? System 1 Component

Slide 26

Slide 26 text

The browser as a platform > Independent applications > Loosely coupled > Separately deployable > Based on standard platform > Updated on the fly > Any device Backend Platform Frontend Platform

Slide 27

Slide 27 text

How to get away with “just” the Web > Mobile first > Responsive design > Progressive enhancement > Shared assets > Pull vs. push > Sacrifice (some) efficiency Small frontends, loosely coupled

Slide 28

Slide 28 text

Simple two-step secret to improving the performance of any website, according to Maciej Ceglowski (@baconmeteor): “1. Make sure that the most important
 elements of the page download and
 render first. 2. Stop there.” http://idlewords.com/talks/website_obesity.htm

Slide 29

Slide 29 text

Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other approaches? Frontend Hybrid ✔ ✔ ✔ ?

Slide 30

Slide 30 text

Assumption: Frontend monoliths are OK Sometimes.

Slide 31

Slide 31 text

Native frontends resemble server monoliths Goals: > As few assumptions as possible > No implementation dependencies > Small interface surface > Based on standards > Parallel development > Independent deployment > Autonomous operations Constraint: > Only internal modularization Solution (sort of): > Organizational structure > Platform interfaces > Release trains > Discipline

Slide 32

Slide 32 text

Rendered on Client Rendered on Server Desktop Mobile Set top Web App Native App What about other “modern” web apps? Frontend Hybrid ✔ ✔ ✔ (✔) ?

Slide 33

Slide 33 text

Assumption: JS-centric web apps can
 be as good as native apps They shouldn’t be as bad!

Slide 34

Slide 34 text

“Web service”1) > Use HTTP as transport > Ignore verbs > Ignores URIs > Expose single “endpoint” > Fails to embrace the Web 1) in the SOAP/WSDL sense “Web app”2) > Uses browser as runtime > Ignores forward, back, refresh > Does not support linking > Exposes monolithic “app” > Fails to embrace the browser 2) built as a careless SPA

Slide 35

Slide 35 text

The web-native way of distributing logic Process Flow Presentation Domain Logic Data Server Client > Rendering, layout, styling
 on an unknown client > Logic & state machine on server > Client user-agent extensible via
 code on demand

Slide 36

Slide 36 text

HTML & Hypermedia > In REST, servers expose a hypermedia format > Option 1: Just use HTML > Option 2: Just invent your own JSON-based, incomplete clone > Clients need to be RESTful, too > Option 1: Use the browser > Option 2: Invent your own, JS-based, buggy, incomplete implementation

Slide 37

Slide 37 text

$('.multiselect', context).each(function() {
 $(this).multiselect({
 selectedList: 2,
 checkAllText: "Alle",
 uncheckAllText: "Keinen"
 }).multiselectfilter({label:"",
 width:"200px"});
 });

 Project
 
 DISCOVER
 IMPROVE
 MAGENTA
 ROCA
 ROCKET
 


Slide 38

Slide 38 text

Why choose a monolith if you don’t have to? Any sufficiently complicated JavaScript client application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half a browser. (Me, with apologies to Phillip Greenspun)

Slide 39

Slide 39 text

ROCA: Resource-oriented Client Architecture http://roca-style.org

Slide 40

Slide 40 text

Disclaimer: Not a fan of SPAs (see https://medium.com/p/f08bb4ff9134 If you’re a fan of single page apps,
 at least build more than one > Don’t reinvent browser integration features > Accept some inefficiency > Trade-off for framework independence > Avoid modularity à la Java EE, OSGi etc.

Slide 41

Slide 41 text

Summary

Slide 42

Slide 42 text

Few organizations are in the business of delivering APIs – UIs matter

Slide 43

Slide 43 text

Frontend monoliths are just as good, or bad, as backend monoliths

Slide 44

Slide 44 text

Nothing beats the browser with regards to modular frontend delivery

Slide 45

Slide 45 text

Stefan Tilkov
 [email protected]
 Phone: +49 170 471 2625 innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstraße 16
 80331 München Germany Phone: +49 2173 3366-0 Thank you. Questions?
 Comments? @stilkov Image credit: The Noun Project
 Marek Polakovic, Arthur Shlain, Karthick Nagarajan