Wrangling Large Scale Frontend Web Applications


The Presentation inside:

Slide 0

WRANGLING LARGE SCALE FRONTEND WEB APPLICATIONS @ryan_roemer | surge2015.formidablelabs.com


Slide 1

The web is massively moving to the frontend


Slide 2

Users want rich and seamless experiences


Slide 3

Product owners want fast and nimble apps


Slide 4

Browser apps are now business critical


Slide 5

And, yes, even for the enterprise


Slide 6

... which means


Slide 7

LOTS OF JAVASCRIPT IN THE BROWSER WRITTEN BY LARGE TEAMS


Slide 8

Let’s dig into some large frontends at a high-traffic, top-five e-commerce site


Slide 9


Slide 10

The Numbers $10 billion FY 2014, $13 billion FY 2015 (est) 1.5 billion page views for Thanksgiving Cyber Monday 2014


Slide 11

The Code 50+ JS applications 650K lines, 2500 files of JavaScript source More JavaScript lines & files than Java


Slide 12

The Technologies


Slide 13

The Dev Team A 2+ year website rewrite 50+ core frontend engineers 14 vertical teams / "tracks" ... and many external teams / partners


Slide 14

A TOUR THROUGH THE TRENCHES


Slide 15


Slide 16

My wrangling adventures as the JavaScript lead for the website & dev teams


Slide 17

A few battle-tested tips from the field...


Slide 18

... with a focus on four personas


Slide 19

ARCHITECTS GUIDES   GATEKEEPERS LIFEGUARDS  


Slide 20

ARCHITECTS 


Slide 21

Plan & build a strong foundation


Slide 22

Architects A real build Code organization


Slide 23

THE FUNDAMENTAL CHALLENGE: JAVASCRIPT IS THE WILD, WILD WEST


Slide 24

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


Slide 25

Let's look at the architectural complexities of just one page...


Slide 26

THE HOMEPAGE 


Slide 27


Slide 28

The Homepage Multiple, independent JS apps Code from 8 different teams Exemplary "in transition" page, somewhere between raw JavaScript & a SPA


Slide 29

 JavaScript ON PAGE Direct page scripts 10 remote scripts 18 inline scripts LAZY LOADED Injected script tags 6 app entry points


Slide 30

 On Page 2 application code 2 CDN infrastructure 2 internal ads 2 Google ads 1 fonts 1 IE-conditional polyfill 18 inline scripts


Slide 31

 Lazy (Code) wno.etyfnto( { idw_nr(ucin) rqie[hae/edr] fnto ( { eur("edrhae", ucin ) rqie[hae/edrdfre") eur("edrhae-eerd]; }; ) / .. / . rqie[hmpg/oeae]; eur("oeaehmpg") / .. / . }; )


Slide 32

 Lazy (App) Asynchronously loaded 1 shared library 4 primary entry points 2 deferred entry points


Slide 33

THE TAKEAWAY? IT'S COMPLICATED.


Slide 34

A "REAL" BUILD


Slide 35

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


Slide 36

Use a Build Tool Choose an paradigm: AMD, CommonJS Choose a build tool / loader: RequireJS, Browserify, Webpack Take time to learn & evaluate the tradeoffs


Slide 37

Our Build Tools Legacy: AMD + RequireJS Modern: CommonJS + Webpack Transition: AMD & CommonJS + Webpack


Slide 38

Keep prod & dev builds blazingly fast


Slide 39

Make development identical to production


Slide 40

Build Complexities Sharing / caching common code (l b j ) i.s Varying repository structures Sharing frontend & backend code Combining application, OSS, & 3rd party code


Slide 41

CODE ORGANIZATION


Slide 42

Plan your repository structure 1 → 14 → many repos


Slide 43

Have a bias for small & flexible


Slide 44

GUIDES 


Slide 45

Coordinate the chaos, level up the development teams


Slide 46

Guides & Guidance The Meta team Educate Review everything


Slide 47

Guidance Challenges Thinking of the project as a whole Onboarding unfamiliar / junior developers Helping teams be consistent / complementary


Slide 48

THE META TEAM


Slide 49

Code from multiple teams all combined on one page


Slide 50

These folks represent the whole page


Slide 51

The Meta Team Set conventions & best practices Lead code reviews for consistency / DRY Develop common utilities & the deployment infrastructure


Slide 52

YOUR META TEAM TASK: HAVE ONE.


Slide 53

Our Meta JS Team 1.5 dedicated developers 6 "loaned" track developers


Slide 54

Our Meta JS Duties ~1 day of code review / week Chat channel participation Cross-track JS initiatives (i18n, multi-tenancy, PCI, etc.)


Slide 55

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


Slide 56

EDUCATION


Slide 57

Continually write living documentation, close to the code


Slide 58

Take a "hands on approach"


Slide 59

Invest in rising developers & spread knowledge back to teams


Slide 60

CODE REVIEW


Slide 61

All code gets substantive & meta review


Slide 62

Including all third party & internal to the org vendor code


Slide 63

GATEKEEPERS 


Slide 64

Protect the frontend through process & architecture


Slide 65

Gates & Gatekeepers Automate quality Minimize risks / exposure Require performance


Slide 66

Gatekeeping Challenges Feature pressure Poor quality code Unknown included code


Slide 67

AUTOMATE QUALITY


Slide 68

Static checking (eslint, jshint, jscs, etc.)


Slide 69

Clientside unit tests


Slide 70

Integration / E2E tests


Slide 71

Code coverage


Slide 72

Continuous integration (CI)


Slide 73

MINIMIZE RISK


Slide 74

Learn / identify your biggest risk areas


Slide 75

Protect yourself wherever possible


Slide 76

Architecture risks: Injected HTML/CSS/JS


Slide 77

Code pattern risks: Defer & pray / Imgesn.. / ' usig. vrHPFLYEOG_IE=20; a OEUL_NUHTM 00 / Wi utlrayfrnx se. / at ni ed o et tp stieu(ucin( { eTmotfnto ) teettp) hNxSe(; } HPFLYEOG_IE; , OEUL_NUHTM)


Slide 78

Deployment / process risks: "Hotfeatures"


Slide 79

REQUIRE PERFORMANCE


Slide 80

Frontend code must be small & fast


Slide 81

Teams are "feature-driven" unless performance is enforced & required


Slide 82

Enforce with audits "Web App Performance Measurement, Monitoring and Resiliency" www.webpagetest.org


Slide 83

Enforce with process


Slide 84

Enforce with automation "Automating Web Performance Measurement"


Slide 85

Build your own tools where necessary


Slide 86

LIFEGUARDS 


Slide 87

Create escape hatches & lifelines in production


Slide 88

Lifeguards & Life Savers Logging, Monitoring Debugging helpers


Slide 89

Lifeguarding Challenges Code executes remotely on different browsers Frontend errors are costly & often invisible


Slide 90

LOGGING & MONITORING


Slide 91

Your code runs & fails on a variety of browsers out in the wild


Slide 92

Log & capture everything


Slide 93

Get errors & messages to a remote store


Slide 94

And then aggregate, report, & alert


Slide 95

Providers Rollbar Loggly Sentry Airbrake


Slide 96

DEBUGGING SUPPORT


Slide 97

Give developers life lines when things go wrong


Slide 98

You ship this: !ucin)vre"el Sre"a$"h /"; fnto({a =Hlo ug!,=(<1 >) atx()$"oy)apn()(; .ete,(bd".peda})


Slide 99

Your devs want this: (ucin( { fnto ) vrmsae="el Sre" a esg Hlo ug!; vr$edn =$"h /"; a haig (<1 >) $edn.etmsae; haigtx(esg) $"oy)apn(haig; (bd".ped$edn) }); ()


Slide 100

Source Maps / ..LT MR CD ..* * . OS OE OE . / [,idw_nr=}) ]wno.etyc(; /#sucMpigR=tp/dvwlatcm97/sds-rned / oreapnULht:/e.amr.o:83j-itfotn


Slide 101

Publish in VPN on deployment


Slide 102

Hidden from end users Available to developers


Slide 103

All Together Now A "real" build Organized code The Meta team Education Code Review Automate quality Minimize risks Require performance Logging, Monitoring Debugging helpers


Slide 104

Some parting thoughts on the future


Slide 105

Embrace change


Slide 106

Reevaluate & refactor your infrastructure & organization


Slide 107

Have a transition strategy


Slide 108

HAPPY WRANGLING


Slide 109

THANKS! surge2015.formidablelabs.com


Slide 110


×

HTML:





Ссылка: