Wrangling Large Scale Frontend Web Applications
56 likes48,112 views
The document discusses the challenges and strategies involved in managing large scale frontend web applications, particularly in high-traffic environments like e-commerce sites. It highlights the complexity of JavaScript architecture, the importance of build tools, and the roles of various teams such as architects, guides, gatekeepers, and lifeguards in ensuring successful development and deployment. Key recommendations include establishing strong conventions, automating quality checks, and effectively logging and monitoring code execution.
![ Lazy (Code)
window._entry(function() {
require(["header/header"], function () {
require(["header/header-deferred"]);
});
// ...
require(["homepage/homepage"]);
// ...
});](https://image.slidesharecdn.com/wrangling-large-scale-frontend-webapps-150927211924-lva1-app6891/85/Wrangling-Large-Scale-Frontend-Web-Applications-32-320.jpg)
![Source Maps
/* ... LOTS MORE CODE ... */
[],window._entry=c}();
//# sourceMappingURL=http://dev.walmart.com:9873/js-dist-frontend](https://image.slidesharecdn.com/wrangling-large-scale-frontend-webapps-150927211924-lva1-app6891/85/Wrangling-Large-Scale-Frontend-Web-Applications-101-320.jpg)
Wrangling Large Scale Frontend Web Applications
- 1. @ryan_roemer | surge2015.formidablelabs.com WRANGLING LARGE SCALE FRONTEND WEB APPLICATIONS
- 2. The web is massively moving to the frontend
- 3. Users want rich and seamless experiences
- 4. Product owners want fast and nimble apps
- 5. Browser apps are now business critical
- 6. And, yes, even for the enterprise
- 8. LOTS OF JAVASCRIPT IN THE BROWSER WRITTEN BY LARGE TEAMS
- 9. Let’s dig into some large frontends at a high-traffic, top-five e-commerce site
- 11. The Numbers $10 billion FY 2014, $13 billion FY 2015 (est) 1.5 billion page views for Thanksgiving - Cyber Monday 2014
- 12. The Code 50+ JS applications 650K lines, 2500 files of JavaScript source More JavaScript lines & files than Java
- 13. The Technologies
- 14. The Dev Team A 2+ year website rewrite 50+ core frontend engineers 14 vertical teams / "tracks" ... and many external teams / partners
- 15. A TOUR THROUGH THE TRENCHES
- 17. My wrangling adventures as the JavaScript lead for the website & dev teams
- 18. A few battle-tested tips from the field...
- 19. ... with a focus on four personas
- 21. ARCHITECTS
- 22. Plan & build a strong foundation
- 23. Architects A real build Code organization
- 24. THE FUNDAMENTAL CHALLENGE: JAVASCRIPT IS THE WILD, WILD WEST
- 25. Architecture Challenges Browser is a single execution environment Code size / duplication is critical Hard to manage, easy to do wrong "Cowboy" legacy vs. large scale organization
- 26. Let's look at the architectural complexities of just one page...
- 27. THE HOMEPAGE
- 29. The Homepage Multiple, independent JS apps Code from 8 different teams Exemplary "in transition" page, somewhere between raw JavaScript & a SPA
- 30. JavaScript ON PAGE Direct page scripts 10 remote scripts 18 inline scripts LAZY LOADED Injected script tags 6 app entry points
- 31. On Page 2 application code 2 CDN infrastructure 2 internal ads 2 Google ads 1 fonts 1 IE-conditional polyfill 18 inline scripts
- 32. Lazy (Code) window._entry(function() { require(["header/header"], function () { require(["header/header-deferred"]); }); // ... require(["homepage/homepage"]); // ... });
- 33. Lazy (App) Asynchronously loaded 1 shared library 4 primary entry points 2 deferred entry points
- 35. A "REAL" BUILD
- 36. Build Challenges Modern JS apps are complicated (compression, polyfills, transpiling, etc.) Multiple JS apps on the same page is even more complex Supporting development & production / CDN
- 37. Use a Build Tool Choose an paradigm: AMD, CommonJS Choose a build tool / loader: RequireJS, Browserify, Webpack Take time to learn & evaluate the tradeoffs
- 38. Our Build Tools Legacy: AMD + RequireJS Modern: CommonJS + Webpack Transition: AMD & CommonJS + Webpack
- 39. Keep prod & dev builds blazingly fast
- 40. Make development identical to production
- 41. Build Complexities Sharing / caching common code (lib.js) Varying repository structures Sharing frontend & backend code Combining application, OSS, & 3rd party code
- 43. Plan your repository structure 1 → 14 → many repos
- 44. Have a bias for small & flexible
- 45. GUIDES
- 46. Coordinate the chaos, level up the development teams
- 47. Guides & Guidance The Meta team Educate Review everything
- 48. Guidance Challenges Thinking of the project as a whole Onboarding unfamiliar / junior developers Helping teams be consistent / complementary
- 49. THE META TEAM
- 50. Code from multiple teams all combined on one page
- 51. These folks represent the whole page
- 52. The Meta Team Set conventions & best practices Lead code reviews for consistency / DRY Develop common utilities & the deployment infrastructure
- 53. YOUR META TEAM TASK: HAVE ONE.
- 54. Our Meta JS Team 1.5 dedicated developers 6 "loaned" track developers
- 55. Our Meta JS Duties ~1 day of code review / week Chat channel participation Cross-track JS initiatives (i18n, multi-tenancy, PCI, etc.)
- 56. Meta JS Benefits Project-wide consistency & support Help tracks consider other teams Represent track interests in the core More engineers to support the whole project
- 57. EDUCATION
- 58. Continually write living documentation, close to the code
- 59. Take a "hands on approach"
- 60. Invest in rising developers & spread knowledge back to teams
- 61. CODE REVIEW
- 62. All code gets substantive & meta review
- 63. Including all third party & internal to the org vendor code
- 64. GATEKEEPERS
- 65. Protect the frontend through process & architecture
- 66. Gates & Gatekeepers Automate quality Minimize risks / exposure Require performance
- 67. Gatekeeping Challenges Feature pressure Poor quality code Unknown included code
- 68. AUTOMATE QUALITY
- 69. Static checking (eslint, jshint, jscs, etc.)
- 71. Integration / E2E tests
- 72. Code coverage
- 74. MINIMIZE RISK
- 75. Learn / identify your biggest risk areas
- 78. Code pattern risks: Defer & pray // I'm guessing... var HOPEFULLY_ENOUGH_TIME = 2000; // Wait until ready for next step. setTimeout(function () { theNextStep(); }, HOPEFULLY_ENOUGH_TIME);
- 79. Deployment / process risks: "Hotfeatures"
- 81. Frontend code must be small & fast
- 82. Teams are "feature-driven" unless performance is enforced & required
- 83. Enforce with audits "Web App Performance Measurement, Monitoring and Resiliency" www.webpagetest.org
- 85. Enforce with automation "Automating Web Performance Measurement"
- 86. Build your own tools where necessary
- 87. LIFEGUARDS
- 88. Create escape hatches & lifelines in production
- 89. Lifeguards & Life Savers Logging, Monitoring Debugging helpers
- 90. Lifeguarding Challenges Code executes remotely on different browsers Frontend errors are costly & often invisible
- 92. Your code runs & fails on a variety of browsers out in the wild
- 93. Log & capture everything
- 94. Get errors & messages to a remote store
- 95. And then aggregate, report, & alert
- 98. Give developers life lines when things go wrong
- 99. You ship this: !function(){var e="Hello Surge!",a=$("<h1 />"); a.text(e),$("body").append(a)}();
- 100. Your devs want this: (function () { var message = "Hello Surge!"; var $heading = $("<h1 />"); $heading.text(message); $("body").append($heading); }());
- 101. Source Maps /* ... LOTS MORE CODE ... */ [],window._entry=c}(); //# sourceMappingURL=http://dev.walmart.com:9873/js-dist-frontend
- 102. Publish in VPN on deployment
- 103. Hidden from end users Available to developers
- 104. All Together Now A "real" build Organized code The Meta team Education Code Review Automate quality Minimize risks Require performance Logging, Monitoring Debugging helpers
- 105. Some parting thoughts on the future
- 106. Embrace change
- 107. Reevaluate & refactor your infrastructure & organization
- 108. Have a transition strategy
- 109. HAPPY WRANGLING