Organizing websites for target audiences. Organizing web pages in components. Orchestrating it all with Erlang. Letting it crash!

1. A Web Widget Platform
Enrique Paz @quiquepaz
1/30

2. Introduction
Meeting Me
• Software Architect
• Passionate Erlang developer
• Testing enthusiast
• Love beautiful code!
2/30

3. Introduction
Meeting Spilgames
• Gaming Platform
• Serving data to 190+ countries world-wide
• 180+ million unique users per month
3/30

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

5. Introduction
Brands and Sites
5/30

6. Old Portals Landscape
6/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

9. Old Portals Landscape
What Was Good. . .
9/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

11. Wish List
11/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 specifications
• 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 fits better (abstracted model)
14/30

17. A Widget Platform
Let’s Create Our Own Solution!
15/30

18. A Widget Platform
Pages Made Out Of Widgets
16/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 specified
• 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 }
]},
• Configurable per site and brand
{ "women" , [
{ template , wdg_featured_games } ,
{ num_games , 6 } ,
{ css , [ "women / wdg_featured_games " ] }
]}
]}
20/30

23. Managing Widgets
21/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 configuration to new
cluster members
22/30

25. Managing Widgets
A Handy Tool
23/30

26. Managing Widgets
Master & Slaves In 1 Shell
• The platform master node runs:
A web server
A management interface
A specific 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 specific set of widgets
• Each slave node runs:
Its own specific set of widgets
24/30

28. Managing Widgets
spil.com/?origins=w1,preview;w5,preview
• Widgets can be called in any node
• Widgets can fail
• Widgets can be disabled
25/30

29. The Future
26/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

33. The Future
Questions?
Leave me feedback! http://spkr8.com/t/28371
30/30