Are you tired of waiting for your local server to refresh every time you make a change to the client?  Does the thought of configuring another developer box make you cringe?  Do managers wonder why adding a simple feature takes so long?

A retailer with a complex server page application wanted to convert it to a single page application (SPA).  The application consumed inline data from JSP pages and had no service oriented architecture (SOA) in place.  Below I will describe our successful approach to converting a legacy server page app into an SPA and the lessons learned from this project.

Why Go Through the Pain?

Many companies have invested large amounts of time and energy building legacy server page solutions.  These solutions typically solved a business need and are much more efficient than previous paper or Excel-based systems.  The ROI was obvious when these systems were built. However, the computational landscape has changed and clients now use a variety of form factors (tablets, phones, desktops, …) that have much improved processing power.

The SPA movement has been highlighted by extremely successful app experiences such as a Gmail.  These apps were more responsive and easier to adapt to the mobile ecosystem.  Gmail was one of the first web apps that actually performed like a desktop app.  SPA solutions load a shell page when they start, and leverage dynamic javascript combined with SOA to quickly handle user interactions.  Powerful SPA frameworks such as AngularJS, Backbone, and Ember have solved traditional issues with SPA architecture.  They effortlessly handle things like browser history and deep page linking.  In truth, now the pain of NOT switching to a SPA is greater than making the switch.  An SPA allows you to rapidly add features and greatly decrease the setup time for onboarding development resources.  Most importantly your users will love you for it.  They will appreciate faster view load times and more interactive experiences.

Ok, so now we have established switching to an SPA is worth it, but how do you go about making the switch?

Our Tech Selection

The first thing you need to do to convert to an SPA is select the frameworks and tools you will use.  Here are some recommendations:

  • We love the Ionic SPA framework for hybrid mobile development.  Its core is the beloved AngularJS.  Ionic expands upon this core with a CSS framework, and strong support for mobile.
  • Learn to love Gulp.  Gulp is the build engine favored by Ionic.  It will allow you to seamlessly compress/combine files, and transpile ALT CSS/JS.
  • Use ALT CSS/JS.  These technologies will make coding a lot easier and with Gulp they add very little complexity.  We ended up using Sass and Traceur.  For future projects we would now use Typescript due to a recent announcement that it will be used by Angular 2.0.

Our Approach

The project was for a mission critical mobile point of sale solution to augment our client’s store registers.  They wanted the option to release the new look and feel before the new REST API was completed.  This approach costs more but gives you progress sooner.

Here is what this approach looks like:

mpos_architecture_phases

  • Each JSP page just routes itself to one view in the SPA.  This approach lessened code change by retaining the highly server driven page navigation found within the application.
  • We wrote special controllers that call a getJspData function defined in the JSP and convert this data into our new client model.
  • To save data we leveraged the existing form posting behavior of the JSP.  We also reused most of the legacy javascript code that was already in place.
  • The first phase’s primary goal was to replace all views with CSS / HTML that could be reused in phase 2.  In phase 2 we just replaced the controllers with a new implementation that uses SPA navigation and manipulates data using the new REST API.

The transformation of the sales view after Phase 1:

Beforeold_item_entry Afternew_item_entry

Things We Learned

Below are some key take-aways from this project:

  • If you have time, skip the legacy controller step and develop directly against the new REST API.  The legacy controller requires the same server page development time sinks we are trying to avoid.  If you must go this route use a tool like JRebel.  It will drastically speed up this task.
  • We recommend creating a mock solution (NodeJS express, perhaps) that will allow the client to be run without the real server.  This will allow the client to be built before the server is ready.  Most CSS/HTML issues can be resolved before you attempt to wire up the backend.
  • Take this opportunity to tweak your design to account for modern mobile features such as the back button, or the soft keyboard.  You want to think about these things up front so that you can get stakeholder buy in early.
  • Build a domain model before you start your REST API.  The domain model will provide a blueprint for the REST API you will implement and is invaluable.  It will also help you to build a REST API that can be universally shared with other applications in your domain.

Take Action

Stop living with the misery of legacy server pages.  Use our approach to incrementally migrate your legacy application into a modern mobile SPA.  If you need help contact us at info@bluefletch.com and we can tailor a solution to your specific needs.



Related Posts

Matthew Ronemous

Matthew Ronemous

Senior Software Architect - Matthew’s a senior software architect with skills in Mobile, Microsoft .NET and ASP.NET application development. Matthew has experience in developing, supporting and training on Microsoft application architecture. Matthew is currently developing enterprise mobile web applications deployed to iOS, Android and Windows Phone devices. He holds a BS in Computer Science from the Georgia Institute of Technology.