Developing large apps is difficult. Ensuring that code is consistent, well structured, tested, maintainable and has an architecture that encourages enhancement is essential. When it comes to large server-focused apps, solutions to this problem have been tried and tested. But, with the ongoing dramatic shift of functionality into the browser, how do you achieve this when building Front-End Web Apps? In this talk we’ll cover the signs to watch out for as your HTML5 SPA grows and provide examples of some of the tooling types that can contribute-to - as well as ease - the growing pains. Finally, we’ll demonstrate how tooling can be used to support a set of conventions, practices and principles that enable a productive developer workflow where the first line of code is feature code, features can be developed in isolation, code conflicts are avoided by grouping assets by feature and features are composed into apps. The demonstrations will use the BladeRunnerJS open source developer toolkit, but the concepts are widely applicable.

1. How to Build
Front-End Web
Apps that Scale
2014

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

3. What is a large-scale
JavaScript app?

4. –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.

5. Large Codebase
More functionality === More code

6. 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

7. Complexity

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

11. Features: Change,
Come & Go

12. Feature Progression

13. Contributors
The Human Factor

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

15. 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. promote quality
5. development must be a productive experience
6. ensure all these compliment each other

16. The Solutions
1. Components/Widgets/Modules
2. A Services Layer
3. MV*
4. Efficient Testing
5. Tools to Support Workflow

17. Prove it!

18. Component/Module/
Feature/Blade

19. Finding assets
is hard

20. /assets /feature-name

21. Long App Reloads

22. Image of app partially
workingWho Broken the
App?

25. Running in isolation
===
Faster reload times

26. Compose
Components/Modules
into Apps

28. Services

29. What is a service?
• Use services to access shared resources
• In-app inter-component messaging
• Persistence Service
• RESTful Service
• Realtime Service
• Services are a Contract/Protocol/Interface

30. Using Services
• Use a unique identifier for each service
• Register (code or config). Code example:
!
• Get
http://martinfowler.com/articles/injection.html#ADynamicServiceLocator

34. Why use services?
• Features should not directly communicate
• Easily change implementation
• Implementations can be injected for different
scenarios:
• Workbench / Test / App

35. Fake Services

36. Fake/Stub/Mock Services

37. Real Services

38. Efficient Testing
(We’ll get to MV*)

40. Don’t Touch that DOM

41. MVVM

42. End-to-End Module Testing
• Testing features in
isolation
• Change view model
and assert against
mocked Service
• Inject fake service,
make calls and assert
View Model

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

45. Tooling & Developer
Workflow
Focus on Features

47. What tooling offers?

48. Automation
• Define workflow & promote consistency
• Scaffolding
• Dev Server
• Builds/Bundling
• Tests

49. Intelligence

50. Compliance

51. Dependency Analysis

52. Knowledge of Runtime
Scenarios
• Workbench (dev-mode)
• Test
• App

53. Customization
• Augment workflow
• Identify allowable change to workflow
• Automation commands
• Builds/Bundling
• Test Runner

54. Proven!
1. structure a massive codebase - by feature
2. an architecture for complex functionality and interaction - Services
& MVVM
3. contributor harmony - separation of concerns; codebase structure,
modules/components & architecture
4. promote quality - Services & MVVM === Highly testable
5. productive experience - tooling supports all of this & ensure
consistency
6. complimentary - Yes, look at all the cross-over!

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