Elevator Pitch
Moving to a new GraphQL implementation can be a challenging task. How do you ensure everything is working as intended, when changing the entire schema? By applying the Strangler pattern, schema stitching and moving everything in small steps, your implementation is in safe hands.
Description
TV 2 Denmark is the largest, Danish television broadcaster and has the most popular, subscription-based streaming service in Denmark. We use GraphQL as a an API gateway for our different platforms, connecting our customers with all our microservices through a singular API.
During the last year, we’ve seen growing pains with our 3 year old GraphQL gateway, due to changes in requirements over time, as well as GraphQL maturing quite a bit since we developed the initial version of our gateway. So, we recently decided to move our entire gateway to a new, modern and shiny implementation.
In this talk I’ll walk you through some of our tactics we applied, when moving from one implementation of GraphQL to another, while keeping everything running in production as well as not modifying the schema composition.
Notes
I’ve been working as a software engineer for the last 15+ years, having worked on some of the largest services in Denmark. I spent the major part of the last 2 years running point on the reliability and scalability challenges within the largest, Danish streaming service, TV 2 PLAY. The efforts have been focused on chaos engineering, optimizing internal communication between services and hunting for milliseconds in our responses.
In November, I gave a talk on dependency handling and handling faulty services behind a GraphQL gateway, at GraphQL Summit, called Destined to Fail.
I have been considering for quite some time whether the subject might fit best inside a short or long time slot at a conference - Initially my thoughts are to keep it smaller and faster, but if the subject seems interesting, I might be interested in doing a longer version instead.