Embed Size (px)
Citation preview
Building Front-End Web Apps that
Scale
Concepts and practices that fed into the workflows and application architecture that was core to the BladeRunnerJS
toolkit.
What is a large-scale Front-End Web App?
Large Codebase
More functionality === More code
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
Complex
Gmail & Caplin Trader• Large Single Page Apps (SPAs)
• Complex functionality
• Complex interactions
• User
• Technology
• Leave open all day
Long-Lived
Feature Progression
ContributorsThe Human Factor
Who contributes to an app?• Front-end devs
• Back-end devs
• Designers
• QA / product owners / business analysts
• Infrastructure and release engineers
• Technical authors
Problems1. Large codebase - Structure?
2. Complex interactions - Architecture?
3. Contributor harmony - Architecture & Developer Workflow?
4. Evolution of Features & Technology - Architecture?
5. Productive developer experience - Developer Workflow?
6. Promote Quality - All of the above
Slice up the App
https://www.youtube.com/watch?v=vXjVFPosQHw
The Solution
“Write small, focused, modular parts, and progressively combine them into bigger things to make your app”
@substack | @briantford
The Solutions
1. Features/Components
2. A Services Layer
3. MV*
4. Efficient Testing
5. Tools to Support Workflow
Slice up the App
Slice up the App
Feature ==> Blade
What Problems is this solving?
Slice up the App
Image of app partially workingWho Broken the
App?
Long App Reloads
Finding assets is hard
/assets /feature-name
Features• Unaffected by breaking changes elsewhere
• Easy to find & change assets
• Can run in isolation
• Fast reload times
Compose Features/
Components into Apps
Services
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/Interfacehttps://www.youtube.com/watch?v=JjqKQ8ezwKQ
Slice up the App
Using Services• Use a unique identifier for each service
• Register (code or config). Code example:
• Get
http://martinfowler.com/articles/injection.html#ADynamicServiceLocator
var chatService = require( ‘!chat.service’ );
Why use services?
• Modular architecture
• Features should not directly communicate
• Easily change implementation
• Implementations can be injected for different scenarios:
• Workbench / Test / App
Workbench Tools
Efficient Testing(We’ll get to MV*)
Don’t Touch that DOM
MVVM
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
Need Proof?Our full suite Caplin Trader testing time went from
>8 Hours
< 30 minutes
Much less for a single feature
http://j.mp/jsscale
Tooling & Developer WorkflowFocus on Features
Support Agile
Automation
• Define workflow & promote consistency
• Scaffolding
• Development Server
• Tests
• Builds/Bundling
Compliance
Embrace Constraints
https://gettingreal.37signals.com/ch03_Embrace_Constraints.php
Intelligence
• Code Dependency Analysis
• Enforces rules
• Knowledge of runtime scenarios & service configuration e.g. Workbench, Test, App/Aspect
Customization
• Augment workflow
• Identify allowable change to workflow
• Automation commands
• Builds/Bundling
• Test Runner
Proven!1. Large codebase - By Feature: Component/Service
2. Complex interactions - Components & Services
3. Contributor harmony - Components, Services & Tooling
4. Evolution of Features & Technology - Components (e.g render tech separation) & Services (common abstractions)
5. Productive developer experience - Tooling to support workflow & concepts
6. Promote Quality - MVVM, Services and tooling. Facilitated by all of the above
