Pat Dunn's profile picture

VP, Engineering

Pat Dunn

I presented this topic at Boston Code Camp

. At that time we were beginning our journey of using GraphQL at EF Go Ahead Tours. In this post I'll go over what our early steps looked like and what the outcome was for our teams.

Many industries depend on legacy systems that businesses are unwilling or unable to invest in improving or replacing. The risk and cost of replacing those systems can be prohibitive, especially in the short term. Yet, the existence of these systems pose a risk to growth by reducing engineering velocity and stifling innovation.

There are many reasons your legacy systems may no longer be sustainable:

The impact of overwhelming legacy and the tech debt often associated with the systems can loom large over your team. It can have a negative impact on team culture as people feel they're working on outdated systems that lack an end goal or an opportunity to innovate. This lack of innovation can lead to the following:

In a risk reward assessment you'll often find that replacing these systems all at once incurs too much cost or poses too much risk. As a result, you'll need a plan to retire your legacy over time. The goals, methods, and processes of doing so is worth an separate blog post but at EF Go Ahead Tours we were looking to do the following:

And of course, we are looking to create new opportunities that drive value for customers.

Contracts between systems are important. These contracts all serve the purpose of making inter-system communication predictable and trackable. In our architecture today contracts get represented by one of three things:

With contracts, you can separate the implementation detail from the functionality of a given service. This is an important tool in building an anti corruption layer as your first step is often to redefine your domain. It also allows systems to be modular and capable of change while having a predictable impact radius on its dependents.

GraphQL allows you to take disparate data sets and represent them as a cohesive set of models with defined relations. Consider the following example:

You have a CMS that contains content related to your products:

And an inventory service that stores pricing and inventory data:

And a review service that stores review information:

What your clients need is a way to look at a common set of models from multiple different entry points. So your remodeled object in your GraphQL SDL layer could look like the following:

type Query {
    product(id: Int!): Product
    review(id: Int!): ProductReview
}
type Product {
    id: Int!
    name: String
    description: String
    images: [ProductImage!]
    tags: [String!]
    collections: [String!]
    inventory: Int!
    available: Int!
    price: ProductPrice!
    discounts: [ProductDiscounts!]
    avgRating: Int!
    reviews: [ProductReview!]
}

type ProductImage {
    url: String!
    alt: String
}

type ProductPrice {
    USD: Int!
    CAD: Int!
}

type ProductDiscount {
    code: String!
    amount: ProductPrice!
}

type ProductReview {
    id: Int!
    productId: Int!
    userId: Int!
    title: String
    description: String
    rating: Int!
    product: Product
}

Your clients create their own queries to the graph depending on their use case without having to care about where the data is originating:

They want to query a product and get all its reviews.

query FindProduct($id: Int) {
    product(id: $id) {
        id
        name
        avgRating
        reviews {
            title
            description
            rating
        }
    }
}

Or it's a review detail screen and they want to show some associated product information:

query FindReview($id: Int) {
    review(id: $id) {
        id
        rating
        title
        description
        product {
            name
            description
            avgRating
            images {
                url
                alt
            }
        }
    }
}

In either scenario, the client is able to fetch the data it needs because the SDL acts as a contract that the GraphQL layer promises to fulfill.

In GraphQL the schema is enforced by resolvers — a function that handles resolving the value of that field. Every field is, including queries and mutations, represented by a resolver. A resolvers signature consists of the following:

Resolvers allow you to fulfill the SDL requirements of a type from many many sources. For example, the legacy CMS, inventory, and review services we outlined above.

export const resolvers: Resolvers = {
    Query: {
        review(_, args, context) {
            return context.reviewLoader.load(args.id);
        },
        product(_, args, context) {
            return context.productLoader.load(args.id);
        },
    },
    Product: {
        reviews(product, _, context) {
            return context.reviewLoader.loadByProduct(product.id);
        },
        avgRating(product, _, context) {
            return context.reviewLoader.loadAvgByProduct(product.id);
        },
        async inventory(product, _, context) {
            const result = await context.inventoryLoader.loadByProduct(product.id);
            return result.inventory;
        },
        async available(product, _, context) {
            const result = await context.inventoryLoader.loadByProduct(product.id);
            return result.available;
        },
        async price(product, _, context) {
            const result = await context.inventoryLoader.loadByProduct(product.id);
            return result.price;
        },
        async discounts(product, _, context) {
            const result = await context.inventoryLoader.loadByProduct(product.id);
            return result.discounts;
        }
    },
    Reviews: {
        product(review, _, context) {
            return context.productLoader.load(review.productId);
        }
    }
}

In the example code above you can imagine the loaders are ways to fetch data from the backing systems. These calls could be over any number of protocols such as gRPC, HTTP, SOAP, etc. The idea is to have your model fulfilled from many backing services. Picture how easy it would be to add new functionality relevant to our product models. You would need a new field to the schema and a new resolver that calls to your new datasource.

Getting started can be intimidating. Rome wasn't built in a day and neither should your graph. This is an opportunity to rethink your domain and establish a ubiquitous language. Start there. Work with product, senior engineers, and stakeholders to start building a dictionary. Define what your domain should look like. Then take a piece of it, represent it in your graph, and build from there.

If your team has the tendency to build BFFEs or works in isolation you'll need to get buy-in and collaborate. You want to avoid the graph becoming another place where the same objects get defined in many ways.

At EF Go Ahead Tours we have a staff engineer who elected as a graph champion. Part of their job is to help teams understand how they can benefit from the new system. They also help run trainings, provided architectural guidance, and general oversight of the graph.

 is a great resource from Apollo to guide you on best practices.

At EF Go Ahead Tours we used this method and were able to achieve the following:

Since taking this initial approach, new technology such as Apollo Federation has emerged. This helped us continue to break apart our legacy systems over the last 3 years while innovating. In a follow up blog post, I will go over how we expanded this approach using a series of GraphQL microservices.

GraphQL adoption at EF continues to increase. In the current phase of our journey, we are working on ways to integrate many businesses through the graph. This has posed unique challenges around performance, domain modeling, and more. We'll be writing blog posts on these topics as we go. So stay tuned!

GraphQL logo on a pink background

Legacy systems can stifle innovation and become costly. Learn how to use GraphQL to create an anti corruption layer that keeps your teams innovating.

Pat Dunn

Using GraphQL as an anti-corruption layer in front of legacy services