DEV Community: Shane Jarman

Why GraphQL Is Perfect For Microservices

Shane Jarman — Wed, 13 Oct 2021 00:04:36 +0000

A well-designed microservices architecture is an amazing thing. When each service is responsible for its own specific domain and can be deployed independently, it allows for unparalleled flexibility and productivity for backend teams. However, very few decisions are all benefit with no cost - including our decision to choose microservices over a monolithic backend.

Before we migrated our backend to GraphQL, one trade-off that we encountered was the additional complexity that it imposed on our client-side networking code - especially when we had to create views that used data from multiple services.

For example, our application had a "appointment list" view that looked a little something like this:

In a monolithic architecture, the networking code for this page could be trivial. It would be very uncommon to look at an appointment without provider, patient, and clinic details, so you probably would want to JOIN those tables in the appointments query and return them every time.

For example:

[MONOLITH]: /companies/id/appointments

{ result: [Appointment] } <--- joined with provider/patient info

However, this JOIN was not possible in our microservices architecture since Appointment Service does not have access to provider and patient data.

Our client applications now had to query three different services via four different endpoints instead of querying one resource that returned all the data they needed. Additionally, the client applications did not have access to the IDs of the required providers, patients, and clinics until after we loaded the initial appointments query!

So the client side networking logic ended up looking like this:

- [APPOINTMENT SERVICE] - GET /companies/id/appointments

.. wait for data ...

{ result: [Appointment] }

THEN:
- [PATIENT SERVICE] - GET /patients/id x 5
- [COMPANY SERVICE] - GET /clinics/id x 5
- [COMPANY SERVICE] - GET /providers/id x 2

Not ideal! The requests were fast, but almost twice as slow as the monolithic version would have been since we had to wait for the initial appointments request to complete before fetching the rest of the associated details.

GraphQL To The Rescue

We worked around these limitations for a while, but realized that eventually something had to give. The microservices infrastructure that the backend team loved so much was making the developer experience for our frontend and mobile teams extremely frustrating. We needed a solution, and we needed one fast.

Luckily, there was a brand new innovation in the GraphQL ecosystem that was the perfect solution for our problem - Apollo Federation.

Apollo Federation allowed each microservice to manage its own "subgraph" while abstracting that complexity from our client applications. All our subgraphs were stitched together in the GraphQL Gateway to create one seamless Federated Graph that could easily be accessed via a single endpoint.

The new request for the company appointment list was:

- [GRAPHQL GATEWAY] - POST /graphql

query {
  companyAppointments { <--- [APPOINTMENT]
    startTime
    patient { <--- [PATIENT]
      firstName
      lastName
    }
    provider { <--- [COMPANY]
      firstName
      lastName
    }
    clinic { <--- [COMPANY]
      clinicName
      lastName
    }
}

Our clients did not need to know which backend service was resolving the data they were querying, and they only had to make one request to complete this view. This new query was also much more efficient because:

GraphQL only returns the specific fields the client requests, making the payloads much smaller
The Gateway is able to gather all the data it needs via inter-service communication before responding to the client (eliminating the need for the followup requests)

Thanks to GraphQL Federation, we were able to have our cake and eat it too! The backend team was able to continue development with all the benefits that microservices provide, while our frontend and mobile teams become even more efficient with the flexibility of GraphQL.

We were extremely happy with the outcome of our migration to Federated GraphQL, and while microservices can be good with REST, they are better with GraphQL!

Architecting a Real-Time Scheduling Integration with DynamoDB

Shane Jarman — Thu, 30 Sep 2021 16:32:40 +0000

The Problem

At BetterHealthcare, we are focused on building the best digital front door in healthcare. To do that, we needed to develop an integrated scheduling product that accurately displayed provider availability in real-time.

Considerations & Thought Process

Our solution needed to be scalable, event-driven, and able to support multiple EMRs (each of which could have calendar data formatted in slightly different ways). The best way to brainstorm a solution to a big problem like this is to break it down into a few smaller problems.

In this case, we discussed the following questions:

What will the scheduling data look like? How will we initially process the scheduling data when we receive it?
Once data from a specific EMR has entered the system, how will we transform it into our standard availability model?
After the data is transformed into a standard format, how will we store it?

After answering all those questions and considering the results in all in the context of our broader platform and architecture, we came up with the following solution.

The BetterScheduling Solution

We decided that the best move was to leverage AWS's managed services to build our availability data flow using AWS Lambda, DynamoDB, and Kinesis streams.

Step 1 - Processing EMR Data Feeds

Each scheduling event that we receive contains just a single piece of the availability puzzle. It could be an appointment cancellation, an updated vacation day, or a change to the 'working hours' of a provider. Scheduling events can arrive in rapid bursts (e.g. when the integration is activated for a new customer) or one at a time as provider schedules update throughout the day.

Because the quantity of events we are receiving at any given time can be highly variable, we decided to publish each one to an AWS Kinesis Stream when it is received. The scheduling-event-stream then has an AWS Lambda Consumer that creates or updates the corresponding scheduling item in the scheduling-items DynamoDB Table.

The benefit of using the scheduling-event-stream is that if data feed from an EMR partner exceeds our write capacity, we can hold the data in the stream temporarily and retry processing the event! Alternatively, if our API failed the request, we would force our partners to "try again" and resend the data (which would not be as reliable and lead to a lot of errors).

Our Lambda, Kinesis, and Dynamo event intake architecture allows us to have the benefits of 'real-time' event processing without the risk of overloading the system when volume increases.

Step 2 - Transforming Scheduling Items

OK - so we now have a table full of scheduling items updated in real-time. Great! But these items are formatted differently for each EMR, and "scheduling items" are not "available slots". We still have more work to do to get to the "real-time availabilities" that we need.

We solved this data 'transformation' issue using DynamoDB Streams. Using pattern-matching, we are able match specific scheduling item updates to a corresponding "EMR Data Transform" Lambda. When a scheduling item is modified, the appropriate Lambda immediately calculates new, properly standardized availability for whichever providers and dates were impacted.

Our 'availability data' is now ready to be stored!

Step 3 - Store Standardized Available Spans

Now we have a day (or multiple days) of standardized available spans ready to be saved. But how should we store them?

We decided to save the final, standardized data in DynamoDB. There are pros and cons to using a 'wide-column' NoSQL datastore like Dynamo, but in our case the benefits clearly outweighed the costs.

Our access patterns were clearly defined, the Dynamo API works splendidly with AWS Lambda, and we would not need to manage any connections (in the case of a SQL solution). As we add additional EMR partners and integrated customers, Dynamo would allow us to scale our reads and writes horizontally while "paying as we go" to handle bursts of onboarding throughout the day.

So - our realtime availabilities are saved in our available-spans DynamoDB table, which our clients are able to query through our GraphQL API.

NOTE: In the final architecture diagram above, you'll notice that there is an additional Lambda connected to our available-spans DynamoDB table. That is the final piece of a slightly shorter 'pre-calculated availability' data flow. It is there to show an example of additional data flows that we support, but it is not required for the provided example to function.

Conclusion

We hope that you enjoyed this high-level overview of our scheduling infrastructure. We plan on posting more in-depth posts on each of the three steps above over the next couple weeks, so stay tuned!