Skip to content

A new SaaS tech stack for iService

A new SaaS tech stack

Unboxing - iService v9

More than a facelift, the latest version of iService® was an opportunity to completely retool its SaaS tech stack. 

AngularJS had its day, but the new JavaScript frameworks have a lot to offer. The agent interface was rewritten using one of the fastest frameworks available today. The new tech stack combined with a single page application architecture improves pages load speed by about 50% compared to its predecessor.

This blog takes a look at the new SaaS tech stack selected for the future of the product.

A new SaaS tech stack
Vue.js logo A new SaaS tech stack
The JS Framework

Goodbye AngularJSHello Vue.js - Our New SaaS Tech Stack

Speed and flexibility were important considerations in the selection of the new frontend JS framework for iService: Vue.js version 3. 

Speed was an important consideration for the new frontend of iService. The new version was built as a single page application (SPA), because load time for agents was very important. We’ve found that our updated SaaS tech stack is about 50% faster in Vue.js as a SPA than the prior multi-page application written in AngularJS. We considered the React and Angular frameworks, but Vue.js is a very lightweight framework in comparison. In addition to load times, getting developers up to speed quickly on a new framework was very important. 

Flexibility was another important consideration. iService allows users to integrate custom forms and views into the agent interface, and the Vue.js component architecture was a great fit. 

The CSS Framework

Bootstrap 5CSS Framework

As a responsive application designed for use within multiple devices, the CSS framework was important. iService has used Bootstrap for over a decade, so using the newest version of the most popular CSS framework on the planet was an easy decision.

Backend Language

C# - still relevantafter 20 years

The iService backend has over 15 years of engineering. Because iService is available as an on-premises application as well as cloud deployment, we have to ensure a simple migration path for all of our updates, including major releases. Our initial selection of C# was a good choice because it remains one of the top five programming languages today.

Realtime Updates

CustomWeb Sockets

After more than a decade using a third-party COMET server for real-time updates, we’ve created our own custom web socket solution with a fallback to long polling. Although it’s more work, creating our own solution gave us a lot of control and insight we didn’t have with a third-party system. We now have custom logging, alerts when connections are lost, and the ability to evolve the solution as needed.

Web Sockets
API First

API FirstDevelopment

iService v9 is an API (application programming interface) first application. With over 150 API endpoints, every function within the system is driven by an API that made it possible to do a parallel development approach. 

Migration Path

Rewrite vs Hybridor Parrallel Versions

Updating your SaaS tech stack is not an easy task. There are lots of considerations, because most of us can’t just put our business on hold while we create something new. Our options included creating an entirely new application, migrating to Angular using a hybrid approach, or a unique parallel approach. 

Rewrite – The simplest option is to just rewrite your application in the new SaaS tech stack. When you’re done, you throw away the prior version and then deploy your shiny new system. We support enterprise clients that need ongoing support and new features. This approach was discarded pretty quickly because we have to keep up with market demands.

Hybrid Angular Migration – Angular provides a method for integrating AngularJS and Angular code in the same application. If we were migrating to Angular as our front-end framework, this would have been a feasible option. But there were limitations within Angular that didn’t work for us, and we determined Vue.js was the best fit. 

Our Solution – We chose an approach that was a combination of a rewrite and a hybrid application. Because our backend was not being migrated, and we have an API first application, we were able to rewrite the frontend as a parallel system within the same website. This allowed us to have a single web interface, enhance the backend C# application, and keep the upgrade to the new tech stack transparent to users. By using two URL paths, we were able to build a single application using our existing DevOps infrastructure. This made deployments to our QA and Beta testing environment much easier than if we had two separate applications. 

If you’re updating your own tech stack, we wish you luck. The pace of change in technology will only accelerate in the future, and these types of updates are invevitable. Embrace the change and use it for your advantage.