how we scaled front end development - practical lessons on scaling js apps

Post on 10-Jun-2015

575 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Every few days, a cool new library makes its way into the world of front end development. While every library has something interesting to offer, the practical question every front end developer has to answer is how well it weaves into the JS stack used by the existing apps. To add to it, the continuous evolution of these libraries only complicates the problem further. The past year saw an extensive growth in the space of what we call “Front End Ops”, where tools such as Gulp, Bower, Yeoman, etc. have been key in moving a lot of automated work into JS, that previously used to be solved using Ruby, Python, or similar scripting solutions. In this talk, I will use our startup story as a backbone to elicit the various techniques, principles and strategies we used to conceptualize, build, and ship our JS apps. Of course, the challenges are included as well!

TRANSCRIPT

How We ScaledFront End DevelopmentPractical Lessons on Scaling JS Apps

Praveen Selvam

The Indix Story

2012 2013 2014

$

Everything about Prices Everything about Products Scale & Velocity

$4.5MSeries A

$9MSeries A1

Indix - Today

450M+Product URLs

Data

Team

1500+Stores

42K+Brands

4 TBData in / day

2Countries

60Employees

30Engineers

The Indix JS Story

Year 1 Year 2 Year 3

Rapid prototyping

Build, Scrap, Repeat...

Optimize and Stabilize Scale, Productivity,Real User Monitoring

One app to many

Build

ScrapRepeat

Year 1

Rapid Prototyping

Inventing new stuffEffectiveness of product value

Engineering velocityAdaptability to changeFunctional coveragePresentable software

Why?

Aesthetics / UsabilityStability

PerformanceMetrics / MonitoringAutomated testing

Extreme focus on... Less importance for...

Templating:

Behaviour:

Data Mashup:

Tooling choices - “Simple”

960.gsjQuery + UIPlay / Rails

Year 2

Optimize and Stabilize

Enter the market quickly

Metrics / MonitoringFully automated testing

Dependency managementShared knowledge of code

Being production readyAesthetics / Usability

Stability & PerformanceEarly customer feedbackSome automated testing

Why?

Extreme focus on... Less importance for...

Templating:

Behaviour:

Asset packaging:

Data Mashup:

Caching:

Tooling choices - “Strategic”

Twitter BootstrapBackboneRailsRailsnginx

Benefits

● Bootstrapo Community tested templates & components

● Backboneo Adapters for external librarieso UI Routing - Drives the right abstraction

● Rails o Out of the box solutions

Major Challenge

Doing things in parallel

Customer version vs Development version

Managing dependenciesas the code grows

Customer version vs Development version

Feature flags

Customer version vs Development version

Branching

Frequent pulls from master into new branch

Keeping the branched time short

Managing dependencies as the code grows

Require.js + Rails Packaging

Require.js Rails Packaging

page1[needs]

mod1, mod2

sub_m1.js + sub_m2.js=

mod1_56789.js

Year 3

Scaling up as a team

Scale Productivity Real User Monitoring

One App to many Apps

Managing Scale

Larger / untidy code base=

Slower progress

Managing Scale

Keeping things in place

Using coveragefor cleanupFeature flag maintenanceRefactoring

Keeping things in place

CSS Usage

Keeping things in place

JSCoverage

Developer Productivity

Having more time

=

Scope for newer inventions

Developer Productivity

Core development activities

Developer Productivity

Yeoman

Developer Productivity

Yeoman

Developer Productivity

Grunt

Compilations LintingMinification

DocumentationDeployments and more...

Developer Productivity

Grunt

Source: Addy Osmani’s Presentation

gruntfile.js

Developer Productivity

Simpler Grunt Alternative

Developer Productivity

Bower

Developer Productivity

Bower

bower.json

Developer Productivity

Codekit

Developer Productivity

Alfred Workflows

Developer Productivity

Alfred Workflows

Real User Monitoring

Predictingdowntime

Reproducingcontext

Reaching outto Engineers

Predicting down time

Track client side issues

Predicting down time

NewRelic Dashboard

Predicting down time

Degradation signals

Predicting down time

Pingdom Transaction Checks

Reproducing context

Mixpanel Live Tracking

Reproducing context

Insights from Analytics

Reproducing context

Splunk Stacktraces

Reproducing context

SourceMaps

Reaching out to Engineers

PagerDuty

From One App to Multiple Apps

Standardizing UXDesign guidelines

IX LibraryCommon pieces of functionality

Recap

The Indix JS Story

Year 1 Year 2 Year 3

Rapid prototyping

Build, Scrap, Repeat...Optimize and Stabilize

Scale, Productivity,Real User Monitoring

One app to many

Twitter Bootstrap

Backbone

Rails

nginx

Feature Flags, Branching

Require.js

Coverage / Clean ups

Yeoman, Grunt, Bower

Codekit, Alfred

NewRelic, Pingdom

Mixpanel, Splunk, SourceMaps

PagerDuty

960.gs

jQuery + UI

Play / Rails

Key Learnings

Choose technologies wiselyBalance prototyping vs Being production ready

Stay up to dateBalance Customers vs Refactoring to absorb the best

technologies

Avoid disruptions to shipped products

Stay in control of products that’s shipped

Optimize your time and stay productive

Thank youpraveen@indix.com

www.praveenselvam.com

top related