FoWA London 2014 Notes: James Turner on How to Build Front-End Web Apps that Scale

Notes from James, How to Build Front-end Web Apps that Scale, 1 October 2014

What’s a large-scale JS app?
Quote from Addy Osmani, Patterns for Large-Scale JavaScript Application Architecture

Large amounts of code
Complexity e.g. GMail – Large SPA, complex functionality, complex interactions, open all day
Long-lived – Features evolve, features added and removed, technology changes
Many contributors – Front-end devs, back-end devs, designers, QA, product owners, business analysts, …

What we need
Structure for codebase
Interaction architectures
Contributors work in harmony
Promote quality
Development productive

Structure
Use Libraries. Developers do too much work, when there’s a library to do it – if it’s not unique to your code, use a library.
Make it modular – module solving a small problem.
Divide into features.
“Component: sealed code unit fully configurable via its (documented) API Module: a general blob of functionality”
Their features are called blades because it’s a slice through the whole stack – HTML, CSS, Tests, etc.

API core
Bootstrap, layout manager, services, themes [<– the unique bits]
————————————————-
Tools, frameworks, components

Frameworks intrude above the line and affect how you write your code

Faster loading time because you’re only loading the code you need for that blade.
Easy for new developers to find assets – it’s all in the blade.
Re-use: make blade into assembly, top level becomes config and ‘glue’. But this is expensive, so only do it if you’ve got it three times.
Modules need to be able to use any rendering technology – don’t tie application to rendering framework.
Conway’s law – system will copy organisation’s communication structure
Vertical layers make it much more obvious who’s broken it.
Segmentation means less likely will break other sections.

Services
Services allow access to shared resources.
They’re a contract/protocol/interface – allows fail fast.
Decouples you from project risk from other teams because you can put in fakes.
Can inject implementations for different scenarios.

Tests
Don’t touch the DOM in E2E tests – theirs failed because the HTML changed. You should be poking the ViewModel instead.
Do test by contract.
Test time went from > 8 hours (running 3×, accepting < 5% failure), now < 10 minutes.

They automate builds, scaffolding, define workflow.
They have tooling for dependency analysis and compliance e.g. you are not allowed to reference another blade.

Questions
Sharing translated text?
– Putting things in libraries
– Theme defined at application level
Versioning services?
– They use streams rather than REST

Advertisements

About Jennifer Phillips Campbell

Software Developer and Medieval Historian
This entry was posted in Future of Web Apps. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s