A Web Widget PlatformEnrique Paz @quiquepaz

1/30

Introduction Meeting Me

• Software Architect• Passionate Erlang developer• Testing enthusiast• Love beautiful code!

2/30

Introduction Meeting Spilgames

• Gaming Platform• Serving data to 190+ countries world-wide• 180+ million unique users per month

3/30

Introduction Brands and Sites

• 5 Brands/Channels for target audiences• 1-15 Sites for different geographical regions• Strong domains

I www.agame.com for teens in the USI www.games.co.uk for families in the UKI www.juegosdechicas.com for girls in SpainI . . .

4/30

Introduction Brands and Sites

5/30

Old Portals Landscape

6/30

Old Portals Landscape

• Monolithic portals per brand• Static pages with lots of AJAX

calls• Architectural layers developed

independently

7/30

Old Portals Landscape What Was Good. . .

• Acceptable performance• Clear layer separation• Fast growth• Per brand & site development• Small learning curve

8/30

Old Portals Landscape What Was Good. . .

9/30

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

Wish List

11/30

Wish List Architectural Wishes

• Isolated requests, features and crashes• Feature toggling on runtime• Linear scalability with supermarket hardware

12/30

Wish List Architectural Wishes

• Isolated requests, features and crashes• Feature toggling on runtime• Linear scalability with supermarket hardware

12/30

Wish List Development Wishes

• One modular codebase• Explicit component specifications• Small features, easy to deploy and rollback

13/30

Wish List Erlang Based Web Platforms?

• Chicago Boss, Zotonic. . .I (+) Nice layer separationI (+) Mature solutionsI (+) Easy to use

• But. . .I (-) Feature isolation not key in their designI (-) A VC framework fits better (abstracted model)

14/30

Wish List Erlang Based Web Platforms?

• Chicago Boss, Zotonic. . .I (+) Nice layer separationI (+) Mature solutionsI (+) Easy to use

• But. . .I (-) Feature isolation not key in their designI (-) A VC framework fits better (abstracted model)

14/30

A Widget Platform Let’s Create Our Own Solution!

15/30

A Widget Platform Pages Made Out Of Widgets

16/30

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

A Widget Platform What’s A Widget?

• Isolated• Explicitly specified• Releasable separately

18/30

A Widget Platform In Practice

• Feature focused development not brand• One widget to serve all brands

19/30

A Widget Platform In Practice

• Minimal to no impact on otherfeatures

• Configurable per site and brand

{ themes , [

{ " f a m i l y " , [{ template , wdg_featured_games_compact } ,{num_games , 3 } ,{ css , [ " f a m i l y / wdg_featured_games " ] }

] } ,

{ { " famiy " , 88 } , [{num_games , 5 }

] } ,

{ "women" , [{ template , wdg_featured_games } ,{num_games , 6 } ,{ css , [ "women/ wdg_featured_games " ] }

] }

] }

20/30

Managing Widgets

21/30

Managing Widgets Deployments

• SWIFT as a central widgetrepository

• HTTP interface with simple GUI• Uses the platform management

interface:I List nodesI List widgets in a nodeI Enable/disable widget in a nodeI Change widget version in a node

• Enforces configuration to newcluster members

22/30

Managing Widgets A Handy Tool

23/30

Managing Widgets Master & Slaves In 1 Shell

• The platform master node runs:I A web serverI A management interfaceI A specific set of widgets

• Each slave node runs:I Its own specific set of widgets

24/30

Managing Widgets Master & Slaves In 1 Shell

• The platform master node runs:I A web serverI A management interfaceI A specific set of widgets

• Each slave node runs:I Its own specific set of widgets

24/30

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

The Future

26/30

The Future Lessons Learned

• Document by example• Reinforce the concepts adoption often• Review, review, review• Measure performance from early stages

27/30

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

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

The Future Questions?

Leave me feedback! http://spkr8.com/t/28371

30/30