Last week I gave a talk at the 2014 Scala eXchange in London, entitled "Effective API design with Scala types". The talk involves some practical examples of how choosing appropriate types can greatly improve the design of your API, making it both much easier to build and much easier to use. I promised I would upload some more details about the code so here it is along with some more background, links to the talk and some supporting resources.
Skills Matter recorded the talk so if you missed it you can watch it on their website. Thanks to everyone who came to see it live. I had a great audience! It's always nice to have a full room of people who are paying close attention and we had some excellent questions at the end as well.
Link to the video of the talk (you'll need to register with Skills Matter to view it).
I use reveal.js for my presentations so the slides are available on this website.
I've pulled the code samples I showed in this talk out into a separate project and put them on GitHub. While I've made sure everything is correct and compiles, bear in mind this is only one way to approach the problem. The general principle is more important then the actual code I wrote, but hopefully these examples will help. There is more information about the source in the project's README.
About the talk
Firstly, the abstract:
The type system is a fundamental tool for programming in Scala, but while we're used to thinking about functions and methods within an application it's rare for us to consider the types outside our programs.
This talk will demonstrate how choosing a consistent and appropriate type to represent our API's responses can dramatically simplify its internal design and implementation.
The content of this talk is something I've been thinking about for a couple of years now. The kernel of the idea began while working on the backend to the Guardian's Identity system, which handles the user accounts and personalisation. When you're working on large APIs it very quickly becomes apparent that the same basic principles are applied over and over - you have an endpoint that performs a series of steps, any of which might fail. The standard library's
Either type seemed like a good fit for this and everything else followed from there.
I hope you enjoy it!
Scala eXchange 2014
Lastly, I'd like to say a few words about this year's conference! I've been to a couple of Scala eXchanges now as well as quite a few other conferences (including the functional programming eXchange). I have to say, this may the best conference I've been to. The talks were of a uniformly high standard, great diversity of content as well real depth in a few fields. One thing that was particularly interesting was that there was so much focus on more advanced type-theory, especially libraries like scalaz. No doubt this is in part due to typelevel's great work, but I think it also speaks of a shift in the programming landscape. Scala, (despite being a language that offers great support for functional programming) has felt a little held back by its Java origins, if only because so much of the community has been coming from the OO imperative world. Many Scala developers have now had a few years to adjust and I think Scala's future looks more interesting than ever.
It was a great honour to a be part of the conference, enormous thanks to Skills Matter and all the sponsors and speakers for making it happen.