Lightning Talks: Day 2

EuRuKo 2016

00:00:04.899 Welcome back to the lightning talks! We'll have seven lightning talks today. We were unable to fit one in yesterday, so we're going to hold it tonight. Each talk will last five minutes, and at the end, you will hear the awesome gong played by the incredible Gennady, followed by applause. Our first lightning talk will be given by Chris and Levena, also known as Chrissy, who will discuss HTTP and cake requests: keeping clients happy, not hungry.

00:00:51.450 Hi everyone! I'm Chris Alda, a software engineer at Deliveroo, which is sponsoring this event. I’m very proud to be here. Thank you very much, Hirako! Besides my work at Deliveroo, I'm a board member and volunteer with two organizations: Women Hack for Nonprofit and Empower Hack, the latter of which focuses on building tech solutions for refugees. Both are open-source organizations. You can read more about them and follow me on Twitter @ChristyGoAround if you're interested.

00:01:29.360 I've been working at Deliveroo for about three months now, and in that time, I've already undertaken a lot of different projects. Each day is unique, which I really appreciate! My focus has been on APIs, specifically for the restaurant apps we use for order management. We're moving away from a Rails monolith to a service-based architecture and are building our own internal event bus.

00:02:00.089 The talk about Kafka yesterday was both timely and insightful; I have much to relay to the team when I return to London. By the way, working in the on-demand food industry means I find myself eating a lot, making it necessary to eventually get a gym membership.

00:02:06.560 Today, I'm going to discuss API design and food, specifically brunch. To clarify, I'm referring to the meal between breakfast and lunch, not Brunch.io, the HTML5 build tool. I've created a makeshift graphic that would likely bewilder our designers if they saw it. Let me set the scene by sharing my last brunch experience in London.

00:02:32.659 Picture this: it was a sunny day in London—one of just five we get a year—and we were in high spirits, craving eggs and bacon on sourdough toast at a fancy café. I went with a couple of friends and their baby, and we had a big pram with us. Unfortunately, the restaurant manager wasn’t in a particularly good mood. He first informed us there was no room to sit, despite there being an obvious table available. When we offered to move the pram, he simply reiterated there was no room, walked away, and left us very confused.

00:04:00.109 Needless to say, we decided to go to the café next door, where we had a great brunch. The issue wasn’t just about the lack of seating; it was that we never understood what the real problem was. It felt like a generic internal server error—confusing and frustrating—leading us to vow never to use that service again.

00:04:34.620 This brings me to the subject of API design: elusive errors are not helpful. A better brunch experience would involve thoughtful error response design. HTTP comes with its own status codes to indicate not just success or failure, but also explain why something went wrong. Following this principle could vastly improve client experiences.

00:05:03.790 When reflecting on brunches I have truly enjoyed, it wasn’t merely the food that made them special. It was the personalized attention we received that made us feel valued as customers. This reminds me of implementing HTTP caching in APIs. Imagine visiting a restaurant for the first time and asking for their menu. After placing my order for delicious potato pancakes, I return later and ask the waiter if they still offer them. I would expect a thoughtful response about their menu's status rather than being handed the same menu again.

00:05:39.970 In a better dining scenario, the service would provide relevant caching information in the form of additional headers in the HTTP response, such as cache control and last modified. The server wouldn't reload data unnecessarily and would foster a sense of comfort in the customer, empowering them to make conditional requests. In Rails, API design can be simplified to address HTTP caching efficiently, typically needing only a few lines of code to enable this process.

00:06:59.610 To summarize, here are three takeaways: First, from Bill Gates: your most unhappy customers are your greatest source of learning. Second, create a service that you would enjoy using yourself. Lastly, prioritize your documentation, error responses, and other seemingly minor details that significantly impact the customer experience. Ultimately, we want to ensure our clients are happy and not hungry. Thank you!

00:07:22.879 Thank you, Chrissy! Up next, we have Stefan Daschek presenting "Decoding AF-S Key Data from Commodore 64 Edition."