How'd you like to listen to dot net rocks with no ads? Easy? Become a patron for just five dollars a month. You get access to a private RSS feed where all the shows have no ads. Twenty dollars a month. We'll get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot NetRocks dot com. Hey guess what, it's dot net rocks. I'm Carl Franklin and I'm Richard Campbell here for another hour of Meret Gordon Nurse. Yes, because we were talking about meat before the
show. Yes, yes, we were, as you do. So you know, every time we end a show and it's like solid awesome, which is most of them, Richard always says, well, that was an hour of media goodness. Well, and we're digging into AP making APIs better, then this is going to be all medi goodness for sure. Oh, it's totally gonna be all medi goodness. Anthony Alaibe is here. We're going to talk to him in a few minutes. But first I have some more goodness
from Microsoft for better no framework awesome. So I just saw this as a blog post from Dan Roth. Yeah, introducing this experimental U tool or feature components called smart components, and these are essentially AI wrapped edit controls. So one of them is a smart paste, so it's takes the place of an
input textbox and by smart pace. You know, if you go to a form and it's got all these fields name, address, phone number YadA, YadA, YadA, credit card number YadA, well you could copy, like text from notepad or something that has all those details arranged in paragraphs or whatever, copy and then paste it into the form, and poof, everything goes in the right place. Nice. Are you interested? I am? This is really cool. No, no, you know, this is what I
figured all along. As these technologies mature, we're just going to incorporate them. We're not going to make apps about them. We're just going to incorporate them in our apps exactly. And that's what I love about this. It's a great it's a great application of a high technology to make every day ordinary things easier. Absolutely, and that's what They also have a text area,
so it will do sort of you put some details of things. You can train it very quickly on just some sentences that are in the style of and then it will suggest to you like autocomplete, you know, like Gmail does when you're but with real details. And then there's also a combo box, so when you're pasting components, it will pick the right value from a dropdown combo box if one is there. Nice little things like that. So this
is all good. So we're gonna link to it. It's eighteen ninety one dot pop, dot me, or you could just search for dot net smart components. Daniel Roth and Steve Sanderson does a great demo. And by the way, he is getting really animated lately in his videos, like he's turning into like Joe actor, like he I was really like a used car salesman, but not quite as not quite as catchy. But he's really selling it. Oh wow, that's interesting because he's only so reserved. He's subdued most
of the time. I think that was Glenn Block, but yes, yeah, he is a very reserved guy. But he's really excited about this and it's good, such a good idea, it's very cool, fantastic. So eighteen ninety one dot pop, dot me, go check it out. Who's talking to us Richard gradyment of Show eighteen o two. So I went back a bit that's July of twenty two when we were at ANC Lennon. We talked to Victoria al Mazova, who we should talk to again because she's so
fishit and smart. That was the whole measuring of dev secops, which is a bit of a non sequity of this comment from Rob Garner, one of our longtime listeners. Hey Rob, thanks for commenting again, even though middlely a couple of years ago, because I love what he said here. He says, Okay, someone has to say it. It's bound to result in the loss of cool points. But as youre sir, seems like it'd be hard to use at times. Sometimes I don't think I was supposed to say
that, but I'm saying it. And my example is functions. They're supposed to really the developer of the complexity of thinking about the structure of an API, to free you to just write code. And the Microsoft examples were great right up until you need to apply the repository pattern. Then you have to
use the pendency injection. They discover you'd be better using the correct dependency approach for your version of functions or whether you're in or out of process, and then you have to dig through all the examples to figure out what you're doing, because the approach is change several sigiment ways for each version of Azure function. And at that point you should be asking yourself, is a function really what I want here? Yeah? You know, and because that's a code
smell right well. And it's the thing that made me jump, was like not thinking about the structure API, because you should always think about the structure API. Yeah. I think we're going to talk about that a lot today. I think so. But Rob, you know, you said the thing we're not allowed to say out loud. And part of this is just the twitching of Azure right Like Microsoft still figuring out how to deliver these things to us too, which makes it really makes it tough to write code against it
because you don't know what's going to happen next. And I don't know if I'm put if I'm making that API available to more than just me, I need to think a lot about making it right and what that looks like. Indeed, So Rob, thank you so much for comment. To copy of music code by is on its way to you. And if you'd like a copy of music Code buy, I write a comment on the website at Donna
rocks dot com or on the facebooks. We publish it show there, an if you comment there and I read on the show, will send you copy of us to go by, and you can follow us on ex Twitter, Twitter x or whatever the hell they're calling it these days. But the cool kids are hanging out on mastadon. I'm at Carl Franklin at techob dot social, and I'm Rich Campbell at mastadon dot social, and of course you can find all the ways to get in touch with me at Carl Franklin dot com.
All right, let's introduce Anthony. This is his first time on dot net rocks, so let me give them the formal introduction. Anthony Alaibe has spent over a decade building software at companies like Opera, Parody, Polka Dot, and Delivery Hero. He has faced his fair share of dealing with unreliability and breaking changes and APIs, including losing over two million dollars in orders to such API issues at Delivery Hero, which prompted him to build API toolkit dot
io to help companies navigate their back end and API landscape. He has an academic background in medicine and it is currently based in Berlin. When he's not writing code, you can find him binging an anime series or thinking about how principles from the medical world can help us build software better. So from the medical world, So you're saying we should measure software using the metric system.
Obviously the rest of the world does you guys need to catch up. Hey, I didn't start the fire, Okay, I just live here, make the freaking rules. In fact, I got an A on my metric test in sixth grade in moose Humper. Okay, silliness. So, yeah, what did you think of the comment that Richard wrote about functions being I think I only read it. I didn't read it. Yeah, you wrote it
with your mouth kind of. I made noises about it. It's gonna be one of those Yeah ahead, Yeah, I mean I think Richard said it said a nice right, we want to use functions functions as much as possible. You're small constrained, But then soon you want to access it that's a base or you want to access access to the dependencies, and it doesn't work out anymore because yeah, you need dependencies somehow. Pretty soon you're just holding
on to functions. Is for the purpose of having a function exactly, but I mean so at the code level, I think when we can, you know, functions can be pretty or I think they might preferred way you know, to go when I can, just because they're constrained, you know exactly what goes in here. You don't expect so much magic, especially if it's
like, you know, some kind of pure simple function. You know, it's like maybe not gonna reach out to data days without extra Also, I find that functions are best used when they're used a lot, so they don't go to sleep. Yeah you know what I mean, Because when a function goes to sleep and the next user comes around and wakes it up, they gotta they might take the wrap is broken. Yeah, I what fund did I be talking about? I think Azure functions. Functions? Yeah, okay,
okay, I was talking about beyond the functions somehow. Yeah, I'm sorry, that's fine. So, yeah, we've done a bunch of shows around the whole concept of the modular monolith, and to me, it's like the function is where you put the the badly behaved piece of your monolith. That it's the one that's being called all the time, and every time it needs to change, it resonates the whole uh block a day of app like, so you want to put it in its own wrap, or it's gonna
always be active or most of the time active. You need to scale independently of everything else, Like why why I have to light up more instead of app service when you could just have this noisy thing running in it in a function exactly. Also when you want to when you're already dip in an ecosystem, for example, when you want to you want to react to events, say, you know, like streaming events, do something and do something else
and trigger something. Gain action functions are very good for that because they just get caught when that event happens, especially if it's an event that doesn't happen constantly. You know. Yeah, hey, can you tell us the delivery hero story? Because I love hearing about people losing millions of dollars. I know, I think the delivery hero story is not that. I think it's a story most of us have experience, maybe you know, at different scales,
and what happened was that? Wait? Wait, what is delivery hero? Because I don't know. This is a popular in the United States, right, but elsewhere this is like this uber eats kind of thing. Yeah, So deliver Hero is this company of companies. That's why the brand is not as popular. But it's a company that owns I would say, most of the food delivery brands outside of China. So if you think of Global or food Panda, you know, depending on where you are food, but
they only deliver Hero sandwiches. No, most of the brands that are owned by deliver here, Like there's an online pizza brand and I think they only deliver pizza. But then the other regular Uber eats style right brands? Yeah, yeah, and I see, like this is not North America, this is South America, Europe, Africa, Middle East, Southeast Asia. Exactly. Interesting, So what were the API issues that lost two million dollars?
That specifically was a migration, so it had to migrate. We were writing a service, so we're writing just taking out a little bit of a monolith to be a separate service. And this service was the sech and discovery experience where you could set for food for most of these apps and get the list of dishes. And so we implemented this. So my team then we implemented this service like you would write, you know, we we tried to get
the specification of the endpoint that we're migrating. But you know, with legacies services that documentation might not always be the best, so well, that's a very polite way to put it. So yeah, so we of course did the manual a way as well, which would be that you you know, copy the request and maybe difits use that as as the infut to implement this
new service. And when it was time to roll out, we even went to step further that we would we run both of them on staging and you know, differing, so when a request comes, to send it to the legacy service and also send it to the new service, and then put requests together to make sure that you know, we was doing exactly what was right. So you're you're literally just white boxing this. You can't see what the
original code is. You're just saying, if I do am I getting the same outputs for the same input on the old one as the new one, exactly. So this the old code was really it just it's just some I don't like you said the word legacy, but it was one of these services where most of the original authors were no longer in the company. They're gone, Yeah, yeah, they're gone. Totally normal exactly, and it's difficult
to you know, to get dip into the weeds properly. But even with this care, defering all the requests, writing as much tests as possible, when we went to production, thinks they went crazy, you know, So did you know right away there was a problem or did it just was losing
data missing things? So when we went to production, obviously we you know, we have the deployments checklists, you know, check that things are still working as expected in as many countries as possible, but we didn't check every country because we were perating were at the time we were put it in fifty
five countries. You know, we're not gonna test fifty five countries. Yeah, And so what happened was that in scandy In some of these countries, specifically in Scandinavia, they have a leg lego we requirements that food delivery companies have to include the dietary requirements of any dishes that they offer. Right, none of us knew about this requirements, Like, I had no idea requirements what requirements? So are these nutritional nutrition values all that kind of stuff,
exact cast whatever, and also allergies and things like that. Okay, yes, but this was a requirement only in Scandinavia. The other countries couldn't curt us. So everything worked perfectly in the other countries of course. So you just you just turned off. So did it fail in Scandinavia or did you not provide the data or did you get sued? Yes, we're just just crashing in Scandinavia, so wine exactly. So a couple one hundred thousand people
didn't get their Ludificit deliveries. Yeah, So that that's basically what happened. And it seemed like a selly thing, you know, just a couple of missing fields. We had pretty good monitoring set up we have, you know, we try to do things carefully with this migration, but that did not prevent us from running into this trouble and maybe start thinking, you know, why can't we automate catching you know, breaking changes or any kind of issues.
So that is basically what happened. You know, we most of us have been there, so yeah, yeah, I know the pain. Maybe not that much money, but I know the pain. Yeah, we have to be very careful, do you like that's the whole point, Like, be more careful next time. Isn't a good strategy? Like we should be
able to not be careful and we can't do harm. You know, what's a good idea is to have a lunch and pass around the Arizona missions insurance policy that your company has, and it tells you what you're on the hook for. And you know, typically in one of those policies, it'll list
right there failure to prevent a denial of service attacks for example. So if you're publishing an API and you don't have any kind of throttling on that API, you could be sued for one of your downstream customers having a denial of service attack. How about that? I'm just shocked at Jillie. That is in a lot of contracts. Well, it's in an insurance policy. The kinds of things that it would cover. Yeah, well, I mean first
problem with reading insurance policies is staying awake. Yeah. The second problem is it will just strike you with fear at all the possible risks. You know, but that's a good thing to know, Like, what what are the things that the insurance companies are concerned about in terms of aris and omissions that you should kind of you know, think about. Yeah, not the litigating is ever is likely to provide a useful outcome. Now I don't want to
avoid that. Yeah, winning a lawsuits like winning an earthquake, right, Like, there's no good outcomes there, right, So that the key is to not get suited in the first place. Yeah, try and try and work this out. So is was this the story that led you towards API toolkit? Yeah, it is precisely this. But you know, all through our careers, we've we've faced a lot of these little issues that kind of stack up in the back of our minds before even a delivery. Here.
I used to work in a at a basically a digital bank, you know, and with these digital banks we have, we still have to work with dead parties. M So the dead parties could be other aps like MasterCard or other banks. In this case, it was in Nigeria, so we had to communic get with other bands and the national into band settlement system. And it was very common that, you know, these tech parties would either just
go down or they would just introduce breaking changes. It could be something as simple as we're naming a field, you know, maybe someone named the field messages before and then some new engineer says, why is this messages it's always one message and then changes it to a message harmlets from his perspective. But you know, no one was prepared for that. I worked on a project once where the architect had every field be an array instead of just a single
value. In the event that someday down the road, perhaps perhaps you might want to pass two of those values instead of one. Yeah, that was a lot of fun, to be fair, We don't know the trauma or that experience before that made him do that. Yeah, that's that's but you know, there's there's preparing for trauma, and then there's just common sense being agile, right, all right, So we haven't really talked about what API toolk io is. If you go the API toolk io, it says AI
powered API observability, quality assurance, and insights. So give us the elevator
pitch there. Yeah, that's a lot of words, but the whole idea is, you know, we already have a lot we have our monitoring platforms already, but can't we go step lower you the most monitoring platforms would catch several issues, maybe some logs and any errors you put in your lugs, maybe, but do we go step for them, actually analyze the payloads you know, will requests body and response body that your customers are making to you,
but also that you are making to tear party integrations. And it is and the reason is that and not every error is going to be an error in your log or an exception that you can catch. Some errors could just be you know, missing data, something was renamed, or an error that is coming from a dependence. I can give a story about this dependency because
there's something that happened. A customer had to deal with a library. You know, it is simple date library, you know, and this date library was created by an American, so but the diffault but it diffaulted you know, the US date formats, which is I think it's month day and then yeah, and there was this very long conversation in this on this library jub that hey, we should use the international default of the day a month year. And it went on for I don't know, maybe with a for years.
Then the author gave in and said, okay, let's make this change. And there was I think a six months depplication. Notice it's just a live you know, everyone no one's reading the git hop issues of all the libries they use. So when this update happened. Eventually, it caused subtle changes were for some customers the date field, you know, was now like the international dates type. But that is a hard thing to identify it because some days of the year are basically the same on both the US date and
the international and like fest of General eleven eleven ten exactly. I'm really surprised that out of that meeting didn't come the solution, which is to separate the date into three arrays, one with the day, one with the month, one with the ear because that's clearly the solution that might have walked you, to be honest. But in any case, it was a breaking change and it causes company quite some money. So it was not the kind of change
that you would blame a developer. You know, maybe some developer was working on a completely different task, decided to update some dependencies and now there's an incident that he has no idea where it came from. So those are the kind of issues I was thinking, can we catch them at the level? Wow? Yeah, IO eighty six O one exists for a reason. It's year, month, day just at least, you know, however you want to display it after that, knock yourself out story. It is year,
month, day, right, what could happen? Yeah, it's a classic words. So you feel like you could catch this from at an API level to say, hey, this API is measuring up dates. Now it's doing something down with dates exactly. So what what what we're doing is, it's imagine a middleware on your service that every time a request comes into your service, it just takes a copy, so it doesn't really impact your run time
or whatever. It just copies it and then you know, sends it somewhere and that in that somewhere, which is a kid m we're like just learning. We build a model of the API, so we learn what all the fields are, whether all the different permutations of fields that are possible on this API. You know what at the type is this field supposed to be a uu i D or is this some random number? And with this model a
lot of things become possible. For example, if this representation changes, if some field used to be a uu i D and all of a sudden it's just a number or it's a text, right, and someone gets notified and
say, hey, this fields changed. Was it what you intended? If it was what you intended, then just acknowledge it, but sometimes it's a bug and someone can fix it. But I like the idea of you just snap this onto the system and let it run for a month and it should build up a pretty good catalog of all the shape of API calls out there. Like in a month, you're going to figure out if you misunderstood the day, feel exactly exactly. And it's like it's it's open to the developers
because you can just go. You can go and see all your endpoints. Pick one of the endpoints and see all the different ships. You know, at the end of the day, most endpoints don't have quite so many ships. You know, maybe there's a lot of different status codes and then different responses. I'm sure eighty percent of them are fine. You know, they're all the same, and maybe it's even ninety five percent of the fine.
It's all the edges that matter. Sometimes you've got Scandinavians that requirements just to highlight that, hey, there's an additional chunk of data in anything. Going to these end points would have been enough flag for you at least look to
know, oh that's something weird there. We should go look there. Yeah, appreciate, So we basically did that, and along the way we realized, oh, now we're analyzing and building this model, there's much more we can do, for example, So when I started to think, okay, what what can we do? For example, we can generate open API specifications from this model that we have now. And the next step is we can
generate simplistic h kind of API tests. You know, because you understand the users journey on the back end, sure you can say okay, use our logs in. Then it does. I can just generate some tests that can now be auto make it and say, okay, make this call, make this synthetic monitor call every one hour, you know, just behave like a user and check that everything is as it should be. That's basically it. So it's the It's the thing I wish we had at delivery here. Yeah.
Yeah, absolutely, if it existed, you probably would have got that. I guess the question is the overhead Can I can I feel it when this thing's turned on as a number of requests per second go down just because you this is going to cost me something, it will cost you something, and that's something depends on the technology stock. So if you're using a stock
like PhD, the challenge with PhD is that it's it's single process. Every request is processed in a single process, right, so we can't just you know, just do something behind the scenes, although we try and use a lot of different techniques. But if you're using phper used to pain anyway, right, But but you know the other technology stacks, you'd almost you would notice. It's like copying of request happens in nane a seconds, micro sequence
max. The sending of the data. It's like if you have any luck, you know, any telemetry, it's basically the same. You know, it's just a synchronous maybe you get you spend a little bit more memory. I mean, I just like this from an observability perspective to see, Okay,
well what do you see about what my APIs are up to? Like we've talked in the past about Azure API management, but that's mostly about you know, something that Carl mentioned earlier on which was going and yeah, can you deal with throttling when a runaway process is calling it fifty times a second? Certainly the most popular feature. So the unilease say that one bad actor can't knock everybody else down. Yeah, no, you guys are doing content
analysis, which I think is a much trickier problem. Yeah, exactly. We can't go on an Arctic proxy unfortunately, so we can't we can't trottle anyone. That's a different thing. Use APR management for that. Yeah, exactly. Hey, guys, holding that thought for just a minute, while we take a moment for these very important messages. We'll be right back, and we're back. You're listening to dot net Rocks. I'm Carl Franklin. That's my friend Richard Campbell. Hey, and that's my new friend Anthony aler
Rebe. And yeah, he's talking about APIs and observability and the AI part of this, which is really content analysis as he was just talking about. I'm really interested in how you use your medical training to write better software.
That's that's an interesting question. Something that I that I have been thinking about that I think could learn from the medical world is s OPS or against We like to call it everyone's books in our industry, but in medicine, there is an ESPN s P Standard Operating prosidure, So there's a standard operating procedure for pretty much everything. You know, if you if your doctor is gonna open your hearts, he's not gonna be like, oh, I'm feeling crative
today. Let's just go for it idea. Yeah right, I remember just opening from the down from from down this time, but no, let's go through the button transplant. Yeah. So, but it doesn't mean there is no creativity happening in the medical you know, there still is. But there is creativity happens with constraints. You know, when all the the common problems are solved, then you can like you know, you can get like small things at the time. And actually, like in software, we're always inventing
the same pop the same things over and over and over. There's a lot of blog posts. If I want to create an up today, it might be different from how I created an up last morning. Well, and I do think we have that problem in software where no two projects are ever the same. One could be excused by, hey, the stacks are advancing, but the other is that we are prone to wanting to play with the new toys. So you know, the opportunity to go, oh, I want
to play with this stack now, which not many. You know, that's kind of service to us rather than service to the customer. The rather to go with the stack. I already knew as well. Instrumented. You know, has the pipeline set up for just resists. It's okay to work within the same stack. There's innovations that can happen inside there. Well said, I think that is basically it that you know we have as engineers. We
want to expect events, want to try new things. But if we can just agree on some standard I don't know, base layers, you could move that innovation step further. So maybe instead of everyone creating one more and plus one framework that is I don't know, almost the same as the other, we can start I don't know, innovating at I don't know, you know, some of the things that are actually different, like our business logics or
the problems you really want to solve our performance. Maybe apps can finally be faster and we can only innovate on how to make things faster, et cetera. But it's something that I'm thinking about. Have you seen more maybe a question for you, like in your experience, how much have you seen one books being used in internal organizations? I mean more? Uh? And you know, and when I hear run books, I think chef right? Is there really the ones who popularized that net names? As I said, A
cid CD pipelines. There's a bunch of different approaches, but it's automation. It's about don't open a word document, right, don't it's code. H You know, today we look at GitHub actions or as your DevOps, like in the in the dot net world, where often just checking the code in accepting the PR kicks off the process that begins all those integrations, decks, the rum book is activated, and I definitely see more and more developers.
Was like, I don't want to think about this. I want to get as far as it worked on my machine, it passed my unit tests, I push it up as a PR, we go through the review process and
the rest isn't my responsibility. The whole team took care of that. And I think there's a natural cycle that devs go through or dev teams where something new comes out and it promises to you know, be a little more complex upfront, but then save you time down the road, right, And this happens over and over again, and most devs resist that because they don't want to go through the initial pain of learning something new and changing moving your cheese
and you know, changing their routine. But then you know, then they see somebody else, just like going at one thousand miles an hour and things are just happening, you know, Like the first time we interviewed Mark Rendel Richard and he told us all about like all these crazy processes that he had in automation that he was doing, and it was all manual and stuff. And the first my first thought was, oh my god, I'm never going
to do that. But then I thought about, wow, the you know, from thought to implementation to publishing can just be instantaneous, and how powerful is that? Right? And then you know, after a while, these devs adopt these things, but it takes a while. I have customers that are still you know, living without source control. Oh man, can you believe that? And I have to educate them and how to use GitHub before
before we can even start working. I found that interesting. Just like you said, I've seen that run books are most popular in c I CIT you know, or in deployments. You know, let's have a run book for how to roll out the new service. And because we have those run books, a lot of evolution happened, like like anty Ball and optio, you
know, having Docker for example. Just the benefit we have in our industries that if a lot of if things are done over and over, it might be possible to just you know, box it up into Docker or into some library or something. But I I feel like it can be run books, or the idea of run books could be applied even further to more things, you know, And I mean, I'm not going to pretend can do the
how. But assuming we had more maybe an industry wide agreed upon run books for a lot of things like maybe how do I beld X y Z or how do I you can onboard even the more junior developers and you can trust them to do quite a lot of task without being afraid because they're really just following a run book and then allowed the creativity just happen. Maybe in creating
new run books for example, are we dancing around? The main thing here is which is part of that pipeline is testing, right in automated testing, so that the junior can't write a piece of code that's going to cause a problem because the test is going to kick it back. You're not you know, I think too many people think about the pipeline as just deploy this.
For me, don't think right, it's really just the continuous deployment part and the only part of a continuous integration that's in there is compile it, which really real integration is is this code suitable to be integrated? I very much agree with that. Yeah, well, I think the tool your building here is about I have collected data for how this API has behaved in the past, so I can generate the set of tests for you that become part of
the pipeline. So if your new code doesn't comply with what we know is the current way that the API behaves, it's not getting integrated. Yeah, exactly, it is exactly that you know that we can catch. And if you consider how as developers we always know the ideal, we know what we should be doing. We know we should all be writing tests. But every time I speak with a developer, I ask them, you know, like, how confident are you in all the tests you've written? Do you feel
like the software you maintained right now is perfectly tested? It always feels like anybody who says yes is lying, right, like the the that's the old are you a good man? Anybody says you question, it's like the correct answer is I'm not sure, Like arguably it's not up to you, right, are you perfectly tested almost certainly. Not am I sufficiently tested? Perhaps, Like there's no absolutes here, just just for the just for as much for as I have. You know, at least I'm tested enough for the
last incidents that we experienced. Yeah, I'm not likely to fail on the thing that knocked the system down last week. I'm not even saying certain about that. I'm not likely to fail on that. I was a betting man, Yeah, I kind of. I took it on the head for that one already. And I think I've written the test that that that would catch that before it gets deployed. Now, well, let's go to the next
one. Let's see what happens again. I think the most important thing here is this idea that stated period of monitor of observability with this tool builds a test suite for you, because who likes writing tests? And then and here's a joke, like I write those tests, then we rev the API, so the tests are wrong and we got to go again. Right, So the idea that you could regenerate them after that is pretty compelling to me. Like that's a bunch of work nobody really wants to do in the first place.
Yeah, Actually, this idea. Half of it came from something we did at Delivery Hero, which is we used to have this lot test that we would like write, you know with like case six, you know, write some general tests to show I don't know, a million requests a minute at the seven right, But they were always wrong because we had very good cushion, so pretty much all the steps would just get cushion and the great
I don't just want. We got better results when we actually recorded, like there are lots of what reques production work exactly, and then just replayed that well, And that's because humans are weirder than testers. I mean, testers are pretty weird, but humans are weirder still, Like, yeah, they do stuff you couldn't even imagine to think of. Just think of little Bobby tables. Here you go. No, my favorite one was working on a site that was barely hanging on, like it was overwhelmed by the load and
the reaction. And part of this problem was that the customers when the first page wind load, opened another window and tried again, and opened the window, tried again, and so it's like one ip looks like it's own DDoS attack and you get multiplied by ten thousand of those people and you you know, you designed your tests where each ip made one request, one page was and that is just not what was happening exactly us Just yeah, no,
this this recording the workload and then being able to play, you know, a Saturday afternoon football tournament workload a bad one. And you would hope that whatever workload you run includes Scandinavian countries. I think that's gonna be important. Hopefully maybe that week all of Scandinavia. I was like, they were on vacation. You missed it. Yeah, they need to get their lutafisk on
time. Can we talk about pricing here? I'm looking at pricing and there's a free uh tier, a plus tier for twenty dollars a month, I think yeah, and an enterprise for police call and so for free you get what twenty thousand requests per month, build monthly, one team member on the last fourteen days of data retained. So you can get aready checking this out without without you know, any pain. Why wouldn't you? So how do you hook this in? Like? Is this code I compile into my app
and deploy it or is this a service? What does this look like? Exactly? It isn't middleware that you you know, you just added line in your code when we started out. You know, there's been a lot of movement in this e BPF space, and that was originally what I was thinking about, but then I realized that, you know, if you want to really help develop us, we want to give them as much context as possible.
Sure, and that context includes things like, you know, when when this customer made this request and it failed, these were the exceptions that happened right in the code at that time. And when we do things with the e b p F for out, we don't have that context. And what's in the code, you know, we have just the HDTP Yeah, you want to be in that process, so you see all those exceptions occur exactly. So, so it's a middlewhere you log, you put it in the
code, and it copies the request. If there are exceptions of the errors, it attaches the errors that happen to the to that particular users. I don't know log you know, so you can see, okay, this user with this IP address made this request and got this response, but there was an error with this tackt traits and whatever that happened in the meantime and you
picked. So that line of code is then an invocation to a service you're hosting on their behalf or could they run it themselves internally, So that line of code is India code. It's in your application, you know, and you can so what is it calling to? Like, it's it's there's an open source SDK for most languages, which what the KID does is basically copy, you know, get all of this information for some cost them as they have sensitive data which they don't want to even live there save us in the
first place. So it's able to redact that sensitive data and then just put put the data on, just send it to API to KID. For some enterprise customers, they also just run it on prem in that case, so there is an on prem option if you want to pay for it. Exactly in that case, it is just a ducker image you're configuring and it just sends it there. That's great, And exactly what I was thinking is like
it's in many cases. In some cases like I want to say, they'll leave my data center or my assurance then so it's contained and it had to happen. It had to happen because I built this, because I worked in a bank in the digital bank and you know half of the problem came from there. But digital but are not gonna trust well, they're under regulatory requirements, like they'll lose their license exactly. So what's next for you? What
are you working on? What I'm working on is basically this is just making especially the things around testing. I'm trying to see what context we can get. And you know, it's like you have all of this data. Every time you look at you you're like, oh, I could do this. So it's just you know, how can we make the life of developments better with the data we already get in anyway? Yeah, wow, if you can help me write tests for my API so I don't break it in the
next rev you're my friend. Yeah, this is good stuff. Yeah. And to start with a free tier just to see does this make sense for me? And it's like, yeah, your first HiT's free, you'll get addicted. Yeah. And I think probably the takeaway message from this interview is that this is not an API management replacement. This is content. You're you're you're testing content and you're looking for that and using AI for that. So thanks Anthony, it's been great. This is a great product. Thanks.
Thanks go. Thank you're welcome, thanks for us beinging this hour with us, and we'll see you next time on dot net Rocks. Than dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London,
Connecticut, and of course in the cloud online at pwop dot com. Visit our website at d O T N E t R O c k S dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now go write some code, see you next time. You got jud Middle vans Man