"Refactoring to a Single Page Application" by Marcello Teodori In origine era il monolite. Spesso dietro una startup web di successo c'è un'applicazione in tecnologia singola (Java, Rails, ecc.) che cresce finché fatica a scalare all'aumentare degli utenti e con essa il relativo processo di sviluppo all'aumentare degli sviluppatori. Sul back-end una strategia consolidata è suddividere progressivamente il monolite in microservice. Per il front-end la soluzione duale è estrarre gradualmente il codice HTML, CSS e JavaScript in una Single Page Application, applicando diverse tecniche come quelle maturate durante la mia esperienza in Workshare.

1. Refactoring to a
Single Page Application
Marcello Teodori
ROME 18-19 MARCH 2016

2. Agenda
● a few definitions
● my experience in Workshare
● some take aways
● current state and future
● what’s your experience?

3. Your traditional web application built on
server side technology, whether MVC
or component based...
A definition for a “Multi Page Application”

4. “A single-page application (SPA) is a web application or
web site that fits on a single web page with the goal of
providing a more fluent user experience similar to a
desktop application.
In a SPA, either all necessary code – HTML, JavaScript,
and CSS – is retrieved with a single page load.”
Single Page Application on WikiPedia

5. “Code refactoring is the process of
restructuring existing computer code –
changing the factoring – without changing
its external behavior.
Refactoring improves nonfunctional
attributes of the software.”
(Code) Refactoring on WikiPedia

6. A refactoring tale: Workshare
1999
Workshare
Doc Comparison and
Metadata Cleaning
Desktop Products
Apr 2012
SkyDox acquisition
Document Sharing SaaS
Ruby monolith #1
aka Cirrus
Nov 2012
IdeaPlane acquisition
Enterprise Social Network
Java monolith
aka Social
Dec 2014
Dealroom acquisition
Legal Transaction WFE
Ruby monolith #2
aka Transact
now
Scaling
microservices on BE
SPA on FE

7. Cirrus
● Typical Rails
Application
● Does a Lot :)
○ including REST API!
● Does Too Much :(
● “Leverages”
ActiveRecord!
● You know the end of
the story...

8. Baaang!

9. The Masterplan!
● a spike on a SPA
○ called “supernova-ui”
○ validate we can do JavaScript
● phasing out all server side tech
producing front-end code
● migrate backend to microservices
○ Cirrus already provides JSON API
○ Social doesn’t and becomes first
microservice: Groups API

10. Let’s start!

11. Moving backend to microservices
Wally
Users Search
Groups
Social
Cards
Homepage Cards
Cirrus
Sign On
Users
Users Search
Activities
Storage
Files & Folders
Figitus
ADAPT BUILD
EXTRACT

12. ...and embrace JavaScript!
And for the frontend

13. TAKE #1:
setup a front-end build

14. Node allows front-end developers to take control
● pick your favourite javascript build
template
○ ex. a yeoman generator
● launch a development server
○ ex. via grunt-contrib-connect
● proxy your current web app or API
○ ex. via grunt-connect-proxy
● overlay your changes

15. JavaScript dependency management FTW!
chimera core-ui
files-ui groups-ui dealroom-ui
new-ui

16. Chimera, the myth of a style guide

17. TAKE #2:
build a client-side
application layout

18. Define your main application layout, client-side
● you will need some basic API
○ user API
○ account API
● application layout
○ topbar
○ sidebar
○ user menu
○ content
● a good candidate for offline

19. The Workshare Application Layout
topbar
contentsidebar
user
menu

20. TAKE #3:
leave login where it is

21. Authentication is complex, you don’t want to break it!
● typical web form login
● CSRF protection
● authentication via cookie
● support auth cookie on API
● single-sign on flows
● vanity domains

22. TAKE #4:
integrate pages via iframe

23. iframe are ugly but can be useful...
● content access when on same origin
● native API to communicate
○ window.postMessage
● easy to detect
○ window === window.parent
● listen to URL/hash changes

24. is a backend dev available? cool!
● create a custom page format
○ (ex. nova)
● serve a naked version of your page
with just the main content
○ in Rails :layout => false
● in your url_helper modify your href to
send a message via javascript to
your parent application

25. isn’t a backend dev available? oh no!
● load iframe as hidden
● hide application chrome and anything
which is not your main content
● patch CSS if necessary
● patch links to route on SPA
● repeat on URL/hash change

26. TAKE #5:
reuse your test suite

27. No refactoring without a proper test suite!
● Robot Framework
○ API tests
○ FE tests via WebDriver
● BDD style test definitions
● Re-use with minimal changes
○ if element selector don’t change!
○ adapt custom keywords
■ Navigate To (new URLs)
■ Locate Element (switch to iframe)

28. TAKE #6:
Apache (or nginx)
is your friend

29. ● map existing URLs you want to keep
● define your strategy to serve your SPA
○ on a subcontext /new-ui
○ on the root
■ via a custom header x-new-ui=true
■ on a different server
● proxy APIs and iframe pages
○ keep same origin
○ no need for CORS headers
It’s deployment time! From Node to Apache/nginx

30. TAKE #7:
manage new development

31. Evolve existing multi page URLs to single
● inject CSS from parent window
● build views in your SPA
● instantiate in multi page
● inject in parent DOM
● it’s really hard but a temporary
workaround until APIs are
available!

32. Now or Never:
current state and future

33. 3 years later and 42 microservices after...
● refactoring well is a long and
sloooow process...
● ...but we release weekly!
● the SPA approach allows iterating
much faster
● also designers with front-end skills
can easily build prototypes!

34. What didn’t work so well
● login pages must be fast!
● FOUC (flash of unstyled content)
● existing “SPAlets” taking full
control of the page (we had some
GWT ones) are hard to integrate
● IE9 and hash URLs
● bundle JavaScript in chunks

35. Disclaimer! Problems we didn’t have to solve
● it’s a web application, not a website
● URLs are forever
● SEO
○ googlebot crawls #! URLs
○ what about the others?
● browsers with JavaScript disabled
● IE less than 9
● first render speed
● should we go isomorphic?

36. TAKE #8:
build an amazing team!

37. Frontend and Backend teams working together
the Web Squad builds
the web frontend user
interface...
…but the Cirrus Squad
provides the API our
features build upon!

38. A Futurama Halloween!

39. Thanks!
ROME 18-19 MARCH 2016
contacts
marcello.teodori@gmail.com
@magomarcelo
All pictures belong
to their respective authors