Lightning Talks: Day 2

by Kriselda Rabino, Stefan Daschek, Thomas Leitner, Victor Shepelev, Anton Dimitrov, Igor Omokov, and Alex Jahraus

Summary of Lightning Talks: Day 2

The video features a series of lightning talks presented at the EuRuKo 2016 event, showcasing various topics delivered by different speakers. Each talk is designed to encapsulate key ideas within a tight five-minute timeframe. The first talk mentioned is by Chris Alda, focusing on API design and its parallels to the brunch experience, emphasizing the importance of clarity in client communications.

Key Points Discussed:

Introduction of Speakers and Format: Victor Shepelev, Thomas Leitner, Kriselda Rabino, Stefan Daschek, Anton Dimitrov, Igor Omokov, and Alex Jahraus are the speakers who participated in the lightning talks session, with Chris Alda kicking off the series.
API Design and Client Experience: Chris relates his experiences working in the food delivery industry at Deliveroo to the principles of API design. He draws an analogy between dining experiences and how APIs handle errors and data responses.
Importance of Error Handling: He highlights that elusive or ambiguous error responses are detrimental, using the example of a frustrating brunch experience where communication failed. Clear error messages in APIs can improve user experience significantly.
HTTP Status Codes and Caching: Chris discusses the use of HTTP status codes to inform clients about the nature of any API failures. He expresses the need for better implementations of caching in APIs to enhance efficiency and user comfort based on their prior interactions.
Personalized Customer Service: The essence of providing personalized attention in dining reflects on the need for services (including APIs) to cater to user needs and expectations, which could lead to improved satisfaction.

Significant Examples:

Brunch Experience: Chris shared a vivid anecdote about a brunch outing in London that exemplifies poor customer experience due to inadequate management and communication, leading to a vow never to return to a specific service.
Real-World Application: He compares the handling of menu requests at a restaurant to how APIs should handle caching and responses, reinforcing that thoughtful responses can foster a better client relationship.

Main Takeaways:

Emphasize the importance of learning from customer dissatisfaction.
Build services that prioritize user enjoyment and smooth interactions.
Pay attention to documentation, error responses, and other details that impact user experience.
The ultimate goal of any service, including APIs, should be to ensure that users are satisfied and have their needs addressed effectively.

In conclusion, the talk emphasizes the parallels between dining experiences and API design, offering insightful lessons for enhancing user satisfaction through effective communication and thoughtful design principles.

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."