Jakub Nesetril, CEO of Apiary on Web APIs and Developer Experience

1. Good morning, Jakub, glad to have you here at InfoQ, can you introduce yourself?

Yes, absolutely. Good morning Jeevak, thank you for having me. So, my name is Jakub Nesetril, I am the founder and CEO of Apiary, which is a company that is building API tools for API providers and prior to founding Apiary I was team leader and director of engineering at GoodData. I think it’s typical that I was a team leader for a long time as a backend architect and I was a team leader for a long time as a frontend architect and I think that relationship between backend and frontend is what powers my passion around APIs and you’ll find that with a lot of people that are passionate about APIs that they were on both sides of the API divide. So for the last two years I’ve been building API development tools in Apiary and we’ve been blown away by how many people are actually excited about it, we’ve grown in the last twelve months from being a company that nobody has heard of to being the largest API provider company in the world. We’ve got about 35,000 APIs developed in Apiary, so that’s really more than anybody else has to offer and I think one of the strong reasons for that is we’re very developer focused, we’re very focused at enabling developers to develop APIs easily, so we’re very excited about that.

2. You keep mentioning developer focus and in the API world one big thing is developer experience, so what is really developer experience and what is good developer experience?

I think developer experience is user experience where the user happens to be a developer. It’s as simple as that. And I think over the last ten years developer experience or user experience in general has come to be recognized as much more important than previously, even if you think of recently the iPhone and smartphone introduction which has really revolutionized the world just based on usability or if you think about the fact how mobile applications, data mobile applications are winning over web applications these days where it’s really only a about couple of microseconds of usability and responsiveness in the approach of the application, I think all those things are making people realize that user experience and developer experience is extremely important. So, in the context of APIs developer experience is probably the number one driver that decides the success of your API and it’s really about how developers feel when they’re using your API, how easy you make it for them and what’s the overall experience with your API product.

3. Now we know that REST is here, you did mention you were a backend architect, so you obviously dealt with SOA and previous generations of these architectures. So in the absence of DX in the current SOA world, what are some lessons that we can learn from SOA and what we should avoid in the API world?

Well, I think it’s still good to frame that question as a DX question, one of the reasons why RESTful architectures got so massively more popular over the last decade was exactly that undercurrent of DX and UX coming into play. So, probably the number one thing why RESTful architectures got more popular is because they are just simpler. They are certainly much less sophisticated, there is certainly much less tooling around them and so the whole platform grew out from the hacker community that just embraces the do-it-yourself approach. But now I think the general programming community has matured into major API deployments, we’re coming back to look at how we can introduce more tooling and how can we introduce more support and how can we introduce more structure into the new world of simpler API development. So for me, we’re thinking a lot about how the decade of SOA influences the decade of APIs and what we should learn from that. And one of the biggest transitions for me was transitioning to simple architectures, to what we call human-readable and human-writable. SOA was a lot about trying to engineer a protocol that was machine-readable and machine- writable. So it was easier to automate the whole process and it was easier to pretend there was no API or to try to automate everything together. And REST is really about acknowledging that there is an API out there and that API needs to be designed well, so that the developer on the other side that is using the API has a good developer experience. But we are still trying to come back with more tooling and better support on automating the process without sacrificing the simplicity or the human-readability and human-writability.

4. You are talking from the perspective of an API provider. But how can an API provider think about developer experience and marry it with their current software development life cycle?

One of the ways to think about developer experience is it’s a form of empathy, and as a result of that thinking about customer use cases and trying to understand customer use cases as good as possible is the strongest way how to drive developer experience inside the company. That’s very hard, it’s nearly impossible to teach somebody empathy, so the next best thing you can do is you can engage them very heavily in your engineering process and in your life cycle process. And that’s where we’re coming out towards more Agile methodology and probably why they have much more success rate than the waterfall approach is because they involve the customer very closely and very upfront. It doesn’t really matter which Agile method you choose, if you prefer Scrum or Kanban or something else, but I think involving the customer very closely from early on is super important in order to get good developer experience.

The next thing I would say is developer experience isn’t a life cycle on its own, it’s just a part of your existing life cycle at every step of the way, so you should look at ways how you can get early adopters from your customers involved as early on in your process and your life cycle as possible, and that even means way before you’re actually developing API, even in the design stage, even in the requirements gathering stage, and then keep repeating that over and over. And there are some tools at Apiary that we do that help with that, but there are other providers that are certainly working in the same direction.

5. You did mention about involving the customer early on, like in the SOA world you had something similar which was contract-first development and that was one of the issues with API developers, the strict adherence to contracts within the SOA world. So how does this contrast in the API world?

I think there is still room for involving the customer and involving the consumer without strict adherence to contracts. So, contracts as we view them are a way to help people structure their discussion around an API and around use cases and perhaps help people drive some of the automation into space so that companies aren’t developing tools and software over and over again when actually the APIs aren’t all that different one from another, so how to drive more tooling infrastructure into the API space. But, the SOA world was really, as I said, focused on automation and machine-readable and machine-writable connectivity. And so that is one of the core differences that the strict adherence isn’t as strict anymore and it’s a got a lot more room for flexibility and once you turn in this direction then, one of the reasons why strict contract adherence wasn’t popular in the SOA world was just the amount of complexity it brings to the table and that’s something that’s changed dramatically over the last ten years. The contract first development that we’re proposing is super simple.

6. We’re hearing about these undercurrents within the developer community especially the web developers around noBackend, the whole noBackend philosophy; so how does that contrast and how does that differ from contract first development approach?

I think I said at a conference a couple of days ago that if you are a backend developer don’t worry, noBackend is not out there to make you lose your job, it’s not trying to kill the backend as a profession. NoBackend is really more philosophical rebouncing of the relationship between a frontend and a backend developer. Traditionally, APIs are probably one of the last outposts of waterfall life cycle development by really being a holdout of design everything first, then implement everything, then turn it over to the customer for a first validation feedback. And we all know how badly that crashes every time it’s employed in the software engineering industry, but it’s very hard to involve the customer in an upfront design session if you don’t have an API ready that you can show them. That’s where the contract first development is really popular.

I think noBackend as a philosophy round it is let’s try to empower a frontend developer as much as we can because they are the ones that are closest to the customer, they are the ones that are closest to the customer use cases, they are actually the last mile of producing software, so they are the best way for discovering what the use cases and problems are. Because ultimately we all know that no matter how much upfront analysis you do, there are always unchecked corners that are only going to be discovered when you actually implement the software. And so the noBackend approach is more a manifestation of an Agile approach where we say let’s try to get the use cases as finished as possible upfront, discover all the problems through that and then let that influence the remaining architecture, specifically in the API space it would probably mean let’s try to bring as much of the functionality in a prototype stage all the way into the UI and into the customer, use that to discover use cases, discover the requirements and then let that drive the API design and only later in the life cycle develop the API itself.

7. You do talk about this iterative approach, so what are your thoughts on versioning APIs?

Versioning APIs is always a hard problem, but I think it’s better if you reposition it as a communication problem between you and your customer. Versioning APIs is really about letting people know there is something new and fundamentally it’s a way to let them know there’s a change that’s backward breaking. If you’re creating an addition to your API, if you are improving the API, or extending it or expanding it I would definitely caution against versioning, it’s much simpler if you just keep adding things and I think in the RESTful design approach additional content or additional features in your API shouldn’t break any existing applications. Now, if you are making changes that are backward breaking then you need to somehow communicate this to your customers and you need to let them decide what they want to do, use the old version or use the new version, or let them know if you’re even supporting that.

One of the ways you can do that is you can version an API through HTTP header, you can version through URLs, you can version through host names, you can version it through content types, you can version it many different ways, but ultimately it’s really, the way you look at it, just letting your API consumer know that there are backward breaking changes and letting them decide which version they want to use and letting them inform you what API call they are making. If you look at it this way it’s less of an architectural problem and more of a customer communication problem that influences the DX that we talked about and the overall developer experience very heavily. But then on the implementation side things are much simpler. Contract obviously should be versioned, they should be versioned inside your code repository, contracts should live side by side with your code so every time you branch your code, every time you merge your code, every time you introduce a new version, contracts should live with it. And one of the ways this can play out very beautifully in the consumer-first, consumer-lead design approach is that you can have a contract that starts out as a proposal, gets picked up by the frontend developer and while they are building their frontend application against a mockup that’s generated out of the contract, they can actually start making changes to that API to very rapidly discover all the use cases and problems that they are having while creating the application. So instead of asking a backend developer to go ahead and make some changes that may take a couple of weeks, they can actually make the change immediately in place and keep developing.

What that means is you can have a contract that starts diverging in two different paths and a backend developer can begin working at one version of the contract, the frontend developer can be working against another version of the contract and then through all the existing software development approaches of doing diffs between branches, doing code reviews, discussing around code, they can start converging back against one common version that is actually going to be implemented by the backend and the frontend developer. And that’s really powerful in unlocking the two teams and allowing them to work in parallel as opposed to working in series, as opposed to one team having to wait for the other. So, if you approach that API development through contracts and versions of those contracts then you can apply all the methodology of branching and merging and all the collaboration practices that developers have built up over the last 20 years and then you end up with an API that’s developed much more quickly. So, there are two parts to it, one is how to version the contract internally while developing software and the other one is how to version it publicly, and I think they are vastly different.

8. What would be one final message you would like to give our enterprise API developers at InfoQ?

RESTful architectures are not scary and they are they are nowhere near as cottage industry and as undeveloped as they were two or three years ago. That landscape is changing massively, so if you are worry about REST being a domain of crazy hackers that build everything in-house, that’s changing a lot and our company and a lot of other companies around have been working very hard to introduce best practices into that industry and introduce tooling into that industry and a lot of what we do is open source, we do have some plans for software-as-a-service, but I think if you look forward into the next few years, I’m having a good feeling that we are starting to find a path that’s a merger of the rich software tooling that we had in the SOA world and the simplicity of REST that’s been brought by the bottom-up approach. So, I am really looking forward to that and I would encourage people to seek out the solutions.

Jeevak: Thanks, Jakub, thanks for speaking with us today.

You’re welcome. Thanks for having me.