Five stages of grief: Evolving a multi-page web app to a single page application
1. Five Stages of Grief:
Evolving a Multi-Page Web App to a
Single Page Application
Dallas, TX
11th April 2013
The Business of IT®
www.parivedasolutions.com
2. Who are we? And why should you listen to us?
Charles Knight
► Charles Knight
• Graduate of the University of Texas at Austin (MIS)
• 6+ years of Agile Software Development in MSFT
technologies
• Senior Manager at Pariveda Solutions
• charles.knight@parivedasolutions.c
om
Kevin Burnett
► Kevin Burnett
• Graduate of the University of Texas at Austin (Aerospace)
• Front-end guru: HTML, CSS, JavaScript, PHP, Rails, C#
• Consultant at Pariveda Solutions
• kevin.burnett@parivedasolutions.co
m
2
3. Table of Contents
► Background & A Real World Business Problem
► Denial – “We’re fine, we don’t need a Single Page Application (SPA)”
► Anger – “Dang it! I knew we should’ve built a SPA…”
► Bargaining – “OK fine, we’ll do what we can to convert this thing to a SPA”
► Depression – “Shoot, are we going to have to stick with the old app?”
► Acceptance – “It’s going to be okay, we have a way to bridge the gap”
► Closing Thoughts
► Questions
3
4. Background & A Real World
Business Problem
Acceptance
Denial
Bargaining
Anger
Depression
Background
4
5. Background
What are we talking about today?
Popular SPA Example: Gmail
► Single Page Applications (SPA)
• Follows the App + API architecture model
► Multi Page Applications (MPA)
• Follows the traditional n-tier / client-server architecture model
John Papa on Pluralsight
► What are we NOT talking about?
• Building a SPA from scratch using the latest and greatest
• Highly recommend following/listening to John Papa
Kubler-Ross Model
► We’ll be telling our real-life story of evolving a MPA to a
SPA Acceptance
Denial
Bargaining
Anger
Background Depression
5
6. Background
What is a Single Page Application?
► Single HTML page is loaded when the user initially loads the app
► Heavy emphasis on JavaScript
► Consumes data asynchronously from a RESTful API
► URL doesn’t change except for hash (#)
► No page reloads
► Universally accessible through a web browser
6
7. Background
Why should you care?
Consumer Apps
► Customer expectations of applications have
changed
► The “bar” has been raised for enterprise apps
Microsoft Technologies
► Microsoft is getting behind this idea
Polyglot graph
% of Programmers
► Polyglot programming is a
requirement these days
(JavaScript is everywhere!)
7
Time Coding
8. Background
Here’s a real world business problem we were faced with
► A Global Fortune 500 / S&P 500
company
► Company realized they needed to
leapfrog their competition
► Had gobs of data and needed cool
visualizations (WOW factor)
► Agreed to focus on modern browsers
(plus IE8)
► Aggressive development timeframe to
deliver in time for client budget season
(9 weeks)
8
9. Denial – “We’re fine, we don’t
need a Single Page Application
(SPA)”
Acceptance
Denial
Bargaining
Anger
Depression
Background
9
10. Denial
Our technology solution to this problem looks very familiar and safe at
first glance
Typical Application Architecture
► Modernizr
Client
► jQuery
► Foundation 2
► HTML/CSS
► JavaScript
► Razor Pages
► ASP.NET MVC3
Server
► Entity Framework
► SQL Server 2008
DEMO: Let’s take a look at the solution
10
11. Denial
Our initial instincts had us researching SPA frameworks, but we refused
to acknowledge the fact that we were trying to build a SPA within a MPA
architecture
► Briefly looked at Knockout.js
► Started with the admin section which didn’t have the
“Wow” factor requirement
► Needed more time to digest requirements and
design a solution
► Ended up with some SPA like capability constrained
within a MPA architecture
11
12. Denial
TAKEAWAY: You must understand when it makes more sense to build a
SPA over a MPA (and take the time to make the decision!)
► Heavy Static Content Focus
► SEO requirement
► Lack of JavaScript experience
► Need to support older browsers
► API availability and desirability
► Real-time performance requirement
► High UX requirement
12
13. Anger – “Dang it! I knew we
should’ve built a SPA…”
Acceptance
Denial
Bargaining
Anger
Depression
Background
13
14. Anger
Eventually, we began experiencing pain points which ultimately
convinced us that our initial architecture was preventing us from realizing
maximum value from a SPA
► Handling browser history / navigation / and bookmarking
► Maintaining State (dropdown selections, etc.)
► Performance degradation as # of view increased
► Decreased maintainability as additional views were added
Kevin Angry!
DEMO: Let’s see first hand the issues that caused our pain
14
15. Anger
TAKEAWAY: You must simulate a lot of built-in browser features when
building a SPA
► History navigation with browser back and forward buttons
► Canceling or stopping a load with the ESC or stop button
► Visual indicator that a page is loading
► Bookmarkability of pages
► Ability to open a page link in another tab / window
► Reloading the page should bring you back to where you last we
► Timeout detection in the event something goes wrong
15
16. Bargaining – “OK fine, we’ll do
what we can to convert this
thing to a SPA”
Acceptance
Denial
Bargaining
Anger
Depression
Background
16
17. Bargaining
We finally realized that we needed to shift how we thought about the
application architecture if we were to really build a SPA
Typical Application Architecture SPA Architecture
► Modernizr ► Modernizr
► jQuery ► jQuery
► Foundation 2 Client ► Foundation 2
► HTML/CSS
HTML
► HTML/CSS
► JavaScript ► A lot of JavaScrip
► Razor Pages
JSON
HTML
JSON
► ASP.NET MVC3 ► JSON
► ASP.NET Web API
Server
► Entity Framework ► Entity Framework
► SQL Server 2008 ► SQL Server 2008
DEMO: Let’s take a look at a Single Page Application solution
17
18. Bargaining
TAKEAWAY: You must build a well thought out client-side application
architecture and should leverage mature open-source JavaScript libraries
where you can
Client-side Architecture Breakdown
► Dependency
Resolution /
Module Loader
SPA Architecture
► DOM / AJAX
► Data Binding /
Client
MVVM
Framework
► Navigation /
History
► Helpers
► Data Push / Pull,
Storage,
Messaging 18
19. Depression – “Shoot, are we
going to have to stick with the
old app?”
Acceptance
Denial
Bargaining
Anger
Depression
Background
19
20. Depression
Trying to convert a MPA to a SPA while continuing to build new
functionality is like trying to change the tires on a moving car
► Wasn’t feasible to do a rewrite from scratch
► Limited time and resources prevented us from easily
implementing the needed new client-side
architecture
► Required everyone on the team to learn new
patterns and practices before they could be 100%
effective
DEMO: Let’s take a look at the JavaScript and focus in on some patterns and
practices
20
21. Depression
TAKEAWAY: You must follow proper design patterns and practices to
avoid building a JavaScript application that is unwieldy and difficult to
maintain and enhance
► Employ separation of concerns
► Use a MV* framework where possible
► Scope your objects appropriately
► Write modular decoupled code
► Test your code thoroughly
21
22. Acceptance – “It’s going to be
okay, we have a way to bridge
the gap”
Acceptance
Denial
Bargaining
Anger
Depression
Background
22
23. Acceptance
We eventually accepted the fact that evolving a MPA to a SPA would take
time and effort
Where we wanted to go
Where we were Piece-wise refactoring
DEMO: Let’s write some code!
23
25. Closing
FINAL TAKEAWAY: You can create rich web applications with SPAs but it
requires planning, a specific application architecture, and a different
developer skillset
► Do you have or want a RESTful API that returns JSON?
► How much (recent) JavaScript experience does you and your team have?
► Are you targeting specific browsers or are required to support a certain browser?
► Which framework will you use?
► Expect rapid changes in client-side technologies and plan accordingly
► Plan and expect to refactor code frequently
► Invest in learning client-side technologies and tools
► Don’t be afraid to test client-side code!
25
26. Closing
What tools and frameworks are available to those wanting to build a SPA?
Opinionated
Flexible
Library Framework
Where should you go to evaluate these frameworks? http://todomvc.com/
26
Single Page Applications are a class of web application that follow the App + API architecture model.Heavily relies upon JavaScript, a server-side RESTful API, and a single HTML page. Once the single page is loaded upon the initial request, the application dynamically updates parts of the page based on user interactions through AJAX calls to the RESTful API. -Views the modern browser as a legitimate application platform-Embraces HTML5, JavaScript, and CSS as enterprise class programming languages-Focused on intuitive design and a richer and more responsive user experience-Consumes JSON data from RESTful APIs
Caused by heavy investment in consumer-facing apps like Facebook, Twitter, and GmailDriven by advances in browsers and client-side technologiesSimple yet feature rich capabilities accessible on an ever increasing range of devices investing heavily in web api (anyone attend dallas day of dot net and hear scott hunter?)opening VS and ASP.NET to the community, welcoming community templates for SPAsJS is very popular and such a prolific programming language (Win8 apps, browser as a legit app platform)
The main challenge was to deliver an application that summarized and simplified the large amounts of data made available by the client and provide a “Wow” factor for their customers, while adhering to an aggressive development timeframe to coincide with their client's customer’s budget cycles