How to Build Front-End Web Apps that Scale - FutureJS
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

How to Build Front-End Web Apps that Scale - FutureJS

  • 1,735 views
Uploaded on

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

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.

More in: Software , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,735
On Slideshare
1,611
From Embeds
124
Number of Embeds
4

Actions

Shares
Downloads
27
Comments
0
Likes
4

Embeds 124

https://twitter.com 82
http://lanyrd.com 34
http://www.feedspot.com 7
http://www.slideee.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 8. Gmail & Caplin Trader • Large Single Page Apps (SPAs) • Complex functionality • Complex interactions • User • Technology • Leave open all day
  • 9. Features: Change, Come & Go
  • 10. Feature Progression
  • 11. Contributors The Human Factor
  • 12. Who contributes to an app? • Front-end devs • Back-end devs • Designers • QA • Infrastructure and release engineers • Technical authors
  • 13. 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
  • 14. The Solutions 1. Components/Widgets/Modules 2. A Services Layer 3. MV* 4. Efficient Testing 5. Tools to Support Workflow
  • 15. Prove it!
  • 16. Component/Module/ Feature/Blade
  • 17. Finding assets is hard
  • 18. /assets /feature-name
  • 19. Long App Reloads
  • 20. Image of app partially workingWho Broken the App?
  • 21. Running in isolation === Faster reload times
  • 22. Compose Components/Modules into Apps
  • 23. Services
  • 24. 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
  • 25. Using Services • Use a unique identifier for each service • Register (code or config). Code example: ! • Get http://martinfowler.com/articles/injection.html#ADynamicServiceLocator
  • 26. Why use services? • Features should not directly communicate • Easily change implementation • Implementations can be injected for different scenarios: • Workbench / Test / App
  • 27. Fake Services
  • 28. Fake/Stub/Mock Services
  • 29. Real Services
  • 30. Efficient Testing (We’ll get to MV*)
  • 31. Don’t Touch that DOM
  • 32. MVVM
  • 33. 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
  • 34. Need Proof? Our full suite Caplin Trader testing time went from >8 Hours < 30 minutes Much less for a single feature
  • 35. Tooling & Developer Workflow Focus on Features
  • 36. What tooling offers?
  • 37. Automation • Define workflow & promote consistency • Scaffolding • Dev Server • Builds/Bundling • Tests
  • 38. Intelligence
  • 39. Compliance
  • 40. Dependency Analysis
  • 41. Knowledge of Runtime Scenarios • Workbench (dev-mode) • Test • App
  • 42. Customization • Augment workflow • Identify allowable change to workflow • Automation commands • Builds/Bundling • Test Runner
  • 43. 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!
  • 44. Phil @leggetter phil@leggetter.co.uk Caplin Systems ! ! ! @BladeRunnerJS bladerunnerjs.org