DEV Community: BetterHealthcare

Monorepo and Trunk Based Development Using NX, GitHub Actions, and Argo CD

Bogdan Polovko — Tue, 01 Nov 2022 13:27:23 +0000

At BetterHealthcare we have a highly performant system that is built using Microservices architecture and is deployed on Kubernetes. As a small team, we have run into the issue, as the number of services was growing, it was much more costly and difficult to manage dependencies and deployments and significantly slowed down our sprint velocity. The system that we had in place was using a Multi-Branch, Multi-Repo structure, where each application was using separate GitHub repo and each repo had 3 branches — development, staging, and production. You can see the inefficiency of this system. If we needed to update and deploy all 40 services to production, we would need to create 120 PRs. The biggest inefficiency was that the code was rebuilt on each branch. Because we had to rebuild the image each time, we were not doing image promotion and had inconsistent deployments across the envs, which means 120 PRs = 120 Jenkins jobs and 40 pipelines. Not viable!

Idea

To fix this problem and make us much more effective and agile as a small team, we have created a set of requirements that our system will need to have and focused on 3 main components:

Migrate to monorepo where both backend and front-end apps could be stored and managed
Migrate from GitFlow to a Trunk Based Development
Have one single build pipeline that will be heavily optimized (harder to build, but easier to manage) where code is built once and could be promoted to any environment without rebuilding

For the monorepo management tool, we have evaluated multiple tools but decided to go with NX as it suited us best. For CI we stopped on GitHub Actions, and to manage the CD part we ended up using Argo CD.
So I came up with something like this:

And more detailed:

To be able to achieve this we had top go through some cultural change. All features needed to be ready to be rolled out to production at any time. That required heavy use of feature flags by the frontend, and more discipline on the backend as well as the use of the feature flags. Developer behavior had to be taken into the account during the design phase to eliminate any possibility that wrong code can get deployed to production.

Implementation

I have created a template and migrated the first app, and added the scripts that were the most critical — build, docker, test, serve, build-schema (we use GraphQL Managed Federation), docker-retag.
Built the workflows — test-and-build, main-build (development), promote-staging, promote-production
Tested and optimized workflows (pnpm turned out to be one of the best tools we could use to achieve fast installations of all packages becuase we now had to store both front-end and backend packages in the same repo)
In parallel DevOps have prepared a repo for all the k8s manifests and helm templates, and setup the ArgoCD on our clusters
We deployed first application
After testing and validations we have started gradually moving services to monorepo and abandoning previous repositories

The builds turned out to be super performant and very fast:

Promotion to staging and production was even faster:

The best part of this is that now a production release could happen at any time with a single action of creating an actual release in GitHub repo. The changelog is autogenerated and JIRA is automated to track all the code that was deployed.

In Argo CD the development and staging environment, we have enabled auto-sync and on production, we can still sync in batches to have more control where in the future we are planning to configure application sets and enable autosync to optimize it further.

Conslusion

The top performance was achieved by using the nx affected feature, which allowed us to always build only what is affected by the commit. pnpm cache, docker-buildx, and using cache have also improved it a lot. In numbers: previous development/staging/production deployment was taking 10 minutes on average per app, current setup allows to deploy in 3 minutes per app + another 25–30 seconds per additional application that is being deployed at the same run on development. For staging/production promotion that time has decreased from around 10 minutes on average to 2 minutes + 10–13 seconds per additional app that is being promoted. Which is a significant improvement in efficiency, speed, and quality! With the old setup if I needed to update packages in all 40 services that would take me at least 6.66 hours to deploy, not taking into account all the test runs, code pushes, and PR creation. With the current setup, that could be easily done in under 30 minutes. Further improvements like esbuild, direct pushes to the GitOps repo instead of auto merging PRs, more automation with JIRA, and more developer experience tooling will significantly speed up the development process!

How to Integrate with an EMR as a Digital Healthcare Startup

Damian Esteban — Mon, 25 Oct 2021 20:26:39 +0000

Introduction

The biggest technical challenge facing the American Healthcare System is the lack of interoperability between EMRs,largely due to the lack of a strong standard protocol. While HL7v2 is the most widely used messaging standard among Healthcare systems, it has loose and optional definitions which lead to discrepancies, and many application vendors do not support the latest and best-defined versions of HL7.

FHIR is a modern and robust standard that could solve this problem, but adoption is slow. Unless you are working with the major players like Epic, Cerner, AllScripts, or a handful of others it is unlikely that FHIR is an option.

At BetterHealthcare we create solutions for healthcare interoperability. Being integrated with BetterHealthcare means that patients can request accurate appointments that are updated in near real-time, and patient information can be sent back to the EMR. This increases efficiency for our customers, allowing them to effortlessly manage their schedules and intake new patients using our robust set of online tools.

What is necessary to integrate with an EMR?

Patience. As a startup, your team is able to move fast and efficiently. Once your project is specced and you have decided on your architecture your team is ready to roll. However, the path to integration with most EMRs is a long one that often involves dealing with many layers of bureaucracy. You’re on their time.
Flexibility. This applies to both the technology and the project timeline. The majority of EMRs do not have RESTful APIs, nor do they send data over HTTP. In my experience, the most common solution is the transmission of CSV files over SFTP. HL7v2 transmitted via MLLP is often an option, but if you don't have a Healthcare Integration Engineer on your team this can be challenging. In order to get an integration project started there is usually a security assessment which takes time, and larger companies may want penetration test results performed within the last year.
A willingness to learn. Even if you do not deal directly with HL7 you must become familiar with the different message types and their content. An excellent resource is Datica Academy's HL7 Primer.

How do I send and receive data from an EMR?

Stay tuned, more detailed blog posts will follow about different approaches. At BetterHealthcare we built a custom integration engine that leverages AWS Lambda, Dynamo, and Kinesis as a proxy layer that transforms incoming data into the desired format. There are many potential solutions. Here are a few services I recommend exploring:

The Google Cloud Healthcare API is a powerful service that allows you to consume and convert HL7v2, FHIR, and DICOM.
Azure FHIR Service is a fully managed FHIR server that you can get running in a few minutes.
FHIR Works on AWS is an official AWS Solutions Implementation that leverages AWS Lambda.
Redox Engine offers EMR integrations with a well-designed standard API. Their services are costly but can be worth the investment. This is your quickest option.
Mirth Connect is a powerful integration engine that allows you to send and receive any type of healthcare data.

The End

As you may have realized, this article barely scratches the surface of healthcare integration strategies. Expect more content on this topic soon and feel free to reach out to me if you have any questions.

Using GraphQL Fragments to Better Organize Your Code

Andrew Gionfriddo — Mon, 25 Oct 2021 20:04:40 +0000

At BetterHealthcare, many of the views we build have a rich amount of information broken down into smaller components throughout the page. In order to organize the information, we have started using GraphQL fragments. By organizing our code with a one component to one fragment relationship, we've been able to reduce network requests, improve code organization, and increase the reusability of our networking code.

What is a GraphQL Fragment?

A GraphQL Fragment is a chunk of reusable GraphQL code that can be used throughout a codebase. They allow for reusability and composability across your mutations and queries. They look like the following:

fragment UserFields on User {
    name
    age
    birthday
}

In this example, the name of the fragment us UserFields. When writing a fragment we have to say what GraphQL data type this fragment belongs to. In this case, it belongs on User. We can then define our fields that we want on our fragment the same we we would define fields in a query or in a mutation.

We can then use this fragment in our queries like so:

query GetUser {
    user {
        id
        ...UserFields
    }
}

This would be the equivalent of:

query GetUser {
    user {
        id
        name
        age
        birthday
    }
}

The Power of Fragments In Code Organization

Consider the following view:

We want to use one query for this page, but we don't want to have a query that's large and unwieldy. Similarly, we don't want to write a query for every component, because then we would have four round trip network requests. By using fragments, we can break down the query information and disperse it throughout the page's components while still only performing one network request.

We'll set up our file structure like the following:

src/
|-- Profile/
|---- ProfilePage.js
|---- ProfileUserInfo.js
|---- ProfileAccountPreferences.js
|---- ProfileRolesPermissions.js
|---- ProfileLoginContact.js
|---- ProfileWrapper.js

Within each component we'll set up a fragment that will be responsible for fetching the data that each of the components need to render. Let's look at a simplified version of the ProfileUserInfo.js as an example. We will colocate the fragment with the component that uses the fragment.

// ProfileUserInfo.js

import gql from 'graphql-tag'

export const USER_INFO_FRAGMENT = gql`
    fragment UserInfo on Profile {
        firstName
        lastName
        gender
    }
`

export default function ProfileUserInfo({ userInfo }) {
    return (
        <Card>
            <TextInput label="First Name" value={userInfo.firstName} />
            <TextInput label="Last Name" value={userInfo.lastName} />
            <SelectInput label="Gender" value={userInfo.gender}>
                <option>Male</option>
                <option>Female</option>
            </SelectInput>
        </Card>
    )
}

Pulling It All Together

Once we set up all of our components and fragments like above, we can then import them to one central query on parent component. In this case our parent component is ProfilePage.js. We can use a template string to insert the fragments into this query so we can then use it. All this code will result in just one network request despite the logic being broken up across several files.

// ProfilePage.js

import gql from 'graphql-tag'
import { useQuery } from '@apollo/client'
import ProfileUserInfo, { USER_INFO_FRAGMENT } from './ProfileUserInfo'
import ProfileAccountPreferences, { ACCOUNT_PREF_FRAGMENT } from './ProfileAccountPreferences'
import ProfileRolesPermissions, { ROLES_AND_PERMISSIONS_FRAGMENT } from './ProfileRolesPermissions'
import ProfileLoginContact, { LOGIN_CONTACT_FRAGMENT } from './ProfileLoginContact'
import PageWrapper from './PageWrapper'

const PROFILE_QUERY = gql`
    query Profile {
        profile {
            id
            ...UserInfo
            ...AccountPreferences
            ...RolesPermissions
            ...LoginContact
        }
    }
    ${USER_INFO_FRAGMENT}
    ${ACCOUNT_PREF_FRAGMENT}
    ${ROLES_AND_PERMISSIONS_FRAGMENT}
    ${LOGIN_CONTACT_FRAGMENT}
`

export default function ProfilePage() {

    const { data, loading, error } = useQuery(PROFILE_QUERY)

    if (loading) return <Loader />;

    return (
        <PageWrapper>
            {error && <ErrorMessage error={error} />}
            <ProfileUserInfo userInfo={data.profile} />
            <ProfileContactInfo contactInfo={data.profile} />
            <ProfileRolesAndPermissions rolesAndPermissionInfo={data.profile} />
            <ProfileAppointments appointmentsInfo={data.profile} />
        </PageWrapper>
    )
}

Reusability

Not only can we use our fragments in our parent, component, but we can use them in our mutations in our child components. As you can see from the screenshot of the view we're putting together, each component is responsible for updating its own information. We can use the fragments we wrote in our mutations. Lets pull up our ProfileUserInfo component again. This time we're going to build onto it. This version of the component will allow us to update the information by calling a mutation that makes use of our UserInfo fragment.

// ProfileUserInfo.js

import gql from 'graphql-tag'
import { useState } from 'react';
import { useMutation } from '@apollo/client'

export const USER_INFO_FRAGMENT = gql`
    fragment UserInfo on Profile {
        firstName
        lastName
        gender
    }
`

const UPDATE_USER_INFO = gql`
    mutation UpdateUserInfo($firstName: String, $lastName: String, $gender: Gender) {
        updateUserInfo(input: { firstName: $firstName, lastName: $lastName, gender: $gender }) {
            id
            ...UserInfo
        }
    }
    ${USER_INFO_FRAGMENT}
`

export default function ProfileUserInfo({ userInfo }) {
    const [firstName, setFirstName] = useState(userInfo.firstName);
    const [lastName, setLastName] = useState(userInfo.lastName);
    const [gender, setGender] = useState(userInfo.gender);

    const [updateUser] = useMutation(UPDATE_USER_INFO, {
        variables: {
            firstName,
            lastName,
            gender
        }
    })

    return (
        <Card>
            <form onSubmit={updateUser}>
                <button type="submit">Submit</button>
                <TextInput 
                    label="First Name" 
                    value={firstName} 
                    onChange={(e) => setFirstName(e.currentTarget.value)} 
                />
                <TextInput 
                    label="Last Name" 
                    value={lastName} 
                    onChange={(e) => setLastName(e.currentTarget.value)} 

                />
                <SelectInput 
                    label="Gender" 
                    value={gender} 
                    onChange={(e) => setGender(e.currentTarget.value)}
                >
                    <option>Male</option>
                    <option>Female</option>
                </SelectInput>
            </form>
        </Card>
    )
}

As you can see, we're now using this fragment in two places, the query that fetches the data, and the mutation that updates the data. You can imagine that if we had to use this chunk of information in other parts of our codebase, we could simply import it. The benefits would become even more apparent if this fragment was larger than just three fields.

Conclusion

Fragments give us a bunch of benefits:

Cleaner Code: We don't have one giant query sitting on our parent component, but rather the fields are located with the exact component that uses them.
Separation of concerns: The parent component doesn't have to know about what's going on in its children's components. All it has to do is create the query based on the fragments that the children give it.
Reusability. We can use the same fragments in multiple queries and mutations across our codebase to reduce code duplication.
Fewer network requests: By using fragments, we get the benefit of code separation without having to write a query (and thus a new network request) for every single component on the page.

When we first started writing GraphQL at BetterHealthcare, we struggled with out to properly organize our queries. We didn't want to do too many network requests, but we also didn't want to write massive queries for each page. Fragments provide the benefits of breaking up the logic of your queries without performing extra network requests.

Fragments also give you even more benefits when using Graphql Codegen and Typescript. We will explore this in a future post. I hope you learned something about the power of GraphQL fragments from this post!