Over a million developers have joined DZone.

Benefits of Tweaking Your Technology Stack

DZone's Guide to

Benefits of Tweaking Your Technology Stack

No matter how fancy your single-page application approach is, it is no good if your users get tired while waiting for it.

· Integration Zone ·
Free Resource

How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.

Our team began implementing Service Oriented Architecture (SOA) almost a year ago, and we have already felt the advantages of this approach. SOA helps us to decouple application features, makes us more API-friendly, and makes our whole system more fail-safe. Now, a failure in a single service will not result in platform downtime and it is much easier to find and fix problems in a separate service. The whole development team now sleeps much better.

However, this article is not about SOA, but about an experiment to create a whole new product as a service. We wanted to create a lightweight application for people who need translations fast and easy. There should be a simple flow: upload files, pay for translation, download files when translations are ready. The goal was to quickly build a simple prototype to get feedback from users. Ninety percent of the prototype was front-end, using the existing API from other parts of the system to minimize development effort.

One of the advantages of creating separate services is how much easier it is to try something new. Not being tied to your old codebase and infrastructure gives you more options. So we decided to try a single page application. It was a reasonable decision, as our back-end was supposed to be minimal. To make thing faster, we used a familiar stack: Marionette, require.js, and Grunt.

Basically, the application was built outof packages that were noted in the require-config.js:

packages: [    {        name: “main”,        main: “main”,        location: “app/main”    },    {        name: “orders”,        main: “main”,        location: “app/orders”    },    {        name: “registration”,        main: “main”,        location: “app/registration”    }    …]

The entire application was built with the r.js tool in a single file. To configure r.js we used a build.json file similar to the docs example:

({    appDir: “../”,    baseUrl: “scripts”,    dir: “../../appdirectory-build”,    modules: [        {            name: “main”        }    ]})

The main package handles application level tasks:

  1. Authentication.
  2. Navigation.
  3. Retrieving application context.

All other packages are imported by the main package and instantiated when needed.

We needed to support a few start up flows for our front-end application. For example:

Load Scripts → Check Auth → Not Logged In → Sign in → Get Context → Instantiate ‘orders’
Load Script → Check Auth → Not Logged In → Instantiate registration → Get Context → Instantiate ‘orders’
Load Script → Check Auth → Logged In →Instantiate ‘orders’

When we completed the first version of the app, we added a few libraries to track events: Trackjs, Mixpanel, Google Analytics. We also used Fullstory to analyze user behavior. Then, we created a fancy landing page, complete with an FAQ and a prominent Upload button. Done! We deployed the application so the business stakeholders could begin to gather feedback.

From our perspective, everything was fine. The web app seemed light and fast, it had its own landing page, so the user was able to start using it without any redirects.

However, engagement data surprised us. Many visitors closed the page before it even finished loading. We didn’t show the landing page before the app was initialized, and depending on a visitor’s connection speed, this could take a few seconds. Turns out, these few seconds cost us half of our potential users.

We started to search for a way to speed up the page load. The heaviest parts of the page were scripts. These were already minified and built into a single file, but it was not enough, so we decided to split scripts into multiple files and defer their load.

As our application was already split into packages, this wasn’t so hard. Initially, we load only one main package that does not explicitly depend on other packages. Now, when we need to instantiate code from some other package we have to require it first:

require([“orders”], function(Orders){    var controller = new Orders(config);})

Also, we had to adjust our build script to generate separate files for each package, instead of a single file for the application. To do so we needed to change the modules option in our build.json:

modules: [    {        name: "main"    },    {        name: "orders",        exclude: ["main"]    }    ...]

We need an exclude option here to prevent including the same dependencies in different files. For example, if jquery is included in main, it wouldn’t be included in orders even if orders depends on it. Even when we migrated to webpack there was no need to configure anything, webpack recognizes the require statements and creates a separate bundle file during build.

These changes slightly improved page load speed. However, it still wasn’t enough. So, we made the decision to show a landing page as soon as it was available and load scripts in the background. This approach created a better user experience, which was verifiable from improved engagement and funnel analytics.

So, don’t forget that no matter how fancy your single page application approach is, it’s no good if your users get tired of waiting for it. Don’t test their patience!

Build and deploy API integrations 7x faster. Try the Cloud Elements 100% RESTful platform for 30 days free. Access your trial here.

performance ,speed ,technology stack ,soa

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}