Most HTML5 web applications are relatively small scale – they are maintained by a single team and contain relatively little JavaScript, CSS and HTML5 code. At Caplin we build "thick client" replacement financial trading systems containing considerable business logic implemented by hundreds of thousands of lines of JavaScript code. The code is maintained by multiple development teams spread across multiple business units. The talk describes the problems faced and how they can be solved using componetization, loose coupling, services, event bus, design patterns, BDD, the best open source libraries, test by contract, and test automation etc.

1. Enterprise HTML5 Patterns
AKQA Anorak: June 2013
James Turner
Architect
james.turner@caplin.com

2. What am I talking about ?
What is “enterprise” ?
We have replaced, functionally large diverse,
desktop thick client trading systems with
with “single page” web applications.
How we did it ?
Architectural patterns and technologies used.
Good news for web-devs
http://addyosmani.com/resources/essentialjsdesignpatterns/book/

3. Move desktop trading to browsers (1)

4. Move desktop trading to browsers (2)

5. Business Drivers
▶ Increase trade volumes
– Integrate pre-trade information
▶ Reduce cost of sale
▶ Direct channel to customer
– Enhanced user experience
– Branding
▶ Zero deployment: URL to customer
– Reduced onboarding time + cost
– Reduced maintenance

6. Reverse barrier convertibles
“10 minutes rather than up to 2 hours on phone with a sales trader”

7. Technology Drivers
▶ Mobile
– Cross device support
▶ Improved browser ecosystem
– Browser performance debugging much better
– Fewer browser differences
– Vibrant open source community
▶ HTML5
– Local storage, web-sockets, CSS3 …
▶ Death of alternatives
– Flash/Flex, Silverlight

8. Characterizing “enterprise”
HTML5 applications
More than
“A lot of code”

9. The application
▶ “A lot of code” 250k + LOC
▶ Single page “thick client” applications
– Different assumptions
– Runs all day, memory leaks
– UX of lazy loading
▶ Consistency: theming/skinning/UX
▶ Internationalisation
▶ Streaming financial tradable prices
– Screen update performance
– Trade on “displayed price”
– Graceful degradation
– Throttling, scheduling

10. Multiple teams
▶ 10-100’s of developers
▶ Multiple independent teams
– Independent versioned deployment lifecycle
– Share some code
– Rest Isolated
▶ Banks are notoriously silo’d by asset class

11. Different cultures
▶ UX/Graphic designers
▶ Web Developers (jQuery anyone)
▶ Product Owners, Product Managers,
Business Analysts
▶ Server-side developers
– Decouple dependencies
▶ QA’s (programming QA’s)
▶ Operations
– Deploy artifacts
– Same artifacts for TEST/UAT/PROD
– Directory services
Coolness

12. 12

13. Armageddon
“Monday morning: Ooops my weekend
check-in just changed the background
colour of the entire application”

14. How we did it:
1. Components
2. Code organization
3. App structure + patterns
4. Testing

15. Components

16. Split by feature, not technology
16
CSS
HTML
JS
config
i18n
images
tests
CSS
HTML
JS
config
tests
images
i18n
CSS
HTML
JS
config
tests
images
i18n
CSS
HTML
JS
config
tests
images
i18n
CSS
HTML
JS
config
tests
images
i18n

17. ▶ Independent business feature
▶ No direct dependencies to other components
▶ Minimal public interface
– Event bus (publish/subscribe)
– Component API
▶ Code sharing mechanism
– Libraries
– Modules
▶ Conforms to conventions/name-spacing
▶ Can be pre-built
What is a component

18. Contents
Deploy
Deploy

19. Workbench
Instant reload imperative for developer productivity

20. Conways’Law
“Organizations which design systems ...
are constrained to produce designs which
are copies of the communication structures
of these organizations"

21. Code Structure
APPLICATION
MODULE A
COMPONENT 1
COMPONENT 2
MODULE B
COMPONENT 3
COMPONENT 4
ASPECTS
MOBILE
DESKTOP
LIBRARIES
INC THIRD-PARTY

22. Inheritance + Name-spacing
▶ CSS
– App defines common “theme”
– Components inherit theme
– Override with more specific CSS rules
• Need name-spacing
– Use CSS pre-processor (e.g. LESS,SASS)
– Define an ontology
▶ XML/HTML
– Name-spacing for unique ID’s

23. JavaScript Coding
▶ Fine grained OO
– We average about 100 LOC per class
▶ One class per file
▶ Design patterns
▶ SOLID (Uncle Bob)
▶ Coding standards
– Inheritance
– JsHint
▶ Common code in libraries
▶ Interpreted: so testing is more important
▶ JsLint /coverage

24. Bundling
dev-server
bundling
(enforcement)
APPLICATIO
N
BLADESET A
BLADE 1
BLADE 2
BLADESET B
BLADE 1
BLADE 2
ASPECTS
MOBILE
DESKTOP
ProjectsEclipse
IntelliJ
Sublime
NetBeans
Vi/Emacs
……..
IDE of choice
running app
J2EE
ServerWAR
deploy
ZIP CDN
Directory
services

25. App Structure
CLIENT SERVER
TraderApp
Layout
Managercomponent
component
component
component
service
service
service
service
event
bus
HTML Bundle
CSS Bundle
I18n Bundle
XML Bundle
JavaScript Bundle
Application
Server

26. JavaScript Interfaces
▶ Defines the contract a component should
conform to.
– A set of method signatures
▶ Multiple classes “implement” the same interface
▶ Provides a hook for documentation
▶ Hook for IDE tooling

27. Service Registry
var service = new caplin.XhrXmlResourceServiceProvider(this.sXmlBundleUrl);
caplin.ServiceRegistry.register("caplin.XmlResourceService”, service);
var xmlResourceService = caplin.ServiceRegistry.getService("caplin.XmlResourceService");
var tradeModelNode = xmlResourceService.getXmlDocument("tradeModels");
Registration:
Usage:

28. Event Hub
▶ Publish/Subscribe inside the browser
– Many to many (or none)
▶ Defined by an interface (contract)
▶ Methods cannot return anything
▶ Classic example: logging
▶ Nice Article:
http://blog.caplin.com/2012/12/07/event-hub-pubsub-in-the-browser/

29. Component Interface
▶ Used by layout managers to manage GUI
components
▶ Defines GUI lifecycle events
– getElement(),
– onOpen(),
– onResize(),
– onSerialize() etc.

30. MVVM Pattern
ViewRendering to screen
Domain
Model
business semantic method callslistens
Reused across many
screens
View
Model
gestureslistens
Logical representation
of the view
(an adaptor)

31. <button class=‘..’
data-bind=‘click:buttonClicked’>
Execute Trade
</button>
HTML template with bindings
$(button).click(function(){
vm.buttonClicked()
});
jQuery Control
Our HTML5 MVVM
Domain
Model
executeTrade()complete()
Message
Service
send()receive()
View
Model
buttonClicked()tradeButtonEnabled
No DOM Access
XmlHttpRequest
binding framework
e.g. KnockoutJs

32. The Testing Triangle
Functional
GUI testing
ITs
Unit Tests
manual
Acceptance
Tests
Performance
Tests
Integration Tests
- Selenium -
(automated
manual tests)
Unit Tests
manual
Performance
Tests

33. Test by contract
Browser
GUI
logicaluseractions
servicecalls
Given “form is opened”
When “user executes trade”
Then “trade message sent to server”
Server
Code
RESTfulAPI
Given “server is started”
When “trade message received”
Then “money is sent somewhere”

34. Test by contract
MVVM and services
View
Model
Domain
Model
complete()
View
execute()
Given …
When …
Then …
Fixtures
executeTrade()
tradeButtonEnabled
Message
Service
Stub
send()
receive()

35. Test Infrastructure
js-test-driver
Server
Bundlers
JavaScript
Dependencies
jsTestDriver.conf
plugin:
- name: "BundleInjector"
jar: …/js-jstd-plugin.jar
module: com.caplin.jstd.BundlerPlugin
load:
- bundles/i18n/en_i18n.bundle
- bundles/js/js.bundle
test:
- tests/**.js
serve:
- bundles/html.bundle
- bundles/xml.bundle
Plugin
JavaScript
Test Files
HTML/XML
Dependencies

36. In summary:
divide + conquer
Natural fine grained OO coding
Components
Common code in libraries
Split GUI Code into
Dom interactions
View Model
Domain Model
Services for stubbing
GWT + Test by contract

37. We will soon be open-sourcing
our implementation of this
architecture
www.bladerunnerjs.org