Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014

•
•
Phil Leggetter
Phil Leggetter

Developing large apps is difficult. Ensuring that code is consistent, well structured, tested and has an architecture that encourages enhancement and maintainability is essential. When it comes to building large server-focused apps the solutions to this problem have been tried and tested. But, how do you achieve this when building HTML5 single page apps? BladeRunnerJS is an open source developer toolkit and lightweight front-end framework that has helped Caplin Systems ensure that a 200k LoC JavaScript codebase hasn’t become a tangled mess of unstable spaghetti code. This codebase is packaged and delivered to customers as an SDK. Additionally customers receive a getting started application of around 50k LoC for them to build upon, and they’re expected not to turn that into a tangled … you get the idea. In this talk you’ll learn the main concepts to apply when building a front-end app that scales and how BladeRunnerJS can support the development process.

1 of 59
Download to read offline
Using ! to build Front-end JavaScript Apps that Scale ! ! Fluent 2014
Phil @leggetter phil@leggetter.co.uk Caplin Systems ! ! ! @BladeRunnerJS
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
• Toolkit written in Java: Modular + Extensible • Our version of: • Yeoman + Grunt + Broccoli + Browserify + App Architecture + Micro-libraries • New concepts: Blades + Workbenches • Not a replacement for Angular, Ember, Web Components…
Overview • What is a Large Scale front-end App? • What are the signs of scaling? • What are the solutions? (with demos)
What is a large-scale JavaScript app?
–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.
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
Complexity
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Gmail & Caplin Trader • Large Single Page Apps (SPAs) • Complex functionality • Complex interactions • User • Technology • Leave open all day
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. development must be a productive experience 5. ensure all these compliment each other
Signs of scaling
Dev Setup takes forever
My App isn’t working! • Other contributors breaking functionality • Code accessed and modified from elsewhere • Dependency Analysis and out of order file concatenation
Finding assets is hard
What does this code do? • Inconsistent coding style • Inconsistent code structure • Side effects through unexpected overrides
Long App Reloads
Have the tests finished yet? • Having to run all the tests • UI-based tests: Slow & unreliable • Continuous Integration…taking 8 hours! Stopwatch designed by Irit Barzily from the thenounproject.com
Scaling Solution
• Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) BRJS Goals
Developer Workflow Focus on Features
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Building a single feature in isolation
Blades
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Workbenches
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Blade Demo
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
• Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) Goals
Application Architecture
Requires an Architecture that… • Allows complex interactions • Support developing a feature in isolation • Allows components to be changed without side effects • Is to maintain: Fix / Update / Extend
Blades (again)
MVVM
Services
What is a service? • Use services to access shared resources • Persistence Service • RESTful Service • Realtime Service • Services registered and accessed via a ServiceRegistry • Dynamic Service Locator1 1 http://martinfowler.com/articles/injection.html#ADynamicServiceLocator
Why use services? • Blades should not directly communicate • Functionality encapsulated behind an interface • Loose-coupled communication • Dependencies can be injected for different scenarios: • Workbench / Test / App
Services Demo
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
• Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) Goals
Quality
Winning! • Streamlined dev workflow: focus on features • e.g. Blades & Workbenches • Consistency: Asset structure, Coding style & structure, Architecture • Loose coupling: MVVM, Services & Interfaces • Facilitates testing • Can easily swap out implementations • MVVM: Avoid testing the DOM
Test Demo ! ./brjs test <path_to_run_tests>
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Biggest Win • Testing features in isolation • Change view model and assert against mocked Service • Inject mock service, make calls and assert View Model
Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014
Need Proof? Our full suite Caplin Trader testing time went from >8 Hours < 30 minutes Much less for a single feature
• Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) Goals
Summary • BladeRunnerJS toolkit: Streamline developer workflow + focus on features • Blades: Build features in isolation (grouping assets together) • Services: loose coupled communication e.g. EventHub • Quality: Test units (classes), features (ViewModel < - > Service) & keep DOM testing to a minimum.
BRJS at Fluent • BladeRunnerJS is a new open source solution • bladerunnerjs.org • v0.4 released last week • @leggetter & @patrickmyles are at Fluent today & tomorrow • BoF session tomorrow - table #7
Phil @leggetter phil@leggetter.co.uk Caplin Systems ! ! ! @BladeRunnerJS bladerunnerjs.org

More Related Content

Using BladeRunnerJS to Build Front-End Apps that Scale - Fluent 2014

  • 1. Using ! to build Front-end JavaScript Apps that Scale ! ! Fluent 2014
  • 4. • Toolkit written in Java: Modular + Extensible • Our version of: • Yeoman + Grunt + Broccoli + Browserify + App Architecture + Micro-libraries • New concepts: Blades + Workbenches • Not a replacement for Angular, Ember, Web Components…
  • 5. Overview • What is a Large Scale front-end App? • What are the signs of scaling? • What are the solutions? (with demos)
  • 6. What is a large-scale JavaScript app?
  • 7. –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.
  • 9. 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
  • 13. Gmail & Caplin Trader • Large Single Page Apps (SPAs) • Complex functionality • Complex interactions • User • Technology • Leave open all day
  • 15. Who contributes to an app? • Front-end devs • Back-end devs • Designers • QA • Infrastructure and release engineers • Technical authors
  • 16. 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. development must be a productive experience 5. ensure all these compliment each other
  • 18. Dev Setup takes forever
  • 19. My App isn’t working! • Other contributors breaking functionality • Code accessed and modified from elsewhere • Dependency Analysis and out of order file concatenation
  • 21. What does this code do? • Inconsistent coding style • Inconsistent code structure • Side effects through unexpected overrides
  • 23. Have the tests finished yet? • Having to run all the tests • UI-based tests: Slow & unreliable • Continuous Integration…taking 8 hours! Stopwatch designed by Irit Barzily from the thenounproject.com
  • 25. • Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) BRJS Goals
  • 38. • Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) Goals
  • 40. Requires an Architecture that… • Allows complex interactions • Support developing a feature in isolation • Allows components to be changed without side effects • Is to maintain: Fix / Update / Extend
  • 42. MVVM
  • 44. What is a service? • Use services to access shared resources • Persistence Service • RESTful Service • Realtime Service • Services registered and accessed via a ServiceRegistry • Dynamic Service Locator1 1 http://martinfowler.com/articles/injection.html#ADynamicServiceLocator
  • 45. Why use services? • Blades should not directly communicate • Functionality encapsulated behind an interface • Loose-coupled communication • Dependencies can be injected for different scenarios: • Workbench / Test / App
  • 48. • Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) Goals
  • 50. Winning! • Streamlined dev workflow: focus on features • e.g. Blades & Workbenches • Consistency: Asset structure, Coding style & structure, Architecture • Loose coupling: MVVM, Services & Interfaces • Facilitates testing • Can easily swap out implementations • MVVM: Avoid testing the DOM
  • 51. Test Demo ! ./brjs test <path_to_run_tests>
  • 53. Biggest Win • Testing features in isolation • Change view model and assert against mocked Service • Inject mock service, make calls and assert View Model
  • 55. Need Proof? Our full suite Caplin Trader testing time went from >8 Hours < 30 minutes Much less for a single feature
  • 56. • Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability) Goals
  • 57. Summary • BladeRunnerJS toolkit: Streamline developer workflow + focus on features • Blades: Build features in isolation (grouping assets together) • Services: loose coupled communication e.g. EventHub • Quality: Test units (classes), features (ViewModel < - > Service) & keep DOM testing to a minimum.
  • 58. BRJS at Fluent • BladeRunnerJS is a new open source solution • bladerunnerjs.org • v0.4 released last week • @leggetter & @patrickmyles are at Fluent today & tomorrow • BoF session tomorrow - table #7