This document discusses how to build large-scale front-end apps that can scale effectively. It defines large-scale apps as having significant codebases and complexity. Some signs that an app needs scaling solutions are long development setup times, apps not loading properly, difficulty finding code, and long test runs. The document recommends streamlining the developer workflow, building features in isolation, using a loosely coupled architecture with services, and extensive testing to improve maintainability for large teams.

1. Building front-end apps that
Scale

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

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

4. What is a large-scale
JavaScript app?

5. 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.
–Addy Osmani, Patterns For Large-Scale JavaScript Application
Architecture

6. Great. More detail
please!

7. Large Codebase
More functionality = More code

8. Caplin Trader
•
SDK:
•
Getting Started App:
•
~1,000 JavaScript files
•
~425 JavaScript files
•
~131,000 LoC
•
~50,000 LoC
~131 lines per file
•
~117 lines per file
~650 test files
•
~200 test files
•
~21,000 test LoC
•
•
•
~95,000 test LoC

9. 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. People who are part of...
•
Large teams
•
Multiple teams
•
Teams spread across an organisation
•
Teams spread across multiple organisations

17. 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 within an application codebase and UI
3. make sure that all contributors can work in harmony
4. development must be a productive experience
5. ensure all these compliment each other

18. Seven signs of
scaling?

19. Dev Setup takes forever
•
Lots of infrastructure dependencies
•
Database
•
Auth service
•
Realtime server
•
One or more Web APIs
•
Dev app server

20. My App won’t load!
•
Run full application
•
All back-end components running
•
Lots of moving parts

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

22. Finding assets
is hard

23. What does this code do?
•
Inconsistent coding style and structure
•
Side effects

24. Long App Reloads

25. Have the tests finished yet?
•
Having to run all the tests
•
UI-based tests
•
Continuous Integration…taking 8 hours!

26. Scaling Solutions

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

28. Developer Workflow

30. Building a single
feature in isolation

31. Blades

34. Blade Demo

36. Application
Architecture

37. Requires an Architecture
that…
•
Allows complex interactions
•
Allows components to be changed without side effects
•
At launch and during runtime
•
Is easily extended
•
Is easily tested
•
Is easily maintained

38. Blades (again)

39. MVVM

40. Services

41. What is a service?
•
Use services to access resources
•
•
Restful Service
•
•
Persistence Service
Realtime Service
Perform common non-UI tasks e.g.
•
•
LoggingService
Services registered and accessed via a ServiceRegistry
•
Dynamic Service Locator
1
1 http://martinfowler.com/articles/injection.html#ADynamicServiceLocator

42. Why use services?
•
Used for cross-cutting concern
•
Functionality encapsulated behind an interface
•
Loose-coupled communication
•
Dependencies can be injected at:
•
App/Workbench load time
•
During runtime

43. Services Demo

45. Quality

46. Manually test in the workbench as part of
iterative development cycle

47. Simple Wins
•
Consistency
•
•
•
Architecture
Coding style and structure
Loose coupling (MVVM, Services and beyond)
•
•
•
Facilitates testing
Can easily swap out implementations
Avoid testing the DOM

48. Biggest Win
•
Testing features in isolation
•
•
•
Change view model and assert against mocked
Service
Inject mock service, make calls and assert View
Model
Run small suit of Application End-to-End Business
Tests

50. Need Proof?
Our full suite Caplin Trader testing time went from
8 Hours
to
10 minutes

51. A note on deployment
•
The BladeRunnerJS app replicates previous sole target
production environment: J2EE
•
You can enable dev mode (discussions ongoing)
•
You can build to a .WAR frill
•
Flat File deployment coming soon (very soon, I hope)

52. Summary
•
Streamline developer workflow for productivity
•
Build features in isolation (grouping assets together)
•
Services e.g. EventHub for loose coupled communication
•
Encapsulate using Interfaces
•
Test a feature ViewModel < - > Service. Avoid the DOM.
•
It all improves Quality and thus maintenance

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