Refactoring to aSingle Page Application Marcello Teodori

ROME 18-19 MARCH 2016

Agenda

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

Your traditional web application built on server side technology, whether MVC or component based...

A definition for a “Multi Page Application”

“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

“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

A refactoring tale: Workshare

1999

WorkshareDoc Comparison and Metadata CleaningDesktop Products

Apr 2012

SkyDox acquisitionDocument Sharing SaaSRuby monolith #1aka Cirrus

Nov 2012

IdeaPlane acquisitionEnterprise Social NetworkJava monolithaka Social

Dec 2014

Dealroom acquisitionLegal Transaction WFERuby monolith #2aka Transact

now

Scalingmicroservices on BESPA on FE

Cirrus

● Typical Rails Application

● Does a Lot :)○ including REST API!

● Does Too Much :(● “Leverages”

ActiveRecord!● You know the end of

the story...

Baaang!

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

Let’s start!

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

...and embrace JavaScript!

And for the frontend

TAKE #1:setup a front-end build

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

JavaScript dependency management FTW!

chimera core-ui

files-ui groups-ui dealroom-ui

new-ui

Chimera, the myth of a style guide

TAKE #2:build a client-side application layout

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

The Workshare Application Layout

topbar

contentsidebar

usermenu

TAKE #3:leave login where it is

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

TAKE #4:integrate pages via iframe

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

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

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

TAKE #5:reuse your test suite

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)

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

● 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

TAKE #7:manage new development

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!

Now or Never:current state and future

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!

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

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?

TAKE #8:build an amazing team!

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!

A Futurama Halloween!

Thanks!

ROME 18-19 MARCH 2016

contactsmarcello.teodori@gmail.com@magomarcelo

All pictures belongto their respective authors