For the next in our series of Scala eXchange speaker interviews, Skills Matter caught up with polyglot programmer and international speaker Brendan McAdams. Previously at Typesafe, Brendan now works at Netflix and will be using his talk at Scala to speak about the architecture Netflix is using for their next generation device metadata APIs. He told us about the beauty of simplicity in code, the importance when building software of keeping users at the forefront of your mind, and why walking and drinking local beer is the very best way to discover new cities.
Only 4 days left – Book your ticket now!
What makes REST API’s beautiful?
I’ve always been a big fan of elegance and simplicity in code. Having done a lot of messaging systems in the past, with everything from Fixed Field over TCP/IP to SOAP, XML/JSON-RPC, and more, I’ve burnt myself out on the complexity and insanity of these formats. Why do we, as developers, insist on building such inscrutable messes and then selling them as an improvement? With REST, you can choose whatever data interchange format you want, whether JSON, XML, or even the abomination that is IBM’s JSONx, while maintaining a consistently simple transport protocol. You can declare a set of common endpoints that any language can consume without big nasty client libraries–frontend & backend devs alike can get useful things done. Ultimately, REST’s transport protocol is just HTTP, which most modern developers understand intuitively. It ends up being mostly self-describing, and that is a beautiful thing. Simplicity in code has an elegance and beauty all of its own, and I absolutely love that.
What is it about the toolsets of Scala (Scalatra, Swagger, and Akka) that allow you to do this particularly well? What makes them different?
Swagger solves the problem of “how do I effectively document my UI in a way that stays up to date with my code and makes sense to API users?”. It is just a fantastic tool for doing this, as you describe your API with it as you write your server API. Ultimately, Swagger really helps with a belief I hold that Code is (or should be) communication. Scalatra makes things simple: minimal configuration and convention. With Scalatra, your code is generally your configuration and it integrates cleanly with Swagger to extend that to your API Docs. As for Akka, I could write an entire book on how wonderful it is as a product. Specifically with Scalatra though, I’ve found it incredibly powerful for handling background tasks that need to happen behind the scenes while the rest of a request completes. In particular, I’ve used it to defer long running invocations to external systems without blocking up the rest of a HTTP request thread.
What other architectural considerations do you need to make when building REST APIs?
Consistency is important: there aren’t 100% perfect, immutable standards for REST APIs but rather a general set of loose guidelines. As such, it ends up being really important to decide on what your standards are and communicate them effectively to your team, and get everyone to agree. Good, well disseminated internal standards prevent the inevitable hammering a square peg into a round hole syndrome. It is all well and good to decide you are going to use a particular set of HTTP response codes, but do the people using your API understand what it means when you do? Do you consistently communicate errors in a meaningful way? Finally, how do you document all of this? I’ve found that self documenting code – especially with a tool like Swagger – makes everyone involved happy because your code quickly reflects reality from a documentation standpoint.
You moved to Netflix earlier this year. What were you able to bring to your new job as a result of having worked at Typesafe previously?
Between my consulting and training work at Typesafe, and MongoDB before that, I gained a lot of perspective as a software engineer. I had previously spent most of my career in a cubicle with my head down, coding. I hadn’t spoken at conferences or even attended many. When I started speaking at the NY Scala User’s Group, my life and career took a pretty big left turn into that world. Speaking publicly, and especially consulting, changed my point of view heavily in my career. I now think much more strongly in terms of who my users are – and the idea that your customers/users might be people inside of your own company. Customer interaction has become much more important to my viewpoint, as a result. At the end of the day, if you aren’t building software with your users in mind you are wasting everyone’s time and a lot of their money. So I’ve found that while working at Netflix I spend a lot more time making sure that my code communicates more effectively with its users. Clear error messages, consistent behavior, and sanity are much bigger parts of what I do in my code than they were prior to my Typesafe and MongoDB days.
Since working at Netflix, have you made any exciting discoveries outside of the SCALA ecosystem?
There are a wealth of tools that Netflix has both internally and as part of the Netflix Open Source projects which have really opened my eyes to better ways of doing things. RxJava, in particular, the focus on immutable deployments makes it much more likely that I can reproduce a server issue because nobody has changed things out from under me.
We do a lot at Netflix with stability and fault tolerance, to the point of having a “Simian Army” whose job it is to create trouble and chaos within deployed systems to ensure what we build is capable of resilience in the face of adversity. There are also very interesting things coming out from the Open Source world in general around these kinds of flexible infrastructure concepts such as Docker, which intrigue me. I simply wish I had more time to play with them! Within the Scala ecosystem, I’ve recently started playing with Scalaz which is a haskell-inspired functional programming library to extend and complete Scala’s stock toolkit. It has turned out to be a fascinating and powerful tool for improving my code.
You’re a very prolific public speaker! What do you love most about speaking at conferences, whether at home or internationally?
I love getting a chance to show people what I’m thinking and what I’m excited about at a given time – and forcing them to sit down for an hour or two and listen to me ramble about it! It is a fantastic opportunity to show off cool things that people might not have known about before, and it is a very rewarding feeling. As for the fringe benefits of being a speaker, I think I’ve always found the “hallway track” – the part of the conference between talks where you get to talk to people – the best part. There’s always amazing perspectives that I wouldn’t find anywhere else, and I learn so much about what is going on in the industry. I’ve made a lot of lasting friendships over drinks and conversation at these events that I wouldn’t trade for anything. Finally, I’ve always loved walking around new cities and trying the local beers. There’s no better way to learn about a new place than a comfortable pair of shoes and a healthy liver. Since I started at MongoDB in 2010 I’ve worn out the soles of at least two pairs of Doc Martens walking around half of Europe!
While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.
Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.