4. Introduction
Brands and Sites
⢠5 Brands/Channels for target audiences
⢠1-15 Sites for different geographical regions
⢠Strong domains
www.agame.com for teens in the US
www.games.co.uk for families in the UK
www.juegosdechicas.com for girls in Spain
...
4/30
7. Old Portals Landscape
⢠Monolithic portals per brand
⢠Static pages with lots of AJAX
calls
⢠Architectural layers developed
independently
7/30
8. Old Portals Landscape
What Was Good. . .
⢠Acceptable performance
⢠Clear layer separation
⢠Fast growth
⢠Per brand & site development
⢠Small learning curve
8/30
10. Old Portals Landscape
. . . And What Wasnât
⢠Extensive frontend caching
⢠No global features
⢠Lots of logic on the client
⢠Long time to global market
⢠Redundant code
⢠Tiny changes, massive impact
10/30
12. Wish List
Architectural Wishes
⢠Isolated requests, features and crashes
⢠Feature toggling on runtime
⢠Linear scalability with supermarket hardware
12/30
13. Wish List
Architectural Wishes
⢠Isolated requests, features and crashes
⢠Feature toggling on runtime
⢠Linear scalability with supermarket hardware
12/30
14. Wish List
Development Wishes
⢠One modular codebase
⢠Explicit component speciďŹcations
⢠Small features, easy to deploy and rollback
13/30
15. Wish List
Erlang Based Web Platforms?
⢠Chicago Boss, Zotonic. . .
(+) Nice layer separation
(+) Mature solutions
(+) Easy to use
14/30
16. Wish List
Erlang Based Web Platforms?
⢠Chicago Boss, Zotonic. . .
(+) Nice layer separation
(+) Mature solutions
(+) Easy to use
⢠But. . .
(-) Feature isolation not key in their design
(-) A VC framework ďŹts better (abstracted model)
14/30
19. A Widget Platform
Pages Made Out Of Widgets
⢠Path determines an entry widget
⢠Widgets and their children form a
tree
⢠Tree generates fully working
HTML
⢠Page generation time guaranteed!
(timeouts)
17/30
20. A Widget Platform
Whatâs A Widget?
⢠Isolated
⢠Explicitly speciďŹed
⢠Releasable separately
18/30
21. A Widget Platform
In Practice
⢠Feature focused development not brand
⢠One widget to serve all brands
19/30
22. A Widget Platform
In Practice
{ themes , [
{ " family " , [
{ template , wdg_featured_games_compact } ,
{ num_games , 3 } ,
{ css , [ " f a m i l y / wdg_featured_games " ] }
]},
⢠Minimal to no impact on other
features
{ { " f a m i y " , 88 } , [
{ num_games , 5 }
]},
⢠ConďŹgurable per site and brand
{ "women" , [
{ template , wdg_featured_games } ,
{ num_games , 6 } ,
{ css , [ "women / wdg_featured_games " ] }
]}
]}
20/30
24. Managing Widgets
Deployments
⢠SWIFT as a central widget
repository
⢠HTTP interface with simple GUI
⢠Uses the platform management
interface:
List nodes
List widgets in a node
Enable/disable widget in a node
Change widget version in a node
⢠Enforces conďŹguration to new
cluster members
22/30
26. Managing Widgets
Master & Slaves In 1 Shell
⢠The platform master node runs:
A web server
A management interface
A speciďŹc set of widgets
24/30
27. Managing Widgets
Master & Slaves In 1 Shell
⢠The platform master node runs:
A web server
A management interface
A speciďŹc set of widgets
⢠Each slave node runs:
Its own speciďŹc set of widgets
24/30
30. The Future
Lessons Learned
⢠Document by example
⢠Reinforce the concepts adoption often
⢠Review, review, review
⢠Measure performance from early stages
27/30
31. The Future
Coming Up
⢠Native widget to backend connectivity
⢠Performance analysis on CI
⢠Historical imagediff for widgets
⢠Device/Browser capabilities available for widgets
⢠Widgets written in Elixir?
28/30
32. The Future
What Weâve Used
⢠ErlyDTL for html templating
⢠Cowboy as a web server
⢠Lager for logging
⢠Rebar for build tool
⢠Lhttpc as HTTP client
⢠Estatsd for monitoring
⢠Sass as a CSS pre-processor
29/30