API Evangelist Conversation with Stanislav Zmiev, Tech Lead of Platform Engineering at Monite

All right, I’m Kin Lane, API Evangelist. Welcome to another episode of API Evangelist Conversations, where I just chat with folks who are doing interesting things with APIs. Let’s dive right in and see who our guest is. All right, who are you?

So, right, my name is Stanislav Zmiev, I’m tech lead of platform engineering at Monite. I also love APIs, I love making them good, but not just the APIs. I also do open source, I do publications, podcasts, conferences, all sorts of things. Essentially, I just do technology and love talking about it.

Nice. Well, you caught my attention on LinkedIn because you’re doing some interesting things with versioning. So let’s start with why, for folks who are listening in, why is managing API change important? Let’s start with the fundamental.

Well, it’s not always important, I guess. So when you have a very small API that is used only by internal appliance, especially if they live in the same repository, they’ve got the same kind of deployment, then managing API changes is easy. You just change things at the same time, or you do them in three steps of, like, extending the API, then switching your client, and then removing what you added, very simple. But once your API becomes public, once your API starts being used by external clients, and especially once your company is built around your API, which is the case for some companies who call themselves API-first, that’s where we have the problem. Because every time we mismanage anything regarding our API, for example if we change it, if we add a breaking change, our clients are going to be broken, our clients are going to lose money. Same goes for, for example, when we’re not doing it accidentally, but we decided that we want to change something about it, a new feature, whatever, but the feature is a breaking change in the API, it requires new arguments, or we’re renaming something. Again, even if we tell our client beforehand, if they miss it, or if anything else happens, they’re going to be broken, they’re going to be losing money. And as a result, which is why we’re taking great care of making sure that our clients never break.

So important, and I appreciate you starting with, I think people come out of the gate thinking they’ve got to version everything, and they don’t really have a plan or strategy, and maybe they have one or two consumers, or maybe it’s an internal API like you said. And so versioning is a, it seems simple on the surface but it’s pretty complex. So what is API versioning, to help you manage this change?

Essentially, API versioning in its simplest form is saying, okay, this version of API has these endpoints with these schemas, whatever, and then we add like a path variable where we say V2 of the same path is going to have different response, whatever, different business logic, and we just say that this endpoint exists in this API, this other endpoint exists in that. So essentially it’s having two versions, two instances, of your API deployed at the same time. And there are like a billion ways to do this, but nobody tells which these ways are.

Yeah, versioning, I mean, there’s date-based, there’s semantic, but I think it’s something that confuses a lot of people, it’s always the top area of discussion. And I’m really keen on your approach, because you mentioned or alluded to you’re into open source, and so why did you build your versioning solution for your payments API as an open-source solution?

I guess calling Monite just the payments API is not enough, but Monite does everything regarding invoicing and documents. Essentially we are embedded invoicing, where we are a super app that does integrations with accounting providers, payment providers, all sorts of things. So we do a lot more than just payments. But yeah, the reason I built it is, as an API-first company that Monite is, we take care of breaking changes, and we have multiple clients that are using it, using different versions of it. And at some point we started trying out the basic solutions, you know, oh, let’s just copy this code from one version, paste it, and then see how it goes, the simplest approach. We were also thinking about, oh, should we use semantic versioning or date-based versioning, where should we put it, we decided to put it into the header instead, but instead we should have thought, well, how do you actually manage these? Because when you copy them, after five versions you have five times the code, and that is impossible to manage, that becomes really bad. I’ve heard of people doing 20 versions like this happily, this wasn’t us. For us it became so painful that at some point I decided to look at how other companies do it. That’s when I found what Stripe does, and essentially I spoke with Brandur Leach, one of the guys managing it at Stripe, before, we discussed how versioning could be done, and that’s where I got the idea for the framework that I built. It’s called Cadwyn. Essentially it does, like, your API developers support, and Stripe does a similar thing, I guess, your API developers support only the latest version of the API, and they describe every time they make a breaking change, every time they make a new version, they describe the difference between the previous version and this version. This allows us to essentially know how the versions have been changed, and as a result we have a tool that allows us to automatically convert every version into every other version. As a result our developers have to support only one version, but our clients are getting all of them at once. If our client wants a version from 2022, yes, 2023, yes, but I guess 2022 is not used anymore, so we’ve already discontinued it, but all of the versions that are active that are used by at least one can be freely used or upgraded, and oftentimes it allows us to even ship features to older versions, so you don’t even have to upgrade to get some of the new ones. And I guess this is the biggest thing about it, it’s cheap and easy to do.

Interesting. I did a podcast with Stripe, it wasn’t the same person who did the versioning, but they have a lot of concern, there’s a lot of anxiety around switching versions when you’re baked into invoicing, when you’re baked into payments and that is literally your money. There’s a lot of anxiety about this. So I could really see this helping kind of alleviate your concern on the producer side, as far as the amount of code but also from the anxiety, because, I mean, Ted did this five years ago, this integration, and no one wants to mess with it, and it’s great, new features, but we don’t want to touch it. So there’s high cost to doing APIs, and so what’s the cost of versioning, what’s the cost of someone investing into change management at this level, or other API providers who are looking to take Cadwyn and put it to work?

Well, the most expensive part of it, I guess, is building such a framework. It took me an incredible amount of time to get it just right. Thankfully Cadwyn has also a source of documentation, how to build such a framework, because nobody ever described it, so it’s probably going to be easier. But after you build it, you start running into unforeseen problems. You’re like, okay, we’re just changing our versions, but then all of a sudden you realize that in some versions, well, in some newer versions, the data is a little bit different, your data might have a different structure. And your developers, especially if they have never versioned, they’re running into this state of thinking that versioning data is, that now we’re versioning everything, not just the API. And that’s where you start getting into the problems of, oh, the client created this thing on version one, but then in version three they started trying to use it and there are some errors, and then the reverse also, they created it in version three but then started using version one, whatever, it’s crazy. And so my recommendation, any startup, any company that is thinking of doing versioning, be careful, it comes with a huge price, incredibly steep. And yes, it allows you to make like the perfect design, it allows you to change your design at any time without affecting your clients, it allows you to make it pretty, make it easy to evolve, but the initial investment of learning, of teaching your developers how to work with it, of managing these API chains, of building the framework, of managing all the versions, sometimes it’s a work of art, you know, to create a new version without breaking old stuff because the data might simply be incompatible. So my recommendation, think very carefully, and for smaller startups I would suggest to postpone it until they have more money, more developers, until they have shipped the actual product. Because my belief is that even if the product is not perfect at the API level, if it fulfills its purpose, if we can sell it, then we should sell it first, and only then should we, you know, make the API beautiful.

That’s such wise pragmatism, because, I mean, versioning and change in itself causes anxiety, but I see a lot of people hand-wringing and causing themselves anxiety even before they’ve shipped anything and trying to create the perfect solution. And so I want to dive more into Cadwyn and understand how it works and do some more storytelling around it outside of this to help you kind of think through it. But at the top of Cadwyn you say production-ready, community-driven, modern, Stripe-like API versioning in FastAPI. Do you consider Stripe to be like a standard that people should follow when it comes to versioning, and is Cadwyn kind of baking that, or how do you see it?

So Stripe is a big name that allows Cadwyn, me, to say, hey guys, you know what, these guys are doing it really well, well, we’re doing the same. This is essentially me just trying to explain who we were or who I was following when developing it. I think Stripe is at the top of the industry, somewhere at the top in terms of the API quality, in terms of the story they tell with their API, and most of the providers in terms of fintech in one way or another are inspired by Stripe. So if Stripe starts doing something tomorrow, I’m sure there will be 20 more, simply because they are a big name and their APIs are of a high quality. Should every company follow that? I don’t think so. I think that the companies should first consider what they need specifically for their product, and that includes, if you are sure that you have the money right now and that your business model is really fit for API-first, then yeah, go follow Stripe in their versioning, it’s good, and I failed to find any better approach. There are similar approaches, there are approaches that are really good for internal appliance, but for external clients I don’t think there is anything that beats it just yet, at least publicly.

Again, very pragmatic, thank you for that. Let’s zoom out from the API versioning, and just about you, what motivates you?

I guess it’s two things, mainly one. I really like the people around me, and when I was contributing to open source, it was always because of someone, it was always because I wanted to solve someone’s problems. Some of the time it’s me, but most of the time it’s my colleagues or the people in open source that I see complaining about stuff, and the feeling of bringing the solution to someone and solving their, maybe not just a business problem, but a tooling, a technological problem, where a developer just becomes a tiny bit happier working on your tooling, that’s the feeling that drives me, and that drove me throughout. And I guess that’s why I became a platform engineer in the first place, because your clients are so close to you, you’re always getting this feedback, whether it’s good or bad.

I like your style. I would say I’m going to do some more storytelling around Cadwyn and see what other people, what else I can stir up, and then maybe we can have you back, because versioning is a top discussion, but I would say more importantly your kind of pragmatic approach to managing change, and just, I think, is refreshing, and it’s why I do this podcast, because this feedback loop with folks like you, smart folks who know things better than I do, is why I do this podcast. And the great part of this format is I can have you back as many times as I need, and so let’s definitely talk more in the future, and I appreciate you coming by.

Thank you, thank you so much, thank you.

All right, well, that’s another one, very cool. Versioning is always an interesting subject to talk about. Look forward to diving into Cadwyn, look forward to learning more, and we’ll see what we can stir up in the future. Thanks, everyone.