Agular in a microservices world

Angular in a
Microservices
world
Brecht Billiet
@brechtbilliet

Hi, I’m Brecht! I help
companies with web
technologies...
@brechtbilliet

I... A few references...
» Kickstart projects
» Give trainings/workshops
» Coach companies
» Do code-reviews
» Do audits
» Blog about stuff
http://blog.brecht.io
» Talk on meetups
» Help with architectural
decisions
@brechtbilliet

The structural evolution of web
software
@brechtbilliet

Web application
Frontend + Backend
(server-side rendering)
@brechtbilliet

We can do
this!
Web application
Frontend + Backend
@brechtbilliet

We can do
this!
We can
still do
this!
Web application
Frontend + Backend
@brechtbilliet

We can do
this!
We can
still do
this!
Err...
Web application
Frontend + Backend
@brechtbilliet

Frontend Web application
(spa)
REST
Backend Web application
@brechtbilliet

We can do
this!
We can do
this!
REST
(spa)
@brechtbilliet

We can
still do
this!
We can do
this!
We can do
this!
REST
We can
still do
this!
(spa)
@brechtbilliet

We can
still do
this!
We can do
this!
We can do
this!
REST
We can
still do
this!
Err...
Err...
(spa)
@brechtbilliet

Spotify engineering culture
» Autonomous teams
» Every team has its own
⋄ Ownership
⋄ Codebase
⋄ Build process
⋄ Deployment
» Choice of tech-stack
» Checkout these movies
» https://labs.spotify.com/
2014/03/27/spotify-
engineering-culture-part-
1/
» https://labs.spotify.com/
2014/09/20/spotify-
engineering-culture-part-
2/
@brechtbilliet

@brechtbilliet

» Hard to achieve on monoliths
Frontend monolith
REST
Backend monolith
@brechtbilliet

REST
Micro
Service
A
Micro
Service
Z
...
» Microservices
» https://martinfowler.com/articles/
microservices.html
This fixes all of the “Spotify engineering
culture” requirements
@brechtbilliet
Microservices

REST
Micro
Service
A
Micro
Service
Z
We can do
this!
We can do
this!
...
@brechtbilliet

REST
Micro
Service
A
Micro
Service
Z
...
Every team has
Its own ownership
Its code decoupled from the
rest
Its own codebase
Its own repository
Its own build process
@brechtbilliet

REST
Micro
Service
A
Micro
Service
Z
...
The frontend is still a monolith
@brechtbilliet

We want
» Code splitting
» Code sharing
» Decoupling
» Lazy loading
» Separate codebases
» To divide work in
different teams
» To give ownership to
specific teams
@brechtbilliet

REST
Micro
Service
A
Micro
Service
Z
...
We do still want a SPA (ux)
@brechtbilliet

REST
Micro
Service
A
Micro
Service
Z
...
SPA
module
A
But also want to give teams
ownership
SPA
module
Z
...
@brechtbilliet

Solution one
The iframe spa
@brechtbilliet

Did he say, IFRAMES?
@brechtbilliet

Iframe 1:
This belongs to team
A. It contains enough
code and business
logic to deserve its
own project
@brechtbilliet

Iframe 2:
B. This will be an even
bigger application
@brechtbilliet

Iframe 3:
C. This app will be
very specific
@brechtbilliet

Orchestrator app:
This application will
only do communication
@brechtbilliet

<!doctype html>
<html>
<head>
</head>
<body>
<iframe src="http://myapp.com/search"></iframe>
<iframe src="http://myapp.com/main"></iframe>
<iframe src="http://myapp.com/player"></iframe>
</body>
</html>
@brechtbilliet

How to communicate between the
iframes
// send a message from iframe to the orchestrator app for communication
window.parent.postMessage({type: 'PLAY_SONG', data: {'title': 'Michael Jackson -
Billy Jean'}}, '*');
@brechtbilliet

How to communicate between the
iframes
// send a message from iframe to the orchestrator app for communication
window.parent.postMessage({type: 'PLAY_SONG', data: {'title': 'Michael Jackson -
Billy Jean'}}, '*');
// send a message to the orchestrator app for communication
window.addEventListener('message', receiveMessage, false);
function receiveMessage(msg): void {
switch(event.data.type){
case 'PLAY_SONG':
// todo (set some label or whatever)
}
@brechtbilliet

Reactive is cooler =)
// get a stream from all messages
postMessage$ = Observable.fromEvent(window, 'message').map(res => res.data);
// get a stream of the 'PLAY_SONG' messages
playSongMessage$ = postMessage$.filter(item => item.type === 'PLAY_SONG');
@brechtbilliet

Advantages
» Great isolation of code => assign to specific
teams
» Not tied to specific framework
» Works with all different javascript technologies
» Independant deploys
» Ability to migrate old project easily
» Easy to plug-and-play in older projects
» AB-testing becomes a breeze
» No code conflicts
» Iframes have their own inside routing
@brechtbilliet

Tradeoffs
» Performance hit (manageable in most cases)
» CSS issues, tooltips behind the iframe, ...
» Drag and drop (can be fixed, but not native)
» Dependencies will be loaded multiple times
» Harder to share state
» Only works for block-shaped elements
@brechtbilliet

Use cases
» Legacy code bases: Add ng4 project into old app in 1 line
» Platforms
⋄ One application per tab
⋄ Multiple applications per tab
» Independant deploys of projects
Don’t overuse it!
@brechtbilliet

Summary
» Use it for specific projects (platforms, legacy
codebases)
» Becomes complex when too many shared state…
» Share backend changes over sockets
» Share state changes over document-events
@brechtbilliet

Solution two
Multiple angular apps
@brechtbilliet

Angular app Search:
Owned by Team A.
Exposes:
● Angular application
@brechtbilliet

Angular app Main:
Owned by Team B.
Exposes:
● Angular application
@brechtbilliet

Angular app Player:
Owned by Team C.
Exposes:
● Angular app
@brechtbilliet

Orchestrator app:
This application will do
orchestrating
@brechtbilliet

How to load multiple angular
apps
Ng4 app (cli)
Ng4 app (cli)
@brechtbilliet

apps
<!doctype html>
<html>
<head>
</head>
<body>

<script type="text/javascript" src="somesharedbundle/dist/inline.bundle.js"></script>

<script type="text/javascript" src="somesharedbundle/dist/polyfills.bundle.js"></script>
...
</body>
</html>
@brechtbilliet

apps
// create the DOM tag
document.body.appendChild(document.createElement('app-courses'));
// load the script from the dist folder
loadScriptsSync(['courses/dist/inline.bundle.js',
'courses/dist/vendor.bundle.js',
'courses/dist/main.bundle.js']);
// create the DOM tag
document.body.appendChild(document.createElement('app-users'));
// load the script from the dist folder
loadScriptsSync(['users/dist/inline.bundle.js',
'users/dist/vendor.bundle.js',
'users/dist/main.bundle.js']);
@brechtbilliet

apps
// It’s important that the script are loaded synchronous
function loadScript(path, cb) {
var scriptTag = document.createElement('script');
scriptTag.src = path;
scriptTag.onload = cb;
scriptTag.onreadystatechange = cb;
document.body.appendChild(scriptTag);
}
function loadScriptsSync(paths) {
loadScript(paths[0], () => {
loadScriptsSync(paths.filter(item => item !== paths[0]));
});
}
@brechtbilliet

Advantages
» You don’t need iframes to load multiple angular
apps
» You can easily divide the work between teams
» Independant deploys
@brechtbilliet

Tradeoffs
» No routing inside the child-apps
» Can’t have multiple instances of a child-app
» Not completely sandboxed
» Dependencies will be loaded multiple times
@brechtbilliet

Summary
» Some people are for it, some are against it
» A personal feeling: It feels a bit hacky
» You can use it when you hit the limitations of an
iframe (e.g css)
» Routing is impossible
@brechtbilliet

Solution three
Angular modules
@brechtbilliet

Angular module Search:
Owned by Team A.
Exposes:
● Angular module
● Example
environment
@brechtbilliet

Angular module Main:
Owned by Team B.
Exposes:
● Angular module
● Example
environment
@brechtbilliet

Angular module Player:
Owned by Team C.
Exposes:
● Angular module
● Example
environment
@brechtbilliet

Orchestrator app:
This application will do
mostly routing/lazy
loading
@brechtbilliet

Angular (>2) is made for large
apps
It’s build as a platform framework
It’s build for large teams (typescript, modules, DI)
Provides:
» Modules with great encapsulation
» Lazy loading
» Ahead-of-time compilation
» A CLI (to reduce the setup process to a minimum)
@brechtbilliet

Spotify-application
(orchestrator)
(angular application)
Search
(angular module)
Main
(angular module)
Player
(angular module)
Splitting up code to specific
teams
NPM
package
NPM
package
NPM
package
@brechtbilliet

Spotify-application
(orchestrator)
(angular application)
Search
(angular module)
Main
(angular module)
Player
(angular module)
Can be TS modules
as well...
NPM
package
NPM
package
NPM
package
Other x
(TS module)
Other y
(TS module)
NPM
package
NPM
package
@brechtbilliet

What does a module look like?
Every module has
» Its own package.json
» Its own build process
» Its own test
environment
» Its own versions
» Its own test suite
» Its own repo
(debatable)
So we can:
» Assign a specific team
» Have separate deploy
to specific NPM
registry
» Lazy load them
@brechtbilliet

The orchestration App:
Module
...
import { routing } from './routes';
import { SpotifySearchModule } from '@spotify-app/spotify-search'; // Npm package
import { SpotifyPlayerModule } from '@spotify-app/spotify-player'; // Npm package
@NgModule({
...
imports: [
routing, // here we lazy load our modules
SpotifySearchModule, // directly import the angular module from npm
SpotifyPlayerModule, // directly import the angular module from npm
BrowserModule,
...
]
})
export class MainModule {

The orchestration App:
Routing
import { PreloadAllModules, RouterModule } from '@angular/router';
export const routes = [
{
path: 'foo',
loadChildren: '../node_modules/@spotify-app/foo/#SpotifyFooModule'
},
{
path: 'bar',
loadChildren: '../node_modules/@spotify-app/bar/#SpotifyBarModule'
}
];
export const routing = RouterModule.forRoot(routes, {
preloadingStrategy: PreloadAllModules });
@brechtbilliet

Creating a child-module
» ng new spotify-player
» Rename src to testenv
» Create folder src, and move the source code there
» Change the .angular-cli.json root property in “app”
to “testenv”
@brechtbilliet

Just use the source code (no
build)
» Set the Package.json main property to src/index.js
index.js:
export {AppModule} from './app/app.module';
@brechtbilliet

Advantages
» Lazy loading out of the box
» Module system out of the box
» Creating projects is easy with the CLI
» Routing + child-routing works perfectly
@brechtbilliet

Tradeoffs
» For every module deploy you also have to deploy
the root application
» Bound to a framework (debatable)
» Not easy to combine with AOT
» Not completely sandboxed, but angular provides
great encapsulation
@brechtbilliet

Last solution
Bootstrap components
@brechtbilliet

Angular component
Search:
Owned by Team A.
Exposed by Angular module
Search
@brechtbilliet

Angular component Main:
Owned by Team B.
Exposed by Angular module
Main
@brechtbilliet

Angular component Player:
Owned by Team C. Exposed
by Angular module Player
@brechtbilliet

App (tech stack
doesn’t matter)
@brechtbilliet

Angular 1 app
<search>
</search>
<main>
</main>
<player></player>
Angular 4 app - spotify
@brechtbilliet

Use multiple bootstrap
components
<!doctype html>
<html>
<head>
</head>
<body>
<spotify-search>Loading search...</spotify-search>
<spotify-main>Loading main...</spotify-main>
<spotify-player>Loading player...</spotify-player>
</body>
</html>
@brechtbilliet

Use multiple bootstrap
components
@NgModule({
...
declarations: [SearchComponent, MainComponent, PlayerComponent],
imports: [BrowserModule],
bootstrap: [SearchComponent, MainComponent, PlayerComponent]
})
export class AppModule {
}
@brechtbilliet

Divide in teams again =)
import { SearchModule } from '@spotify-app/spotify-search';
import { MainModule } from '@spotify-app/spotify-main';
import { PlayerModule } from '@spotify-app/spotify-player';
@NgModule({
...
imports: [BrowserModule, SpotifySearchModule, SpotifyMainModule, SpotifyPlayerModule],
bootstrap: [SearchComponent, MainComponent, PlayerComponent]
})
export class AppModule {
}
@brechtbilliet

Advantages
» You can use multiple ng4 apps (as components) in
a non angular application
» You can combine it with the angular modules
approach (same advantages)
@brechtbilliet

Tradeoffs
» Iframes still provide better encapsulation
» No independant deploys (only to npm)
@brechtbilliet

Summary
» For me this is the most ideal solution
@brechtbilliet

Questions
Shoot!
@brechtbilliet

Credits
This template is free to use under Creative Commons Attribution license.
Thank you 4 having me!
@brechtbilliet
https://www.linkedin.com/in/brecht-billiet-58417426/
billietbrecht@gmail.com
http://brecht.io
http://blog.brecht.io
http://strongbrew.io
@brechtbilliet

Agular in a microservices world

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agular in a microservices world

Similar to Agular in a microservices world (20)

Recently uploaded

Recently uploaded (20)

Agular in a microservices world