Complex monolithic system refactor & GraphQL API development
In a market short in GraphQL expertise, Xolvio not only showed us exactly how to build our supergraph but also refactored our monolithic system in just three months.
Will Rigsbee, Senior VP of Engineering, StudyKIK
StudyKIK (a Syneos Health company) is a leading provider of clinical trial recruitment and retention technologies connecting patients, sites, and sponsors. However, their monolithic system architecture was increasingly hampering engineering productivity. StudyKIK turned to GraphQL with the aim of decoupling backend from frontend for greater user experience agility. Looking to support their GraphQL efforts, the company enlisted Xolvio, the official Apollo GraphQL professional services partner, to evaluate its GraphQL practice and to make recommendations for proper design and implementation of a federated Supergraph architecture. Following this assessment, Xolvio refactored StudyKIK’s monolith in three months and built a federated GraphQL API on top of it to supercharge innovation. As a result of the engagement, StudyKIK skyrocketed their ability to iterate on new features, consequently accelerating a new product launch by a full quarter.
As StudyKIK’s monolithic system grew in complexity over the years, it became increasingly difficult to maintain. A high degree of coupling, especially around some entities, meant that new feature development required careful attention to many different parts of the system. This became particularly problematic for evolving customer experience, which led to StudyKIK introducing GraphQL to their tech stack, with the aim of decoupling backend from frontend.
However, the monolithic system’s complexity made GraphQL schema design difficult and posed the risk of maintaining one giant GraphQL server. Consequently, a refactor of the monolith seemed inevitable. StudyKIK’s challenge was then threefold: to plan out a new, distributed, microservices architecture; to execute the refactor in a safe and controlled fashion; and to create a federated GraphQL schema to match the new architecture.
Our engagement with StudyKIK began with Apollo GraphQL consulting. Over a period of two weeks, our team interviewed key product and engineering stakeholders, conducted event storming workshops, and analyzed the gathered information to produce a set of targeted recommendations and a roadmap to follow. Trusting our expertise, StudyKIK then tasked us with refactoring their system and revamping their GraphQL journey by designing and implementing an Apollo supergraph.
This highly effective workshop technique allowed us to quickly model StudyKIK’s business domains from a high level by extracting tacit knowledge from the relevant stakeholders and making it visible on a virtual whiteboard. Then, we dug deeper to document the relevant business processes in more detail, before using the modeled processes for software design and development.
In Domain-Driven Design, a bounded context is defined as a boundary of language consistency. These domain boundaries emerged from the Event Storming workshops and allowed us to define the new, distributed architecture in terms of modules. Later, we applied this domain-driven approach to GraphQL schema design, as bounded contexts naturally map to subgraphs in a supergraph.
Armed with initial bounded contexts and a detailed understanding of StudyKIK’s business domains, we began the refactor in a stepwise fashion, creating a mixture of code repositories and microservices. In order to ensure great scalability, reliability and performance benefits, we applied an event-driven architecture with a message broker enabling decoupled communication between the different modules.
In parallel to the refactor, we laid the foundations for StudyKIK’s GraphQL API by designing and implementing a federated GraphQL schema. We focused on current data demands on the client side, so that the GraphQL API could provide the correspondent supply through the appropriate subgraphs of the supergraph. This demand-driven approach allowed us to quickly build a fully operational API, ready to be expanded as per StudyKIK’s roadmap.
When we started our engagement with StudyKIK, their engineering organization was wrestling with a highly complex monolithic system that hampered their ability to improve on customer experience. Three and a half months later, they could boast a brand new, refactored, event-driven, distributed system with a federated GraphQL API on top. Apart from these hard deliverables, we armed StudyKIK teams with knowledge, skills, and best practices to continue growing both their system and the API. As a result, StudyKIK was able to accelerate their roadmap and moved an upcoming product launch by a full quarter.
Witness the impact of visual requirements facilitation and our problem solving prowess in a 90 min. consulting session.
Request consultation