FRONTEND 'VS' BACKEND
GETTING THE RIGHT MIX
Created by / /Bob Paulin @bobpaulin bob@bobpaulin.com
ABOUT ME
Independent Consultant
Business Enablement
Web Centric
A LONG TIME AGO I CREATED "FACEBOOK"
College students love seeing pictures of their friends doing
stupid things at parties
Photoshop can be used to make funny pictures even more
funny
Do not host anything on your school's web property
WHAT THIS TALK IS NOT
Deep Dive into web frameworks
THE answer on which architecture is better
WHAT THIS TALK IS
Using Frontend and Backend frameworks together
How developers work together
Advantages and disadvantages of architectures
Some empirical data on architecture performance
HOW DID WE GET HERE?
Complexity
Corporate Culture
Developer Aptitudes
BACKEND DEVELOPER
TYPICAL BACKEND DEVELOPERS
Focus on the server side
Data Storage and Retrieval
System Architecture
Availability
Does it work?
FRONTEND DEVELOPER
TYPICAL FRONTEND DEVELOPERS
Client/Browser focused
Information Architecture
Closer to creative/design
Does it look right?
DOES THIS MODEL ACTUALLY WORK?
CHALLENGES WITH FRONTEND/BACKEND
TEAMS
COMPETING REQUIREMENTS
FREQUENT HANDOFFS
FRAMEWORKS OFTEN COUPLE FRONTEND AND
BACKEND TECHNOLOGIES
ANOTHER WAY TO THINK ABOUT THE PROBLEM...
AN AMERICAN FOOTBALL ANALOGY
FRONTEND DEVELOPERS = OFFENSIVE BACKS
FRONTEND DEVELOPERS = OFFENSIVE BACKS
Score Points with Customers
Work is highly visible
Can be limited by poor play at other positions
Often get the biggest share of blame when things go wrong
and praise when things go right
BACKEND DEVELOPERS = OFFENSIVE LINE
BACKEND DEVELOPERS = OFFENSIVE LINE
Enable other positions to do great work
Work is not usually visible
Mistakes often have a cascading effect
Generally only get blamed when things go wrong. When
things go right .... well things are just suppose to work all the
time right?
OK ENOUGH ABOUT YOUR PEOPLE PROBLEMS
LETS LOOK AT SOME CODE ALREADY!
3 DIFFERENT APPROACHES TO THE SAME WEB
SITE
REQUIREMENTS - A BOOK REVIEW SITE
Allow users to select keyword preferences
Allow users to view and post review comments about a
specific book
Should use responsive design. Because, well, that's the hot
new thing right?
A BACKEND RECIPE
Spring MVC
Spring Data
MongoDB
Apache Tomcat
Apache Http Server
JSP
Twitter Bootstrap
WRO4J
Amazon Cloudfront (CDN)
DESIGN
Cache Google Api Response for Books and Book Search
Consolidate and minify CSS and JS using WRO4J
Page turn between Homepage and Reviews
Page can't be cached but static resources can
CODE
Spring MVC Controller
Spring Data Services
WRO4J Config
ARCHITECTURE
A FRONTEND RECIPE
Brunch
ChaplinJS
CoffeeScript
Handlebars
Node.js
Apache CXF
Spring Data
MongoDB
Apache Tomcat
Apache Http Server
Twitter Bootstrap
Amazon Cloudfront (CDN)
DESIGN
All Services are done through AJAX
Apache CXF Provides Restful
Services(Consumers/Producers) JAX-RS
Single Page Application Behavior via Chaplin
Node.js but only for Brunch Compilation
All pages and frontend code cached
Some Data Services Cached: Volatile vs Static
CODE
index.html - Look Ma, only 16 lines of server side html!
Chaplin Controller
Chaplin Views
Chaplin Models
Handlebars Templates
Apache CXF JAX-RS
INDEX.HTML
<!doctype html>
<!--[if IE 8]> <html class="no-js lt-ie9" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Frontend Home Page</title>
<meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="/frontend-web/stylesheets/app.css">
<script src="/frontend-web/javascripts/vendor.js"></script>
<script src="/frontend-web/javascripts/app.js"></script>
<script> </script>
</head>
<body>
</body>
</html>
require('initialize');
ARCHITECTURE
A MIXED RECIPE
FRONTEND TECH
Backbone
CoffeeScript
Handlebars
Twitter Bootstrap
BACKEND TECH
Spring MVC
Handlebars.java
WRO4J
Apache CXF
Spring Data
MongoDB
Apache Tomcat
Apache Http Server
Amazon Cloudfront (CDN)
DESIGN
Some Services are done through AJAX others on Serverside
Apache CXF Provides Restful
Services(Consumers/Producers) JAX-RS
Page turn between Homepage and Reviews
Page can't be cached but static and service resources can
Page actions do not require page turns
Templates are shared between frontend and backend
Book Searches are cached with data URIs
CODE
Cached Controller
WRO4J
Backbone Views
ARCHITECTURE
TEST DESIGN
Web Page Test
Browser - Current Chrome
Location - Virgina
Click events tested locally using Chrome Developer Tools
TEST SCRIPT
1. Homepage View
2. Add a New Book Preference
3. Open a Review
4. Add A Comment
BACKEND HOMEPAGE WATERFALL
FRONTEND HOMEPAGE WATERFALL
MIXED HOMEPAGE WATERFALL
BACKEND REVIEW WATERFALL
FRONTEND REVIEW WATERFALL
MIXED REVIEW WATERFALL
DISCUSSION
What does this data tell us?
What does it not tell us?
Which is most scalable?
Variations between Browsers
CONCLUSIONS
BACKEND SUMMARY
Most consistant load times
Better performance with static data
Less requests
Full page loads for incremental changes can prevent optimal
performance
Data is embedded within the page so it can't be separated
into different TTL
Dynamic content within the JSP prevents pages from being
cached. Increases traffic to the origin
FRONTEND SUMMARY
Requests handled independently. Enables fine grain caching
Eliminates page turns to refesh data model
Significant caching opportunities at the edge
Generates more requests
Higher memory and CPU consumption on the client end
MIXED SUMMARY
Allows the most flexibility in how information is loaded
Code reuse at the template level
Eliminates some page turns related to data updates
Performance suffers when both page and services are
volatile (non-cachable)
REFERENCES
CODE AND PRESENTATION
Frontend "vs" Backend
FRONTEND
BackboneJS
Brunch
ChaplinJS
CoffeeScript
Handlebars
Twitter Bootstrap
BACKEND
Apache CXF
Handlebars.java
MongoDB
Spring Data
Spring MVC
WRO4J
BOB PAULIN
/ /BOB PAULIN @BOBPAULIN BOB@BOBPAULIN.COM

Frontend 'vs' Backend Getting the Right Mix