Session

API Optimization Tale: Monitor, Fix and Deploy (on Friday)

I saw a green build on a Friday afternoon. I knew should push it to production before the weekend. My gut told me it was a trap. It wasn't a mere superstition about deploys, Fridays, and kittens. I had already stayed late to revert a broken deploy. I knew the risk.

We were extracting a service from a monolithic Rails platform. The initial REST-based internal API crashed even with a fraction of the traffic. We decided to replace it with GraphQL and optimize API usage. This radical change happened in a series of safe, incremental steps. Along the way, we noticed patterns of a performant, robust, and predictable GraphQL API consumer.

Why was it crucial to deploy so late? What gave me the confidence to deploy on Friday? How did we measure the effects of the optimization? And finally, why did I even think of testing on production? To answer, I'll tell you a tale of incremental changes, monitoring, and good old patterns in a new setting. Hope, despair, and broken production included ;-).

Maciej Rząsa

Senior Software Engineer at Chattermill

Rzeszów, Poland

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top