HealthJoy Connected Navigation Platform
Connected Navigation Platform
Guiding to high-value care

Mental Health
Behavioral Health
Foster a mentally healthy workplace

Employee Assistance Program
EAP
Supporting holistic wellbeing

    Virtual MSK Care Icon
    Virtual MSK Care
    Reimagining musculoskeletal care

    Virtual Primary Care
    Virtual Primary Care
    Powered by smart navigation

    SurgeryPlus COE Icon
    Surgery Centers of Excellence
    Best-in-class surgical outcomes

      Virtual Urgent Care
      Virtual Urgent Care
      Immediate care, any hour of the day

      Chronic Care
      Chronic Care
      A new approach to chronic care

      HealthJoy Integrations
      Integrations
      Flexible to any strategy

        5 min read

        HealthJoy 2.0: A Peek Under the Hood

        HealthJoy 2.0: A Peek Under the Hood

        We talk a lot about the front end of the HealthJoy 2.0 application, and the interface changes are certainly a drastic improvement. 

        They make the app easier to use, and it’s more beautiful. You can read all about these changes in Part 1 of this series introducing HealthJoy 2.0.

        In Part 2, we’re going to dig into less obvious, but absolutely critical, updates. We’ve done a whole lot more on the back end that members might never see, but those things also fundamentally change how HealthJoy works. I had the pleasure of adding some input into the front-end user interface (UI) changes and working with the designers, but the back end improvements remained a mystery. I would hear bits and pieces in meetings, but as we approached the launch, I realized I didn’t have a holistic view of all the changes. So, I decided to take a deep dive. In order to understand what’s new on the back end of HealthJoy 2.0, I interviewed my friend Alexey Tarazevich, Director of Product, Max Mashkov, Senior iOS Developer and Mobile Lead, and Sergey Tsisnevich, Software Architect, to discover all the changes.

        The HealthJoy platform has been built over the last five years, and like any startup, things were sometimes done quickly to get to market fast. Our platform consists of our app, a custom customer relationship management (CRM) system built to help our concierge team deliver quick service, a dashboard for HR, custom application program interfaces (APIs), and a wide variety of databases. As a project, HealthJoy 2.0 started a couple of years ago and represents a fundamental change to the architecture of our core product. These changes don’t encompass the complete list of everything that’s new, but rather what I considered most important, coming from a non-programming background.

        A stronger server connection

        When you stop to think about it, the wireless Internet on your phone is pretty amazing. You have access to the world’s information at your fingertips. These connections that we take for granted are very complicated and don’t always work as planned. In the older version of our app, if you were in a location with terrible Internet, you might find yourself getting error messages while using HealthJoy. With HealthJoy 2.0, we’ve created a “self-healing” strategy to maintain a connection to the server and be more forgiving if problems occur. We’ve made changes to how the app refreshes, maintains its present state, and syncs to our system. This might not be something you appreciate if you’re in a city with a great connection, but it will feel vital if you get hurt while hiking outdoors and want to speak with a medical provider.

        New call-to-action

        Moving to gRPC: A lean and mean communication framework

        During the 1990s, as instant messengers gained a foothold with AOL, a new open source instant messaging protocol called XMPP was created by the open source community. We originally built HealthJoy as a full featured XMPP client, which uses a very verbose (read large) markup communication protocol over web sockets, using XML-based content. While there are many features of XMPP we still like, we were able to take advantage of Google’s gRPC project by encapsulating XMPP and moving a majority of the business logic from the client (the mobile application) to our servers. This allows us to manage complexity in one place cross platform and reduce the overall size of the installation file on your mobile device. Further, we have adopted Protobuf, a serialization library, that further reduces the payloads between our servers (less data to make the magic happen!). All of these architecture decisions give our members increased stability, better battery life, less data usage, and a far snappier experience.

        Our servers are doing the heavy lifting

        Our previous chat system depended on a user’s phone to do the processing locally. This approach worked perfectly, but with heavy usage could put more demands on a user’s battery. Our app was never really too much of a battery hog (not like many of the games I play), but we knew we could do better. We’ve moved almost all of the chat process to our server. At the end of the day, you might never notice a .1% difference on your battery, but our programmers want to live up to best practices.

        A Shift from the Angular framework to React

        Some of the features within our app, like our benefits wallet and inbox cards, leverage a hybrid app development strategy through WebViews. A WebView is an embeddable browser that an application can use to display web content. With this type of front-end development, programmers choose frameworks and libraries to make things easier. We initially used Angular, but we switched to React. Facebook created the React framework in 2013, and it’s since grown to be the leading choice for developers. We’ve seen a considerable performance lift in all our WebViews, which we know users will appreciate. The file size of many files dropped by up to 85%, which improves performance significantly.

        A more native approach to programming

        When we began the development of HealthJoy, we chose Objective-C and Java as our primary programming language for iOS and Android, respectively. It’s been around since the 80s and is a solid choice for programming. I remember learning it in college in the 90s and using it for small projects. Since our launch, both Apple and Google have designated preferred programming language, Swift and Kotlin respectively, that are tailored to their platforms. Both Swift and Kotlin are fantastic programming languages that have tons of unique features that work wonderfully on iOS and Android. We’ve fully transitioned all our code to these development environments, which allows us to continue to deliver rich native experiences much faster than before.

        Coupling, but not dating

        So, when designing software, the term “coupling” apparently referred to the degree of interdependence between software modules. Low coupling is a sign of a well-structured and planned system, which HealthJoy 2.0 architecture has now achieved. This makes our system easy to maintain, extend, and scale. Going forward, we are far more agile in our development.

        An odyssey away from Monoliths

        Over the last few years, companies like Netflix, Google, Amazon, and other technology leaders have switched over from monolithic software architecture to microservices. The benefits of this move include flexibility, scalability, agility, and more. A monolithic application is built on one large codebase, with major limitations on feature improvements, scaling features, and speed of delivery. Microservices break this down into a collection of smaller independent units which communicate with each other through APIs. With HealthJoy 2.0, we’ve now officially moved to microservices. As we scale our engineering team, this new architecture will give our team more flexibility for future development.

        Other technical improvements (warning: jargon ahead)

        We’ve also implemented a series of other large and small changes that significantly impact performance, simplicity, and scalability, things our members will appreciate every day. Some of those additional changes: (feel free to skip this section if your head spins when getting into the technical weeds).

        We’ve moved to OpenResty (Nginx / LuaJIT) to help further scale our web applications.

        Our DevOps team is using ELK Stack (Elasticsearch, Logstash, and Kibana), Prometheus, and Grafana for system and application logs collection, aggregation, visualization, search and monitoring.

        We’ve also made drastic changes to our automation testing, extensively leveraging Appium, Cucumber, Jenkins, Selenium, and TestNG. We’ve also added Sauce Labs for cloud-based live, automated and continuous testing.

        These technical improvements ensure that we deliver the best code to our members every time.

        A round of applause for our entire tech team

        As you’ve read, HealthJoy 2.0 was way more than just a user interface polish. This was a huge endeavor for our entire technical team, and I personally want to thank everyone involved in delivering a fantastic product. This is a revolutionary change for us as a company, and it sets us up for innovation in the future. These changes will help us to live up to our company mission to guide our members to affordable, high-quality healthcare.

        Want to see it for yourself?

        Get a demo of the all-new HealthJoy 2.0. 

        HealthJoy Receives “Chicago’s Best Places to Work” Award

        HealthJoy Receives “Chicago’s Best Places to Work” Award

        I’m excited and honored to announce on behalf of everyone at HealthJoy that Built In selected us as one of Chicago’s best places to work in 2020 in...

        Read More
        Introducing HealthJoy QuickLaunch

        Introducing HealthJoy QuickLaunch

        Our healthcare system is facing an unprecedented challenge. Some reports estimate we can expect the number of potential coronavirus infections in the...

        Read More
        Navigating an Employee Benefits Plan Design Change

        Navigating an Employee Benefits Plan Design Change

        Every year, companies must decide on how much they’ll need to change their existing employee benefits. As annual rates increase, it can be...

        Read More