Building front-end apps that Scale - FOSDEM 2014
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Building front-end apps that Scale - FOSDEM 2014

on

  • 1,760 views

Developing large apps is difficult. Ensuring that the code is consistent, well structured, tested, and that the architecture encourages maintainability is essential. When it comes to building large ...

Developing large apps is difficult. Ensuring that the code is consistent, well structured, tested, and that the architecture encourages 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 we achieve this when it comes to HTML5 single page apps?

BladeRunnerJS is an open source developer toolkit and lightweight front-end framework that has helped the company I work for (Caplin Systems) ensure that a 200k LoC JavaScript codebase hasn’t become a tangled mess of unstable spaghetti code (with bacon bits). This codebase is then delivered to customers, along with around 50k LoC example functionality 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 about the main concepts we have applied, how we have applied them - and how you can too - to achieve what might sound like the impossible.

Statistics

Views

Total Views
1,760
Views on SlideShare
1,662
Embed Views
98

Actions

Likes
1
Downloads
15
Comments
0

2 Embeds 98

http://lanyrd.com 86
https://twitter.com 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Building front-end apps that Scale - FOSDEM 2014 Presentation Transcript

  • 1. Building front-end apps that Scale
  • 2. Phil @leggetter phil@leggetter.co.uk Caplin Systems ! ! ! @BladeRunnerJS
  • 3. Overview • What is a Large Scale front-end App? • What are the signs of scaling? • What are the solutions? (with demos)
  • 4. What is a large-scale JavaScript app?
  • 5. 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
  • 6. Great. More detail please!
  • 7. Large Codebase More functionality = More code
  • 8. Caplin Trader • SDK: • Getting Started App: • ~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
  • 9. Complexity
  • 10. Gmail & Caplin Trader • Large Single Page Apps (SPAs) • Complex functionality • Complex interactions • • • User Technology Leave open all day
  • 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. People who are part of... • Large teams • Multiple teams • Teams spread across an organisation • Teams spread across multiple organisations
  • 14. 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 within an application codebase and UI 3. make sure that all contributors can work in harmony 4. development must be a productive experience 5. ensure all these compliment each other
  • 15. Seven signs of scaling?
  • 16. Dev Setup takes forever • Lots of infrastructure dependencies • Database • Auth service • Realtime server • One or more Web APIs • Dev app server
  • 17. My App won’t load! • Run full application • All back-end components running • Lots of moving parts
  • 18. My App isn’t working! • Other contributors breaking functionality • Code accessed and modified from elsewhere • Dependency Analysis and bundling out of order
  • 19. Finding assets is hard
  • 20. What does this code do? • Inconsistent coding style and structure • Side effects
  • 21. Long App Reloads
  • 22. Have the tests finished yet? • Having to run all the tests • UI-based tests • Continuous Integration…taking 8 hours!
  • 23. Scaling Solutions
  • 24. Goals • Streamlined developer workflow • Consistency • Focus on building a single feature (in isolation) • Scalable loosely-coupled application architecture • Quality at its core (maintainability)
  • 25. Developer Workflow
  • 26. Building a single feature in isolation
  • 27. Blades
  • 28. Blade Demo
  • 29. Application Architecture
  • 30. Requires an Architecture that… • Allows complex interactions • Allows components to be changed without side effects • At launch and during runtime • Is easily extended • Is easily tested • Is easily maintained
  • 31. Blades (again)
  • 32. MVVM
  • 33. Services
  • 34. What is a service? • Use services to access resources • • Restful Service • • Persistence Service Realtime Service Perform common non-UI tasks e.g. • • LoggingService Services registered and accessed via a ServiceRegistry • Dynamic Service Locator 1 1 http://martinfowler.com/articles/injection.html#ADynamicServiceLocator
  • 35. Why use services? • Used for cross-cutting concern • Functionality encapsulated behind an interface • Loose-coupled communication • Dependencies can be injected at: • App/Workbench load time • During runtime
  • 36. Services Demo
  • 37. Quality
  • 38. Manually test in the workbench as part of iterative development cycle
  • 39. Simple Wins • Consistency • • • Architecture Coding style and structure Loose coupling (MVVM, Services and beyond) • • • Facilitates testing Can easily swap out implementations Avoid testing the DOM
  • 40. Biggest Win • Testing features in isolation • • • Change view model and assert against mocked Service Inject mock service, make calls and assert View Model Run small suit of Application End-to-End Business Tests
  • 41. Need Proof? Our full suite Caplin Trader testing time went from 8 Hours to 10 minutes
  • 42. A note on deployment • The BladeRunnerJS app replicates previous sole target production environment: J2EE • You can enable dev mode (discussions ongoing) • You can build to a .WAR frill • Flat File deployment coming soon (very soon, I hope)
  • 43. Summary • Streamline developer workflow for productivity • Build features in isolation (grouping assets together) • Services e.g. EventHub for loose coupled communication • Encapsulate using Interfaces • Test a feature ViewModel < - > Service. Avoid the DOM. • It all improves Quality and thus maintenance
  • 44. Phil @leggetter phil@leggetter.co.uk Caplin Systems ! ! ! @BladeRunnerJS bladerunnerjs.org