Developing large apps is difficult. Ensuring that code is consistent, well structured, tested and has an architecture that encourages enhancement and maintainability is essential. When it comes to building large server-focused apps the solutions to this problem have been tried and tested. But, how do you achieve this when building HTML5 single page apps? BladeRunnerJS is an open source developer toolkit and lightweight front-end framework that has helped Caplin Systems ensure that a 200k LoC JavaScript codebase hasn’t become a tangled mess of unstable spaghetti code. This codebase is packaged and delivered to customers as an SDK. Additionally customers receive a getting started application of around 50k LoC for them to build upon, and they’re expected not to turn that into a tangled … you get the idea. In this talk you’ll learn the main concepts to apply when building a front-end app that scales and how BladeRunnerJS can support the development process.

1. Using
!
to build Front-end
JavaScript Apps that Scale
!
!
Fluent 2014

2. Phil @leggetter
phil@leggetter.co.uk
Caplin Systems
!
!
!
@BladeRunnerJS

4. • Toolkit written in Java: Modular + Extensible
• Our version of:
• Yeoman + Grunt + Broccoli + Browserify + App
Architecture + Micro-libraries
• New concepts: Blades + Workbenches
• Not a replacement for Angular, Ember, Web
Components…

5. Overview
• What is a Large Scale front-end App?
• What are the signs of scaling?
• What are the solutions? (with demos)

6. What is a large-scale
JavaScript app?

7. –Addy Osmani, Patterns For Large-Scale JavaScript Application
Architecture
In my view, large-scale JavaScript apps are
non-trivial applications requiring significant
developer effort to maintain, where most heavy
lifting of data manipulation and display falls to
the browser.

8. Large Codebase
More functionality === More code

9. Caplin Trader
• SDK:
• ~1,000 JavaScript files
• ~131,000 LoC
• ~131 lines per file
• ~650 test files
• ~95,000 test LoC
• Typical Apps:
• ~425 JavaScript files
• ~50,000 LoC
• ~117 lines per file
• ~200 test files
• ~21,000 test LoC

10. Complexity

13. Gmail & Caplin Trader
• Large Single Page Apps (SPAs)
• Complex functionality
• Complex interactions
• User
• Technology
• Leave open all day

14. Contributors
The Human Factor

15. Who contributes to an app?
• Front-end devs
• Back-end devs
• Designers
• QA
• Infrastructure and release engineers
• Technical authors

16. So, how do you ensure an
application is maintainable?
1. structure a massive codebase (js, css, html, i18n,
images, config etc.)
2. an architecture for complex functionality and
interaction (UI and other components)
3. make sure that all contributors can work in harmony
4. development must be a productive experience
5. ensure all these compliment each other

17. Signs of scaling

18. Dev Setup takes forever

19. My App isn’t working!
• Other contributors breaking functionality
• Code accessed and modified from elsewhere
• Dependency Analysis and out of order file concatenation

20. Finding assets
is hard

21. What does this code do?
• Inconsistent coding style
• Inconsistent code structure
• Side effects through unexpected
overrides

22. Long App Reloads

23. Have the tests finished yet?
• Having to run all the tests
• UI-based tests: Slow & unreliable
• Continuous Integration…taking 8 hours!
Stopwatch designed by Irit Barzily from the thenounproject.com

24. Scaling Solution

25. • Streamlined developer workflow
• Consistency
• Focus on building a single feature (in isolation)
• Scalable loosely-coupled application architecture
• Quality at its core (maintainability)
BRJS Goals

26. Developer Workflow
Focus on Features

28. Building a single
feature in isolation

29. Blades

32. Workbenches

35. Blade Demo

38. • Streamlined developer workflow
• Consistency
• Focus on building a single feature (in isolation)
• Scalable loosely-coupled application architecture
• Quality at its core (maintainability)
Goals

39. Application
Architecture

40. Requires an Architecture
that…
• Allows complex interactions
• Support developing a feature in isolation
• Allows components to be changed without side effects
• Is to maintain: Fix / Update / Extend

41. Blades (again)

42. MVVM

43. Services

44. What is a service?
• Use services to access shared resources
• Persistence Service
• RESTful Service
• Realtime Service
• Services registered and accessed via a ServiceRegistry
• Dynamic Service Locator1
1 http://martinfowler.com/articles/injection.html#ADynamicServiceLocator

45. Why use services?
• Blades should not directly communicate
• Functionality encapsulated behind an interface
• Loose-coupled communication
• Dependencies can be injected for different scenarios:
• Workbench / Test / App

46. Services Demo

48. • Streamlined developer workflow
• Consistency
• Focus on building a single feature (in isolation)
• Scalable loosely-coupled application architecture
• Quality at its core (maintainability)
Goals

49. Quality

50. Winning!
• Streamlined dev workflow: focus on features
• e.g. Blades & Workbenches
• Consistency: Asset structure, Coding style & structure, Architecture
• Loose coupling: MVVM, Services & Interfaces
• Facilitates testing
• Can easily swap out implementations
• MVVM: Avoid testing the DOM

51. Test Demo
!
./brjs test <path_to_run_tests>

53. Biggest Win
• Testing features in
isolation
• Change view model
and assert against
mocked Service
• Inject mock service,
make calls and assert
View Model

55. Need Proof?
Our full suite Caplin Trader
testing time went from
>8 Hours
< 30 minutes
Much less for a single
feature

56. • Streamlined developer workflow
• Consistency
• Focus on building a single feature (in isolation)
• Scalable loosely-coupled application architecture
• Quality at its core (maintainability)
Goals

57. Summary
• BladeRunnerJS toolkit: Streamline developer
workflow + focus on features
• Blades: Build features in isolation (grouping assets
together)
• Services: loose coupled communication e.g. EventHub
• Quality: Test units (classes), features (ViewModel < - >
Service) & keep DOM testing to a minimum.

58. BRJS at Fluent
• BladeRunnerJS is a new open source solution
• bladerunnerjs.org
• v0.4 released last week
• @leggetter & @patrickmyles are at Fluent today &
tomorrow
• BoF session tomorrow - table #7

59. Phil @leggetter
phil@leggetter.co.uk
Caplin Systems
!
!
!
@BladeRunnerJS
bladerunnerjs.org