MICROSERVICEWEBSITES

Gustaf Nilsson Kotte

@gustaf_nk

Mobile devicesThe problem

How can we develop a website with multiple teams?

Different business units need to make a website together that should feel like “one website” for the end-user.

Example: Retail domain

Products, Shopping cart, Checkout, Recommendations, Reviews, User profile, Editorial content, etc...

The problem

Decentralized services but centralized web?

Frontend

Bottleneck

Services should have their own frontend!

Stefan Tilkov et al, “Self-Contained Systems”

Frontend Frontend FrontendFrontend

Enables continuous delivery

Decentralized governanceAn option for teams to choose different tools → heterogeneous/plural/diverse system

High rate of change on the frontendAllows the system to evolve over time

James Lewis & Martin Fowler, “Microservices: Decentralized Governance”

Addy Osmani, “JavaScript Start-up Performance”

Mobile device performance

Constraints (need to support)

Continuous deliveryDecentralized governanceGood performance on mobile devices

Microservice Websites

Mobile devicesAnalysis

INTEGRATION USE CASEShopping cart

How can we reuse the shopping cart between different parts of the web site?

“Many-to-one”

Multiple teams – one shopping cart

INTEGRATION USE CASELanding page

The web site’s landing page is the page with the most amount of traffic and many business units want to be represented there.

“One-to-many”

Multiple teams – one landing page

Integrating on...

What (data/code/content)When (build/run)Where (client/server)

Cartesian product → 12 combinations

Let’s go through them!

Analysis

What × when × whereWhat? When? Where?

Data (APIs) Build Client

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client

Server

Run Client

Server

Content (HTML) Build Client

Server

Run Client

Server

What × when × where

What × when × whereWhat? When? Where?

Data (APIs) Build Client No reuse at all, only API usage

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client

Server

Run Client

Server

Content (HTML) Build Client

Server

Run Client

Server

What × when × where

What × when × whereWhat? When? Where?

Data (APIs) Build Client No reuse at all, only API usage

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client No continuous delivery. No diversity + mobile performance.

Server

Run Client

Server

Content (HTML) Build Client

Server

Run Client

Server

What × when × where

What × when × whereWhat? When? Where?

Data (APIs) Build Client No reuse at all, only API usage

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client No continuous delivery. No diversity + mobile performance.

Server

Run Client No diversity + mobile performance.

Server N/A

Content (HTML) Build Client

Server

Run Client

Server

What × when × where

What × when × whereWhat? When? Where?

Data (APIs) Build Client No reuse at all, only API usage

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client No continuous delivery. No diversity + mobile performance.

Server

Run Client No diversity + mobile performance.

Server N/A

Content (HTML) Build Client

Server

Run Client

Server

What × when × where

What × when × whereWhat? When? Where?

Data (APIs) Build Client No reuse at all, only API usage

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client No continuous delivery. No diversity + mobile performance

Server

Run Client No diversity + mobile performance.

Server N/A

Content (HTML) Build Client N/A

Server “Static page fragments” – ok, but limited amount of use cases

Run Client

Server

What × when × where

What × when × whereWhat? When? Where?

Data (APIs) Build Client No reuse at all, only API usage

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client No continuous delivery. No diversity + mobile performance.

Server

Run Client No diversity + mobile performance.

Server N/A

Content (HTML) Build Client N/A

Server “Static page fragments” – ok, but limited amount of use cases

Run Client Client-side transclusion

Server Server-side transclusion

What × when × where

What? When? Where?

Data (APIs) Build Client No reuse at all, only API usage

Server

Run Client

Server

Code (JavaScript, PHP, etc) Build Client No continuous delivery. No diversity + mobile performance.

Server

Run Client No diversity + mobile performance.

Server N/A

Content (HTML) Build Client N/A

Server “Static page fragments” – ok, but limited amount of use cases

Run Client Client-side transclusion

Server Server-side transclusion

What × when × whereWhat × when × where

Mobile devicesTransclusion

Transclusion

“transclusion is the inclusion of part or all of an electronic document

into one or more other documents by hypertext reference” (Wikipedia: Transclusion)

Producer

Expose a fragment resource, "/retail/shopping-cart/"

Consumer

Include the fragment declaratively, similar to <img src="..." />

Transclusion can be used both on server and clientExamples: Edge-Side Includes (server) and <h-include> (client)

No relative URLs in fragments!

<img src="images/relative-does-not-work.png" />

<img src="/images/root-relative-often-works.png" />

<img src="https://image-resources.jayway.com/images/absolute-always-works.png" />

...because URLs are relative to the consumer’s context (not the producer’s)

Edge Side Includes (server)

<-- Include the shopping cart component -->

<esi:include src="/retail/shopping-cart/" />

ESI 1.0 proposal submitted to W3C 2001

CDN support: Akamai, Fastly

On-premise support: Varnish, Squid, nodesi, etc

<h-include> (client)

<h-include src="/retail/shopping-cart/"></h-include>

Custom Elements version of hinclude.js (by Mark Nottingham, 2006)

Difference: interface and transitive includes

HTTP/2 → Bundles multiple xhr requests into one

Both support refresh()

ESI (server)

+ SEO+ JS/CSS in responses works as usual+ Initial performance+ Cross-domain requests

- Extra infrastructure investment- Dev perspective (+ i.e. nodesi)

- No streamed responses ⇒ blocking- Performance sensitive (+ timeouts)

- No header forwarding (+ configuration)

Server transclusion vs client transclusion

h-include (client)

- No SEO- No loading of JS/CSS in responses- Delay before xhr requests arrive- No cross-domain requests (unless CORS)- If no initial width/height, page will “jump”

+ No extra infrastructure investment+ No extra dev setup+ Async ⇒ non-blocking+ Responses are rendered when they arrive+ Headers work as usual in browsers

ESI and h-include together (1)// Refresh-only h-include

var proto = Object.create(HIncludeElement.prototype);

proto.attachedCallback = function() { /* do nothing */ };

document.registerElement('h-include-refresh-only', {

prototype: proto,

});

⇒ <h-include-refresh-only src="...">REFRESHABLE CONTENT HERE</h-include-refresh-only>

h-include-refresh-only

⇒

ESI and h-include together (2)// Lazy-loading with hunt.js

window.addEventListener('load', function() {

// For these elements...

hunt(document.getElementsByTagName('h-include-refresh-only'), {

// ...when they’re almost in the viewport...

offset: 400,

// ...load them!

in: function() {

this.refresh();

},

});

});

Constraints (need to support)

Continuous deliveryDecentralized governanceGood performance on mobile devices

Rules for integration

Transclude server-side resources

Microservice Websites

Mobile devicesClient-side

dependencies

Shopping cart HTML, check!

But, what about...

Additional client-side behavior? (JavaScript)Design? (CSS)

How to import service dependencies

Still need cache busting (i.e. /retail/shopping-cart/scripts-aef419.js)

Server-side transclusion works well here

Client-side transclusion require either 1) HTTP redirects, or 2) “loaders” like little-loader for JS and loadCSS

for CSS. Both options are less performant than using server-side transclusion, because of extra client/server

roundtrips.

<head>

...

<!-- Include shopping cart resources (cache-busting-as-a-service) -->

<esi:include src="/retail/shopping-cart/resources/" />

<!-- (scripts go in head too, if defer attribute is used) -->

...

</head>

<body>

...

<-- Include the shopping cart component -->

<esi:include src="/retail/shopping-cart/" />

...

</body>

Load dependencies (before transclusion)

http://caniuse.com/#feat=script-defer, https://www.html5rocks.com/en/tutorials/speed/script-loading/

<head>

...

<!-- Include shopping cart resources (cache-busting-as-a-service) -->

<link rel="stylesheet" src="/retail/shopping-cart/style-ffc864.css" />

<script defer src="/retail/shopping-cart/scripts-aef419.js"></script>

<!-- (scripts go in head too, if defer attribute is used) -->

...

</head>

<body>

...

<-- Include the shopping cart component -->

<div class="shopping-cart">Hello, shopping cart</div>

...

</body>

Load dependencies (after transclusion)

Client-side dependencies: JavaScript

No assumptions of consuming services’ client-side dependencies

⇒ Vanilla JS + polyfills (neither are “free”, so use both with care)

Custom Elements simplifies the lifecycle of components

https://github.com/WebReflection/document-register-element (5 KB)

Client-side dependencies: CSSDisclaimer: I’m not a CSS expert

Large-scale CSS development is hard (but what’s the alternative?)

Styleguide

Namespacing/components/responsive/flexible

Good news: others have this problem too (i.e. “multi-team SPAs”)

Small global dependency for resets and typography (optional)

Constraints (need to support)

Continuous deliveryDecentralized governanceGood performance on mobile devices

Rules for integration

Transclude server-side resources

No global client-side dependencies

Microservice Websites

Mobile devicesSummary

Services should have their own frontend!

Frontend Frontend FrontendFrontend

Integration: Transclusion

Constraints (need to support)

Continuous deliveryDecentralized governance (otherwise: “occasional” rewrites)

Good performance on mobile devices

Rules for integration (free to use JS frameworks internally, but not for exported fragments)

Transclude server-side resources

No global client-side dependencies

Microservice Websites

Further resources

Microservice Websites, Gustaf Nilsson KotteMicroservices, James Lewis & Martin FowlerSelf-Contained Systems, Stefan Tilkov et al.Architecture Without an End State, Michael NygardJavaScript Start-up Performance, Addi Osmani

Also, this is a great book:

I’ll happily chat on twitter: @gustaf_nk