Technology Insights

GraphQL: Escape from the Monolith

By Chris Reid / April 3, 2019

As SaaS codebases have grown larger, engineering teams have faced challenges building, testing, and deploying new features. One answer to this problem is breaking down a monolithic codebase into smaller services. Here, AppDirect Staff Software Developer Chris Reid discusses one approach to solving the monolith problem.

Making the Move to Microservices

In order to have more maintainable code, we made a choice to break up our codebase into smaller services, each with their own set of specific responsibilities. Each service should do one thing, and do it well.

The biggest issue when taking this approach was needing a way for each service to interact with the data in several different databases: MySQL, MongoDB, and Postgres, as well as a Redis cache. In the case of a monolith, there could be one common Object Relational Mapping (ORM) layer for each database. With microservices, however, that ORM would be needed in multiple services and languages. We concluded that we needed a different approach if we were going to maintain the current code, while delivering new features, and moving further towards microservices.

One of the main options we considered was to maintain a shared library used by each of the services. The core pitfall was the lack of ability to easily change the schemas of objects. Each change would need to be reflected in three different implementations for each of the languages we use. The other pitfall was blurring the lines on where our business logic would reside; some in the library, and some in services.

We needed a technology that would allow abstractions to exist between components while still maintaining future flexibility.

We concluded that in order to prevent adding new interim APIs to our existing codebase, we needed to use a technology that would allow abstractions to exist between components while still maintaining future flexibility.

Our Approach: GraphQL 

We choose GraphQL to solve this problem for a few key reasons, among them:

• It is language agnostic
• It allows strict type definitions
• We have server, web, and mobile http clients
• We have internal and external http clients
• We have data spread across multiple databases and multiple microservices

Using GraphQL we have a consistent way for internal (or external) services to access and manipulate data. Normally, to expose that kind of functionality, it would require implementing a new set of dedicated APIs.

In this case we have two ORMs to maintain, but we are no longer dependent on new code being added to a codebase that we want to deprecate. If we add new queries needed by new internal functionality, we can easily expose those same queries to external clients where appropriate.

With GraphQL, we've been able to take a major step toward evolving a monolithic codebase to work in the Kubernetes-enabled microservices environment that the rest of our technology portfolio runs on.

Chris Reid is a Software Developer at AppDirect.

Interested in exploring engineering careers at AppDirect? Visit our Careers website to learn more.

VIEW CAREER OPPORTUNITIES