How to avoid API troubles with Vedran Cindrić of Treblle

Victor [00:15]: Hey, everybody, welcome to the show. Today’s guest is Vedran Cindri founder of Treblle. If you ever wanted to integrate with another software where you had to use an existing integration, or you are building various front ends, like web front end or mobile apps, or if you’re using microservices, you definitely had to deal with APIs. This episode is for founders and product managers with basic or no technical background. It dives into APIs, how they work, what their challenges are and how your developers can be supported, building them. Vedran welcome to show.

Vedran [00:46]: Hi Victor. Thank you for having me and hello to everyone joining in the podcast.

Victor [00:52]: Awesome. Yeah, my pleasure. Why don’t you tell people a little bit about yourself and of course you’re business Treblle.

Vedran [00:59]: I’ve been a full stack developer for the past 10 years. I’ve kind of started developing early on. Really like it, really adore it. And together with my current co-founder, we used to run a web development company here from Zara Croatia. We worked with clients all around the world and kind of in the middle of that got. Out of our own need and necessity, I would say, we got the idea for Treblle. It really started helping us and we kind of turned it into a product and managed to actually raise an investment for that. So in an essence, some of our fancy marketing terms are Treblle, helps you stay in tune with your API, but at the end of the day, we make it super, super easy to understand what’s going on with your APIs and the apps that use them. So that’s in a nutshell, what Treblle is.

Victor [01:50]: That is of course relevant to our current topic. So this is awesome. I want to dive into how you started this business a bit on this side before you dive into this topic as well. So you already mentioned you were running a software house, building software for clients, plastic model from a very beautiful location, got to admit right close to the sea. One of my favorite holiday destinations. So I’m definitely going to drop by one day.

Vedran [02:15]: I have a beer with your name on it here in the office.

Victor [02:19]: Awesome. So you are essentially building software for clients and you are a software house collaborating with a lot of stakeholders. I guess, the client obviously, and who else?

Vedran [02:31]: So basically when you do development for 10 years, you kind of tend to work in all the imaginable situations. So of course the cleanest cut would be to, let’s say you are the one who’s developing everything from the platform. API’s, mobile apps, any kind of front end or backend that you might be using. But in a lot of cases, you work alongside with a team of people because a client wants to use a different skill than you have, et cetera, et cetera. So we often find ourselves mostly actually interacting with people who refuse to do native apps.

[03:09] So my thing personally is, I’m a strong believer in native swift and Android apps. I build them with Java, build them with swift. Respect, the ecosystem, et cetera, etc. So our clients kind of liked how we worked, but not that part. So they always show us essentially in a lot of cases build platforms. So they would come to us with an idea. Here’s what we want to build. Here’s what we want to have in the end, we would kind of build it all out. We would design everything from the database down to the actual apps, but somebody else would tend to do mobile apps in, I don’t know, flutter and react, native or whatnot.

[03:49] And when you’re interacting with these various people, it was mostly, we are in Croatia, somebody else is in New York. Somebody might be in India, somebody might be somewhere like Sydney, Australia. It gets pretty crazy when you work all around the world.

Victor [04:06]: If you care about your sleep schedule.

Vedran [04:11]: And if you want to have a life happy, fiancé or something like that.

Victor [04:15]: So such a luxury.

Vedran [04:16]: So basically it gets really complicated really fast, especially if the other team members are, I would say, let’s say, lacking in knowledge. So if they are maybe less versatile in what you’re trying to do and what they’re building, there might be problems. So we would often actually find ourselves in a situation where let’s say, we would make an API today and we would send the documentation for integration to the guys in the US. They would start, I don’t know, 6:00 PM our time, they would hit a roadblock or at least they would think they hit a roadblock because they weren’t sure what they were doing. And basically they would wait for us to answer a question for like 8 hours. And of course everybody, or even12 hours in some cases 24 hours.

[05:04] And of course, if you have clients that are very angry and they don’t know who to direct the anger at, either you or them or both of you. So we kind of started actually thinking in that direction, how can we help those guys answer their own questions? If they see what they’re doing, they don’t have to wait for us or me to tell them, hey, you sent something incorrectly or you didn’t even request it or you’re using a wrong URL or your variable isn’t sent as you think. So that was the basic idea. Let’s try to basically democratize APIs.

[05:40] Allow everybody who’s working with the API that we’ve built to see that. Everybody from mobile developers, the CEO, his product team, anybody. And that’s how we essentially started. And because we couldn’t get the product to scale at the beginning, I would turn it on while I was awake and turn it off before I would go to sleep so it doesn’t crash the API. So until we figured that out, people would use it in that period. And as soon as we kind of deployed it, I reclaimed probably like two hours a day of my time, just answering questions that I mentioned before. So it instantly helped us, Dale, everybody liked it, and we continued to build more and more features.

Victor [06:25]: I do love your marketing line though, democratize APIs. I’m sure that this is what convinced investors on the pitch deck.

Vedran [06:33]: So I actually use the term right now. We didn’t use it anywhere else. It just came to me because it truly is. One thing that I did and I talk about is the fact that APIs were for so long in the shadows, I would say, and nobody actually knew what an API request looks like. And now with Treblle they can actually feel something, see something, see what anybody, everybody else is doing and can actually understand. Oh yeah, okay this guy just created an account. Here is a reflection of that. Here is actually what happened. You wouldn’t believe how much clearer everybody is on what actually. Who does, what. What they’re sending, what they’re receiving, how things are working?

Victor [07:19]: We’re going to dive a bit deeper into how Treblle does that exactly. And what it does exactly a bit later. But first I really wanted to speak about APIs in general. Now, obviously there’s this one, I would say bigger divide on APIs, which is they are used case, right? There’s two of them, there is internal versus external APIs. Would you explain to our audience a bit what the difference here is and how they’re used?

Vedran [07:47]: Let’s start with a definition of an API. An API is just a short term for application programming interface. And in an essence, what an API is, it simply serves as a mechanism to transfer information back and forth between a client and the end goal, which is a database. The world got a bit complicated over the last few years and a client nowadays can mean anything, right? It used to be a mobile app. Now it’s a website, it’s a gaming console. It’s your car, it’s your smart light bulb. All of these things actually communicate to different internal in most cases, internal APIs. So for example, if you have a banking app, they use their own internal API, which in most cases, isn’t exposed to anybody else, except the people who built the app, the bank and their developers.

[08:38] On the other hand, you have this new, I would say trend of actually building companies on top of APIs. And that’s where external APIs come in handy. So essentially you’re building, let’s say again, a new kind of bank, and you want everybody to be able to write clients for your bank. So basically you Victor could write an Android app using that client, using that API. I can write an iOS, somebody can write something else. So essentially the idea is the same. It’s just the use case is a bit different. And I think more and more people are actually starting to expose their APIs to of the world and are building actually these open external

Victor [09:19]: Yeah, very true. I think most people really only think about external APIs when they think of APIs and to give an example, you mentioned banking, right? So PayPal, everybody knows PayPal. So their own mobile app would be using an internal API. Nobody can replace this mobile app, by their own client. But if you write an integration with them. Integrate them in your store or something like that, then use their external API. And I guess kind of the point here is, obviously there’s badly documented external APIs as well, but let’s face it. Let’s be honest. The documentation just isn’t so good is usually within the internal APIs because nobody’s using them apart from ourselves and suddenly somebody else has to use them.

Vedran [10:04]: That’s 100% true. I’ve probably in the past four months I’ve used probably like 20 APIs and there’s always a surprise. You can always expect something different and that’s just the name of the game. Developers are not necessarily meant to be great I would say writers and poets, if you will, and somebody who can do a structure and write that efficiently. But I think at the end of the day, and that’s why we kind of started building a feature of Treblle, that essentially generates documentation automatically. And if you’re a developer, you’ll never have to write it again. And the reason we started doing that, of course, because I personally hated writing docs just like every other developer. But secondly, and more importantly, the way that APIs are used and developed nowadays is much different than what it was before.

[10:54] So previously you would build an API, either internal or external, you would launch it into the world on the internet and you wouldn’t touch it for at least like six months a year. And then you would pile up in those six months a few features, you would roll out those features and that’s it. Nowadays basically we make, I made four changes to my API yesterday. Today I’m going to make a few more and that’s just the name of the game, essentially. You’re rapidly changing and developing these APIs. And I think the traditional way of documenting simply doesn’t make sense anymore. It’s less useful.

Victor [11:31]: Yeah. And on top of that, I mean the main point here is that, or the main challenge is that if I change something in my frontend, in my software, which is also an interface, a human interface, then people are hugely but not always says why we still need support teams, fairly smart at figuring out where that button went. At least I can try. I can try to look where, where the damn button went? Where did they hide it again? I want that feature back. Now when it comes to software, like mobile app or not my mobile app, somebody else’s mobile app. If I change the API underneath them, it’s just going to break. Everything’s going to break. Every client is going to break, which is why versioning is so important. But then you have multiple versions, and this is also something you need to maintain.

Vedran[12:16]: Exactly. So essentially if you do even the smallest change and I think probably iOS is the most sensitive one here. If you make the slightest change, even from, I would say a bullying to a non bullying or an integer to a string, you could crash the app. It wouldn’t even load. Depending on what the developer did on the mobile app. You might have a very bad day. And trust me, I’ve been on many, many calls when those things happened and as somebody who didn’t have Treblle before and has Treblle now, I’m very thankful that I get the insights that we essentially provide in those exact cases.

Victor [12:56]: Yeah. And it’s not a joke because then you write a fix for the iOS app and we all know how long it takes for Apple to approve changes. So this can really, really break your business for a few days if not weeks, which is tough.

Vedran [13:11]: Especially if you don’t know what’s going on. Because when something breaks, nobody on a mobile app or on a client, especially a client who doesn’t, let’s say a light bulb, that doesn’t have an interface. Somebody has to go in and actually plug something into that and examine that. So you don’t know what’s going on. The only information that you have is a report from somebody who said I tried it and it doesn’t work. You have no idea what the problem is on the API. You have no idea what the problem is on the client, if the problem is bad data, corrupt data in the database or something else. So yeah, it’s truly something that can mess you up.

Victor [13:49]: If you’re a developer who doesn’t care, you simply say it works on my machine. But if you actually do care, you now face a lot of work to debug this because you can’t debug it on the client. That’s what you just said, it’s hard on a browser if you try to reproduce it yourself, you have a lot of development tools available where you can check. But if it comes from a client and it doesn’t work and you have no idea what they’re sending, you have no way of knowing what’s happening. Especially if it’s not your client, it’s what somebody else wrote. Then you have just no idea what is going on. So really before Treblle what would you do to even debug this?

Vedran [14:27]: It’s going to sound very boring, but we used to jump on meetings for like an hour or two, where we would sit down, somebody would first yell it’s not working again. Who needs to fix it? I don’t care. You just need to fix it. Then we would try to, of course replicate that. Especially, let’s say when you’re dealing with something where a person registers for an account and has to fill out this big of a form and something doesn’t work right. In a lot of cases that just comes down to bad data, but you don’t know what they entered. You never saw. So we tried everything. We tried server logging, which is then only readable to us or I once was in a very serious meeting where there was like a crisis and I gave them the logs. And I said, I don’t think this happened based on the logs. As you know, the logs don’t show you everything.

[15:22] It’s very, I would say developer focused. So when you give it to somebody, the lawyer just said, I don’t know what this is. I can’t read this log. You could have made this up. So logs don’t help in real world situations. But it basically comes down to asking somebody who tried it, can we get more info? What device are they using? Where are they from? What did they try? Let’s try describing, let’s try recreating it. Let’s try examining the code, both on the client and on the web. So usually a lot of, lot of work would go by to even detect and fix a small problem.

Victor [16:02]: And now let’s go back to APIs in general. We already examined that there’s one use case for internal APIs to build various frontends, but then also you have internal APIs because there’s another buzzword that’s going around for the past few years. And that’s called microservices. Would you explain to our audience what a microservices is and why that involves APIs?

Vedran [16:27]: Yeah. So let’s say, the other day we were actually doing a microservice ourselves. So basically let’s say that you have like this really huge complicated platform. Let’s say that, again, let’s come back to the banking app. Banking app has a lot of moving parts. When you create an account, maybe it sends you an SMS. Maybe it sends you an email. It does something in the background that you’re not even aware of, maybe creates an actual bank account in the background. It might fetch information from a government entity to check who you are, et cetera, et cetera. So previously the way that was built and I have to admit I’m more fan of model it, but I do like microservices to a degree they’re used very well, but basically it would separate this logic into a smaller microservice.

[17:18] So the reason for that is of course, it’s much more easier to maintain, update, fix, et cetera. But also if something happens to your main infrastructure, necessarily not everything will go down. So let’s say that you have a server or a microservice is that essentially just sends SMS messages to confirm your account, if that goes down or if there’s a bad piece of code in there, it won’t crash the rest of the environment, the rest of the service. So you’ll still be able to create an account, but you simply won’t get a message. And that’s, I think is kind of what the microservice architecture is about, essentially extracting a piece of the infrastructure, the platform and everything that you’re building into its own separate thing.

Victor [18:04]: Yeah. It’s a bit like whether you’re building a mall or a lot of small stores. If something breaks within your mall, let’s say, I don’t know, the doors don’t work. The system doesn’t work that opens or closes doors or whatever. Nobody can get in and can’t get anything done. Versus if you have a streak of small buildings left or right, people can move across, but that involves you building a city infrastructure. You have plumbing, you have roads, you have public transportation that people can get from one place to another. And this is like a microservice. There’s information and data traveling. It’s not this one system that does everything, but there’s information in data traveling from one to the other. And these are your internal APIs essentially. That’s what’s happening here.

Vedran [18:52]: Yep. And you’re multiplying the amount of things that can go wrong when you’re doing that essentially. It’s a beautiful architecture, but it’s also something that you have to be monitoring. You have to know, understand what’s going on. You have to know how they’re behaving, et cetera, et cetera.

Victor [19:09]: Yeah. There’s these early pictures of, the pictures of early, you know, telephone lines, where you have like a city that, where you have a court from every building to the other, where you simply have no idea what’s going on. And so yeah, a badly built microservice can up much worse than a monolith. So actually building that really needs some, let’s say it’s more complex to build in the beginning. It has advantages, but you do need to know what you’re doing.

Vedran [19:40]: Let me put it this way. Don’t give your junior developers control and the ability to structure your microservice architecture. So try to get somebody who has been in the game for a bit longer.

Victor [19:54]: Yeah. You’ll not find a senior who will actually want to maintain that. That’s the biggest problem.

Vedran [19:58]: That’s why we, again, we build Treblle because of some of these horror stories, if you will.

Victor [20:05]: Okay. So now we know microservices, we know various clients at front ends, they all use APIs. So what’s important to build good usable APIs? What should somebody just consider on maybe a checklist? What makes a good API?

Vedran [20:22]: I recently actually wrote a blog post on it, on our Treblle blog and it’s called 10 rest commandments. And basically I wrote it because it really answers the question that you kinda asked me. The problem with basically APIs is at the end of the day, everybody is using, I would say on architecture called rest. So you’ll, you’ll hear a term called restful APIs. And it’s really actually a great architectural, I would say, pattern or schema to build APIs upon.

[20:56] But the problem is at the end of the day, it’s not a standard. There isn’t a standard that you need to comply with or if you build an API, you can basically run it through something, it will tell you it’s a good API. It’s a bad API. There are only, I would say best practices and tips and tricks that you can follow that are usually made by a bunch of guys who made mistakes before you. So you definitely, whenever there are best practices, you definitely want to follow them. But I think off the top of my head, a good API starts with I would say a good structure. And that means everything from naming conventions including naming the URLs, including naming the actions, using all the HTTP verbs that you can actually.

[21:43] Gracefully failing by that I mean, if your API is failed, then try to do it gracefully without actually breaking the entire interface in the app, by responding with Jason, by providing really insightful messages for the other end, who is receiving this API. And above all, I think most nowadays APIs actually have to be very optimized, very fast, otherwise, users simply don’t wait. If you click something on your app and you have to wait for like three minutes, it just simply nobody’s going to wait for that. So that’s very very important. There isn’t a standard, but those are some of the best practices that you could follow.

Victor [22:27]: So yeah. To follow best practices, to have APIs, give back error messages that actually tell a developer what’s happening. And obviously one of the important ones is for as many folks as possible to be it impotent. Because a lot of clients, it happens that they send something twice it has to do with a buffering or a failing.

Vedran [22:51]: One of the commandments that I wrote is like, be smart. So your API is like the brains of the entire operation. So it has to predict where others will fail and do wrong, and you have to kind of auto correct for them. You also have to auto correct for yourself. So try to, basically when you’re build an API, try to put as much as you can on the API. So that literally all other people involved, like the clients are just like dumb relays of data. And you control the flows, you control the business logic you control what they get and how they get. So, yeah.

Victor [23:27]: And obviously you want to provide good documentation, I suppose. How do you do that?

Vedran [23:32]: So previously, like I said, I measured time before Treblle and after Treblle. So before Treblle we used to write these, at the very early stages, it would be like a Google docs where you would just write what the endpoint is, what it takes and what it gives out. In more modern times, you would have to probably write the API documentation using open API spec and something called swagger. And there, you can write it in either Jason or Jamal. And it just really a lot of time to basically spend writing it. But because you have to define everything. You have to define everything from what will be, what’s the endpoint name, what’s the base URL? What authentication are you using? How is this endpoint going to react? What is the verb that you’re using, what data could be returned, what type of data that is?

[24:28] So you have to write all of that down and with Treblle, if you have Treblle enabled you don’t have to do anything. So, because we’ve kinda all been tired of that, we’ve made it so that if you’re using trouble, we automatically generate documentation every time you make a request. And we literally save you a lot of time and money on that.

Victor [24:50]: So it learns from the data and the structure, how you’re sending it, and maybe somebody. So if somebody didn’t send a field in the first request, but then they use a new field in the next, you just realize that and add it to the docs?

Vedran [25:03]: We know that, we know, for example that might be an update. We keep it in the back burner. If it happens again, we kind of merge that, and that becomes the predominant documentation that we expose. We also keep track of every single. So if you start with one documentation and end up with a completely different one, we track everything in between. We know exactly how your documentation change or is changing over time. So we could literally show you, this is what you did that day. This is what happened the last day. This is what, et cetera, et cetera. Imagine it as a DevLog right, when you go on GitHub and [25:38 inaudible]. So basically imagine that simple architecture.

Victor [25:44] That’s really cool. I think major parts, a lot of people are maybe not thinking of is testing APIs, which is also very important. So to recap, maybe for some people, whenever you write code, you should test, like there should be something that tests what you do. And there’s obviously the differentiation between manual tests and automated tests. And I suppose first how you manually test an API is far up a program called postman, something like that. You just try to make requests your API and see if that actually turns out how you want it to, but what’s a more sophisticated way of testing APIs?

Vedran [26:23]: Testing is probably like the most urban myth in development. It’s like a jeti. Somebody has seen it, but we’re not sure who. Basically you could, of course, when you write code, if you have enough time and if you’re a really good and careful. You’ll write either unit test or some test on your code to make sure it doesn’t break. And again after you’re done with that, you might actually fire up, like you said, in terms of APIs, usually that was postman for us as well. Like we use postman a lot and the beauty of postman is it’s really cool, but you’re the only guy who sees the response. And you’re the guy making the test.

[27:08] And if you’re a developer and if you created the API, you’re going to make a perfect test. That’s just a given. You’re not going to feed your own API bad, really incorrect data so it breaks. You’re going to probably imagine a scenario where everything is okay. And every time you try it, it’s just going to return everything that’s supposed to do, but that’s not actually how the real world works. Because a lot of mistakes actually happen during integrations where the clients just simply don’t do a good job. The most popular probably thing that could happen is instead of sending an ID, they send undefined or null, or empty. You’re not going to send undefined in postman. You’re going to send an ID. So I would say postman, in terms of testing is you have like a fire alarm in your house that only alerts you when you’ve already been robbed.

[28:03] So that’s how I would compare it. You need something that constantly checks and tests everything that goes on and notifies you again when something is wrong. So we used a lot of actually different tools, everything from postman, from a bugsnag, from a lot of these error track tools. We were also very unhappy with those. And we said, there has to be a better way. So that’s one of the things that we built into Treblle is actually this smart error tracking, where we track both code-based errors, but also spike usages. And even if your API is not responding at all for hours, and we know it used to respond in that period of time, we can notify you and alert you what happens. And more importantly, you get to see what other people are doing.

[28:54] So if a problem occurs, postman cannot help you. You would have to call that person and tell them, hey, what did you send to make the problem happen? So you’d have to manually type that into postman. Here on Treblle, you already know what they’ve sent. You see the data and we have this thing called one-click testing. So essentially let’s say that you deployed a codebase change, then it crashed. There was an error. You see that on Treblle, you go into the code. Treblle tells you exactly the line codes so you go in and fix it. And now you would have to, again, manually type that into postman to check if it’s working.

[29:34] With Treblle, you just click one button and Treblle is kind of smart enough to know everything about that request. What was sent, what data, what identification details, what URL, and it goes in and makes the entire request for you. So you click a button, we essentially replay the last request. And you’re done.

Victor [29:55]: That is really awesome. So to explain the nutshells so I understand, so Treblle is a bit of like in middle man, between, you plug it in between the clients and your API, and it just records everything that’s going on. A bit like a log, but it makes it accessible and visible to everybody, including less technical people. And you have a lot of tools.

Vedran [30:16]: And because we have access to that data we’re able to not only show you the raw data that you send. We enrich the data. So we tell you what the location of the user is. You can even see it on a map immediately. We tell you what device they’re using. We can even automatically without actually having access to the device, tell you what, for example, what iOS version is the client running on? Which app version are they using? And so on is so forth. So we automatically do these things. And because we have access to the data, we know when something is wrong, we can help you recreate the test. We can help you document so you don’t have to. And more importantly, I would say in the recent times, we give you valuable analytics.

[30:58]: So you know when your API is being used the most, or what app version is using it, or whatever client you might have, when from which cities, et cetera, et cetera, and one feature that we’ve kind of especially built for our fellow developers is we give you what we call like a trouble score of the API. The 10 commandments that I wrote are actually something that we wrote in code first. So we check every single API request amongst, to see if they kind of follow some of the best practices. And we give you an overall score of your API. So you know if your developers did a good job or not.

Victor [31:36]: That is really awesome. So if you are developing an API or your developers are developing an API, whether it’s internal, whether it’s external, whether it’s for your mobile app, for your desktop application, if you’re using react or something like that, chances are very big that talks in API. And you’re hearing things like, what is it? I don’t know what that person sent. I don’t know what.

Vedran [32:03]: I don’t know why that isn’t working. I don’t know why that’s slow. That was my favorite one. Like probably like 50% of my questions before Treblle were, why is this so slow? Is it the app or is it the API? Now we tell you exactly how fast the API is, et cetera, et cetera.

Victor [32:25]: And if you’re sure if your API is done well enough, then I guess you should give Treblle a try because it will help you with all of these things. So that’s pretty awesome. So Vedran thank you so much for coming on the show and explaining how that works. Where can we find more about you and of course, especially Treblle?

Vedran [32:45]: So you can always visit our website treblle.com and we’re on all social networks I believe, except Facebook. So LinkedIn, Twitter, all the major, like developer-friendly networks, like dev.to, stack overflow, indie hackers, hackerNoon. So all of these communities and of course my favorite is Reddit. So we have like this Reddit board there called developing APIs. If you are developing building APIs in any shape or form, join us there. We like to talk everything from the way we build APIs to how we crash them.

Victor [33:29]: Awesome. Perfect. Well, thank you so much. This has been a pleasure and really helpful. Thanks for coming on the show.

Vedran [33:35]: Thank you very much, Victor. It’s always a pleasure to talk with somebody who’s as technical and understand some of the pain points that we have tried to solve. So really thank you.