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.
Related Articles

Technology Insights
Evolution of the AppDirect Kubernetes Network Infrastructure
At AppDirect, we embraced Kubernetes—an open-source system for automating deployment, scaling, and management of containerized applications&mdas...By Alexandre Gervais / AppDirect / June 7, 2018

Technology Insights
Introduction to the Workflow Microservice
At the beginning of this year, the Engineering team at AppDirect rolled out the first deployment of the Workflow Service (WFS) in production for a lar...By Pascal Chouinard / AppDirect / April 4, 2018

Technology Insights
10 Ways AppDirect.AI Enhances Advisor Efficiency
Unlock advisor efficiency with AppDirect.AI: Elevate collaboration, tap into specialized capabilities, and craft custom AI bots. Explore the AppDirect AI Marketplace and discover how to create AI that learns from your own data sets.By Ideas @ AppDirect / AppDirect / November 22, 2023