Typical Apps

Report 4 Downloads 113 Views
How to Build Front-End Web Apps that Scale 2014

Phil @leggetter [email protected] Caplin Systems !

What is a large-scale JavaScript app?

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

Large Codebase More functionality === More code

Caplin Trader •

SDK:



Typical Apps:



~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

Complexity

Gmail & Caplin Trader •

Large Single Page Apps (SPAs)



Complex functionality



Complex interactions





User



Technology

Leave open all day

Features: Change, Come & Go

Feature Progression

Contributors The Human Factor

Who contributes to an app? •

Front-end devs



Back-end devs



Designers



QA



Infrastructure and release engineers



Technical authors

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

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

Prove it!

Component/Module/ Feature/Blade

Finding assets is hard

/assets

/feature-name

Long App Reloads

Image of app partially Whoworking Broken the App?

Running in isolation === Faster reload times

Compose Components/Modules 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/Interface

Using Services •

Use a unique identifier for each service



Register (code or config). Code example:

!



Get

http://martinfowler.com/articles/injection.html#ADynamicServiceLocator

Why use services? •

Features should not directly communicate



Easily change implementation



Implementations can be injected for different scenarios: •

Workbench / Test / App

Fake Services

Fake/Stub/Mock Services

Real Services

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

Tooling & Developer Workflow Focus on Features

What tooling offers?

Automation •

Define workflow & promote consistency



Scaffolding



Dev Server



Builds/Bundling



Tests

Intelligence

Compliance

Dependency Analysis

Knowledge of Runtime Scenarios



Workbench (dev-mode)



Test



App

Customization •

Augment workflow



Identify allowable change to workflow •

Automation commands



Builds/Bundling



Test Runner

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!

Phil @leggetter [email protected] Caplin Systems ! ! !

@BladeRunnerJS bladerunnerjs.org