Microsoft built Kiota to keep an API with 20,000 endpoints humming

[00:00:00] **Phil:** Hello everybody, and welcome to another episode of APIs. You won't hate this time. It's just me, Phil, with no mic. I, I don't know what I'm doing. He, there's a lot of buttons on my screen and I'm a little bit scared and confused, but I I think it's recording. I think this is a podcast and thankfully to keep me company with this world of confusing options.
[00:00:19] I have two wonderful guests Darryl Miller, who has been on the show before, and a new guest Vincent Bere. Did I get that right?
[00:00:27] **Vincent Biret-1:** Yes. Perfect.
[00:00:29] **Phil:** Fantastic. Welcome both start with you Vincent. Would you like to just tell everyone who you are?
[00:00:34] **Vincent Biret-1:** Yeah, sure. Hi everyone. Nice to meet you. Nice to meet you in person. Making our quotes at the same time, Phil. And I am based out of Montreal. I'm a principal developer on the Microsoft Graph client experience team. And I work a lot with Darl on the day-to-Day basis.
[00:00:51] **Phil:** Nice. And Darryl, who, who are you?
[00:00:53] **Darrel Miller:** I work at Microsoft as an API architect on the Microsoft graph and in my. Spare [00:01:00] time. I spent some time working on the open API specification and a few IETF HTP related specifications.
[00:01:06] **Phil:** Nice. And I'm really glad that you could both come today to talk all about open AI and the latest happenings with Sam Altman.
[00:01:14] **Darrel Miller:** Our lips are sealed. We can say nothing.
[00:01:16] **Phil:** Okay. Yeah, no, I do often confuse open AI and open API. So yeah, let's, let's talk about that one. So you guys have made with a lot, a lot of other people involved. I'm sure you've made another SDK tool that's a little bit different from some of the others.
[00:01:32] But first we have to ask ourselves, what is an SDK? What is this tool all about?
[00:01:38] **Darrel Miller:** Well, I, I, first of all, I wanna say we, we are trying not to call it an SDK generator because. SDK is a term comes with a lot of baggage and is confusing and people have different understandings of what it means, and so we like to call it an API Client Code generator, which is a bit more of a mouthful, but it is a bit [00:02:00] more explicit.
[00:02:01] Vincent, tell 'em what it does.
[00:02:02] **Vincent Biret-1:** Well, it will for any rest, API that you have, that has an open API description, it will take that and generate client code to call your. Rest API with fluent API in the code and models, and it'll handle ization, ization and a number of different aspects for you so you can get going calling your API and you focus on what matters, writing the code for your application and not just, you know, handling ization digitalization and, and nitty gritty details like that.
[00:02:33] **Phil:** Brilliant. And so we've had, we've had a couple of cool, a couple of podcasts about kind of SDK generators, client stuff in the past. I think depends on what happens between recording and actually publishing stuff. But like one of the last ones was about that. We've talked about Fern in the past and we've talked about amatic and so. Now we're talking about Kyo, not
[00:02:57] **Vincent Biret-1:** Yes.
[00:02:58] **Phil:** KTA from [00:03:00] Microsoft and. It's a little bit different. I noticed that you are trying to take the approach. I mean, some of these SDK generation tools kind of come across like you are the API development team and you don't have time to be right in a Go library and our library and other languages that you might not know.
[00:03:17] So just run this command. And then tadda, it's been published and all different, A PA developers use all different. SDK generators and some they write by hand and some they use different tools. And so everyone's A-P-I-S-D-K looks a little bit different. It seems like you folks were going for a slightly different approach of kind of you're an API client and you could, you could grab a bunch of different open APIs from different people and generate a whole bunch of SDK well API client libraries yourself so that you can work with other people's APIs.
[00:03:49] Is that about right or have I just butchered it?
[00:03:52] **Vincent Biret-1:** No, it's perfect. Actually. You could, you could do the podcast on, on your own by yourself. You already know everything here, but
[00:03:58] **Phil:** later.
[00:03:59] **Vincent Biret-1:** yeah, [00:04:00] exactly. I'm, I'm gonna grab a coffee instead, but yeah. The idea is to. As you can still use Kda to as an API producer to put SDKs out there to reuse your own term and, and offer those to your customers.
[00:04:13] You can perfectly do that with Kda of course, but we set out on a different approach, as you said, to. Make sure that you have a consistent experience across multiple APIs. More and more nowadays projects or applications have to integrate between multiple APIs, multiple vendors that we use, and having to, you know, find out whether or not they have a package for you in your language first, and then learn the semantics and the different aspects of this specific package for each and every API you consume.
[00:04:44] Potentially get into, de dependencies, conflicts and having to resolve that, which is always awesome to do. We, we really want to get rid of all that, that experience for, for people and instead say, all right, you have your API consuming tool and API discovery tool for that matter. [00:05:00] Because KRA also offers search and discovery commands and, and, and features as well to allow you to discover public APIs out there.
[00:05:08] And then you pick and choose not only the different APIs you're interested in from the different vendors or partners or whatnot, but you can even get down to choosing a specific. Operation under specific endpoint. So now you get a client that is very specific to you, what you actually need to do, and you get this consistent experience code writing experience across multiple API providers.
[00:05:30] **Darrel Miller:** Yes. So Phil, the problem is developers have opinions. We all have opinions about HTTP and when people go and say, Hey, I need to build an SDK for my API, so that everybody will use it. So PHP developers will use it and Ruby developers will use it. We all go and build these libraries that say, well, this is the way that an H-T-P-A-P-I should be projected into into the native programming language.
[00:05:59] [00:06:00] And the problem with having every API provider. Have their opinions on how their API should be projected. It means that poor API consumer now has to deal with everybody's opinions of every API that they go and talk to. So the Kyoto approach is, well if you can put it with our opinion, the Kyoto opinion on how you project H HB APIs, you can then use K for every API that you want to talk to and you only have to learn how to do it once.
[00:06:29] And we are. We are as un opinionated other than . Having HTTP opinions, like we don't take the HP methods and say, well, usually when it's a post, it means create. Therefore we're gonna use the create verb on a method. We just tell you, there's your post, here's how you put HP headers in. Here's how you put query parameters in.
[00:06:50] Here's how you format a request body. You understand the uniform interface, we're just translating it into your programming language, and we'll deal with the really annoying stuff, [00:07:00] like figuring out how to present in code parameters in a query string, and how to use a UI template
[00:07:05] to construct. Yeah, yeah. All those ugly things. That those edge cases of HP we take care of. But you take our projected code, which people have said, yeah, this is not how, this is not an optimum experience for this API. And I'm like, yeah, I know it's not an optimum experience for the API put an adapter in front of it and create a perfect experience for your.
[00:07:27] A particular application that you're building and use it as a mocking interface and then hide our projected code behind it. You're never gonna get beautiful projected code. And we keep trying to do that based on a whole bunch of people's opinions, and you'll never get everybody to agree on what the perfect projection of an HT P API is.
[00:07:48] **Phil:** Yeah, absolutely. I mean in, in most kind of worlds of frameworks, there's a whole bunch of different. Coding patterns that people prefer. And then, you know happens in Laravel all the time. Everyone goes from repository, [00:08:00] pattern, event bust, all these different things and like different different naming conventions and everything else.
[00:08:05] So yeah, certain communities can't be consistent with themselves and even if they do reach consistency at any point, it changes. So it can be really hard to try and make something that, that, that makes everyone happy. And I saw Remember, I remember seeing you give a talk at one of God knows how many conferences a couple of years ago about
[00:08:27] **Darrel Miller:** The
[00:08:27] kit back in SDK was what it was called.
[00:08:31] **Phil:** yeah, that's the one.
[00:08:32] It was like, yeah, how to make good SDKs or whatever. And a lot of it was talking about Middlewares. Do you still have a bunch of middleware logic in Kyo Did you manage to get that in
[00:08:40] **Darrel Miller:** Yes, indeed. It's all built on that patent. Vincent, you wanna go into a bit of the details of the underlying bits?
[00:08:47] **Vincent Biret-1:** Sure. So the. code we generate only relies on a set of abstractions that we publish, of course which means that as soon as [00:09:00] we, you generate a client for an API and that you pull the abstractions package, you'll be able to build your project solution application whatever. It won't do anything, of course, because you'll be missing a bunch of implementations, but at least it will build.
[00:09:13] And then for those attractions that are for executing the HTP request serializing, decentralizing, and the authentications aspects as well. We provide default implementations that you're more than happy more than welcome to use and import in your project or your application. But if you're not happy with those because you need a different ization format or you prefer a different library, for example you can re-implement those abstractions and, and swap those away.
[00:09:41] And if we focus on HTP and executing the request one of the abstractions we have is the request adapter and we have a default implementation that also provides a bunch of middlewares for retry handling, compression handling, redirection handling, and a different of of things set of our [00:10:00] things as well.
[00:10:00] And, and now if you want to add custom behavior to that, you can of course just write. Additional middleware. If you're happy with a client of choice, we've selected, or if you're not happy at all with a client, which typical client we've selected you can of course reimplement the whole interface and, and, and, and do whatever you prefer here, but.
[00:10:19] **Phil:** That's brilliant. Yeah. 'cause middlewares are just increasingly becoming the thing I'm the most interested in when it comes to . Pretty much any part of working with APIs, right? 'cause the, the actual business logic of, of most APIs is quite small. It's usually like, oh, we're gonna call a model and add some stuff and do a bit of validation.
[00:10:37] But that's like three lines of code and it punts it off to a whatever service some sort of service class. But the most important, like API logic, Both, both client side and server side. Most stuff can be implemented as middlewares and everything from you know, rate limiting and caching. And I was just doing a whole series of posts about like item potency, keys and, and things like [00:11:00] that.
[00:11:00] And both the client and the server can just kind of install one package and just register it and, and, and use that. So is there a bunch of like pre-built stuff? For Kyoto, you like, do you have support for item parent C keys? 'cause that'd be fun.
[00:11:15] **Vincent Biret-1:** Now, so this one specifically we don't have but it'll be very easy for you for any language we provide and support today to say I wanna add support for potency, keys, and write up a middleware and add it to your chain and use the same exact client you just generated with qal. You don't need to change it for generated.
[00:11:32] Code at all or touch any of that. You just need to add your crosscutting concern, implementation and, and, and you're good to go. And, and better than that we work a lot in the open as an open source project, so if you feel like what you've built will be valuable to others, we'll be more than, well, happy to see pull requests coming our way and, and, and, you know, make others benefit from your hard work here.
[00:11:54] So, Yeah.
[00:11:55] **Darrel Miller:** Did you notice?
[00:11:56] **Phil:** sounds like it does.
[00:11:57] **Darrel Miller:** Did, did you notice Phil in the latest [00:12:00] update to the item potency, item potency, spec in the ITF? That hasn't quite . Been gone through last call yet there was some wording that was changed that now allows a client to send an item potency key, even if they don't know whether the server supports it or not.
[00:12:18] And
[00:12:18] this, this came from browser vendors. cause the browser vendors were like, Hey, it would be really handy when we're. To send an item potency key in the hope that maybe the server supports it. And then if a server does, then, then, then, cool. So you don't need this pre-negotiated contract and Oh, I know that the server implements it, therefore I'm gonna send it.
[00:12:41] You can just always send it on a post if, if you want that post to be ideally,
[00:12:47] **Phil:** that makes a lot of sense. I mean, they already kind of take a huge amount of guesses at various cash in logic and, and do a bunch of things for you. And like most browsers will already say like, are you sure you want to refresh this page? 'cause that means you're gonna. [00:13:00] You know, resend this data.
[00:13:01] Now they can change that to be like, are you sure you wanna refresh this? Because it might resend the thing. Or, but if they've had like good responses and they know that it does support it, then they can be like, yeah, you can refresh this and not have to show you the message. So that's pretty handy. I cool Bit of a tangent on item potency keys there, but there's a blog post. I'll tell you all about it. I wrote one for the APIs. You won't hate blog. That was mostly just me complaining about getting charged three times for a hotel. But then I wrote another one for HT TP toolkit on their blog, which is actually useful.
[00:13:31] So go and check that one out. Now that I'm done plugging my stuff on my stuff, I am curious what Microsoft's interest in all this is. Why did you start building
[00:13:41] kta? Did you just wanna save API developers from writing boring SDKs, or is there a bigger business reason
[00:13:48] **Vincent Biret-1:** Both, like both actually. I think so, so for context both Darl and I work for Microsoft Graph, which is one of the largest rest APIs in the [00:14:00] world, both in terms of traffic and in terms of number of o of operations we support. I. To give you an idea, we have about 20,000 different unique operations in, on the V one endpoint.
[00:14:12] So that makes for 70 plus megabytes open API description for the whole thing.
[00:14:17] **Phil:** Good Lord
[00:14:18] **Vincent Biret-1:** yeah. And, and so we, we found ourselves in a situations where the traditional, the existing generators out there. Would not scale in terms of how fast we can generate things they would not scale in terms of naming conventions and other things that, that Darl mentioned earlier.
[00:14:36] Because they would try to generate clever methods name and that would not work at that scale of course. And they would also not allow. For more advanced scenarios like selecting the different endpoints you care about or not selecting the different operations you care about or not, and generating code just for those things.
[00:14:55] And, and so this is how we set out to, or this is why we set out to [00:15:00] build yet another claim code generator for REST APIs a couple of years ago with Darl to not only solve our business needs, but we built it in such a way that is not. Just for Microsoft Graph and and the Devex developer experience for Microsoft Graph, but also that it's really useful for the broader community and the industry at large.
[00:15:19] And hopefully people find it useful. Yeah.
[00:15:22] **Phil:** Oh, I see. So you just released the, you, you really, you've released the software so that other people can fix your bugs for you, and then you can say, well, open source,
[00:15:30] **Vincent Biret-1:** yeah, of course. Our personas is great. We get people work for us for free. No, but we, we, we are already collaborating with Red Hat on, on, on, on qda and, and we made a a key decision to ship a bunch of clients based off Qda for different, set of projects they have. We are also working with GitHub for their client experience as well there are a number of different players out there that not only, you know, get benefits from the open source, and the fact they can use it right off the bat, but they also contribute back to the project. So it's not [00:16:00] just, you know, us trying to offload book fixes to the community at this point. Right.
[00:16:03] So.
[00:16:04] **Darrel Miller:** So the other benefit of the approach that we've took, well there's, there's two benefits. There's, one is, as Vincent said, it's really big, our api, so nobody wants to use the entire API. So they want this ability to just project Code just for the parts of the API I they care about. But the other thing is a lot of our customers who are doing work with Microsoft Graph which stores like all your, your data for if you have an an M 365 license, so your email, your calendar, your contacts, all of that kind of stuff.
[00:16:33] A lot of it is integration scenarios. Either integration with internal systems or integration with other third party systems. And we found a lot of our customers were doing work where they are making two APIs talk to each other, which is where this consistency story starts to come into play. And we found there were a lot of our customers.
[00:16:55] Who just, who weren't using our SDKs. And our understanding [00:17:00] was yes, it's just another SDK that they have to learn. And this was, this was a big piece of feedback that we got from customers that people are just tired of going and learning yet another SDK. And they're like, I know how to make HTTB calls, and they'll just.
[00:17:14] Go do it themselves because they don't want to have to deal with multiple different SDKs. And so Kyoto was, was a reaction to that kind of scenario that our customers are running into and we need to go build them anyway. And Vincent and I had lots of conversations about how, how open source this would be.
[00:17:34] And it's taken us a little while to really convince our management that we should be building things that for customers who are not directly our customers, there's a lot of indirect benefits to shipping something that conforms very well to a standard like open API.
[00:17:49] **Phil:** that's, that's always a really hard. A hard one to push, isn't it? It's like, Hey, can we do loads of work that won't make us money directly , [00:18:00] because they're like, yeah, open source, the SDKs. That's great. You don't need to open source. The thing that makes the SDKs, I mean, how, how much extra work has gone in that's like how long has a piece of string, but like how, how much extra work has gone into making it something you could, you know, confidently release to the public versus something that was just fine for your needs.
[00:18:18] **Darrel Miller:** Yeah, that's
[00:18:19] **Vincent Biret-1:** Ooh, that's . a, that's a very good
[00:18:21] **Darrel Miller:** We don't wanna admit that publicly.
[00:18:24] **Vincent Biret-1:** yeah.
[00:18:27] **Darrel Miller:** So the, and and this is the challenge is it's usually when you run into, there's two scenarios. One is when you run into a problem that we have with our API. And there's an obvious easy shortcut that you can take that will solve it for us, but won't solve it for anybody. And you've gotta sell that to management as like, no, we can't take the shortcut because that won't deliver the bigger picture.
[00:18:50] And then there's the other scenario, the classic one that we keep running into is we'll call an API and they'll return a list of things as an array, adjacent array [00:19:00] and
[00:19:01] We don't ever do that in Microsoft Graph because we follow a set of O data conventions that says everything has to be an object at the root.
[00:19:08] And even collections are an object with a values property that contains an array. And so we'll keep going and we'll try it against an, oh damn, there's a scenario that doesn't exist in graph. And then we've gotta justify going, spending the time to go fix that. And our, our management are. Great. They have, they have come to terms with the fact that integration scenarios are an absolutely worthwhile thing, and we're starting to gain a lot more traction with other teams, either across Microsoft and across the industry, which again, helps to justify doing it.
[00:19:40] But yeah, it, it's a non-trivial amount of work and it requires continuous convincing of management that it is worthwhile doing.
[00:19:48] **Phil:** Hmm.
[00:19:48] **Vincent Biret-1:** Yeah. And, and I think also another part that we spend time on, which we wouldn't, if we had not open sourced the, the generator. Is the experience of a tool itself, like how [00:20:00] to well structure the commands and provide actionable feedback to users using the the generator. We also built a vs code extension, an an integration of the tool in VS code.
[00:20:11] All of that, of course, is not directly supporting our core business. But it brings broader adoption, it bring of the tool itself, and it brings more people to contribute to the tool. And, and that has largely paid off in case any of our managers are listening to it post ca, post cast. It has paid off already.
[00:20:30] Like for example, on the Java front red Hat. Has done tremendous work to get to a much better Java story in terms of generation. And, and if we had not open source for generator, if we had not, you know started building a community around, around Kda, we would not have gotten those benefits.
[00:20:48] Right. So.
[00:20:48] **Phil:** Ah, that is brilliant and I'm glad you threw that in there just for your managers in case they are listening. Slightly different topic. I mean, I don't think we've talked about Microsoft graph on it before and that that sounds [00:21:00] like a massive API that sounds blooming complicated. So is it a, a series of smaller APIs or is it just one massive API with loads of operations?
[00:21:09] And is there
[00:21:11] any difference between those two things really, apart from implementation
[00:21:14] **Darrel Miller:** hundreds of APIs. Produced by completely different organizations at Microsoft that in different languages, on different tech stacks, that all gets sewn together into kind of like a federa, like a GraphQL Federation data, a gateway, but using O data conventions instead. And this is one of our other interesting challenges.
[00:21:40] We actually Don't natively use open API to describe our APIs. It's ironic. It's like in some of the backends do use open API as they're building it, but then when they come to Microsoft Graph, they have to provide us with what's called A-C-S-D-L description, which is XML based format. And it should see some of the, the [00:22:00] more junior engineers as they join Microsoft and we tell 'em, yeah, you've gotta go and create this XML description of your API.
[00:22:07] **Phil:** Use this language that's like, it sucks and there isn't types and everything's like a Boolean or a string, and just
[00:22:12] **Darrel Miller:** there's lots of, there are lots of types, but, but, but it's, it, it has its challenges, but we're using that language. We can basically sew the the ap, all of these different APIs together into one coherent, description and
[00:22:26] provide a single surface area. And the technology problem is not the biggest thing that we solve.
[00:22:33] It's getting different parts of Microsoft's organization to talk to each other. I. Like how many different companies have you dealt with where you ask them to change your address and then you change your address and then you get a letter from them three weeks later that's going to the wrong address because they have your address stored 74 times.
[00:22:52] Well, we provide that role as a centralized place that says, no, there should only be one representation of a user's [00:23:00] profile photo. There should be only one representation of a user's contact information. And that's, that's kind of the, the business value of Microsoft Graph is it provides that one unified surface area to our customers for doing integrations with that data.
[00:23:16] **Phil:** That's awesome. So yeah, that's, that's the more interesting part I feel like of API governance that a lot of people don't get round to talking about. 'cause they haven't quite got that far yet. Like when, when people start trying to figure out. What API governance is and how to do it. Then it's mostly just like looking at pull requests and saying, don't do that.
[00:23:34] But it's, it's usually kind of focused on that's not the right naming and convention, that's not the right security thing. Like I, you know, I've, I've been pushing this for a long time 'cause I build tools that help you do that. But it's kind of getting people started with the idea of it. But the, the more interesting thing has always been trying to automate some of that dumber stuff, some of that more simple stuff.
[00:23:54] Patterns, standards, conventions, automate as much as you can so that you can then start to focus on [00:24:00] more domain modeling where you're like, yeah, don't, there's, there's already a dress over there. How are you gonna keep it in sync? Oh, you're gonna do a two-way sync, not on my watch son. You know, and, and just kind of just bounce in I bad ideas out of the entire ecosystem is, is far more interesting.
[00:24:16] So
[00:24:16] **Darrel Miller:** one of the most interesting conversations that we have with teams is when they show a user's name, and the first question we ask is, are you getting that from our central identity location? No. We, we, we keep a copy of it over here and we're like, oh, no, you don't, because people change their names. And it can do serious damage to people if they change their name. And that doesn't immediately get propagated throughout our entire system.
[00:24:47] And we get some funny looks from teams when we're like, oh, no, no, no. You've gotta go back and change your system. You can't store that. You can cache it for a short period of time, but no, you have to guarantee that you are going to sync that name before, [00:25:00] we'll, actually you ship the API.
[00:25:02] So it, it, it's interesting the areas we get into conversations about in what is, you know, API governance.
[00:25:09] **Phil:** Mm. Yeah. Awesome. I mean, we had the same, same problem that WeWork where users could live in multiple different systems and there was a, a three-way sync between, you know, two different monoliths that had roughly half the data that everything needed. And like Salesforce, I. That we also had a copy of Bloom and everything, and they all had different validation rules.
[00:25:29] So when you updated it in one place, it might make it to one or two of the other systems, but it might not . So you just had all this like, crazy different information and they all used like email as a unique key across all the systems, which would change and break everything. So yeah, trying to keep data in sync is.
[00:25:47] The dumbest part of the, kind of, was the hardest, most annoying and often dumbest part of microservice architecture. 'cause you're like, what if we split up all this code into multiple separate, distinct [00:26:00] things that then don't have access to anything and we'll just copy and paste everything everywhere and everything's worse.
[00:26:06] So you really need those very experienced people that can just sit there and say, yeah, not under my roof. Whenever someone triess to copy stuff,
[00:26:12] **Darrel Miller:** the response is, but, but, but we have to ship this next week.
[00:26:15] **Phil:** Yeah, it'll be okay this time. I promise it won't be like every other time. Cool. I mean, what other, what other troubles do you have corralling that many different APIs into one architecture?
[00:26:28] **Darrel Miller:** I mean, it, it's the reinventing of the wheel, which is no, please don't implement another RAC type security system that's specific to your particular . Product in the corner of the system. I think that's one of the other common things that we get into. I mean,
[00:26:45] **Phil:** Role-based authentication,
[00:26:48] **Darrel Miller:** role-based authentication, access control role-based access control.
[00:26:51] That's what our backs from.
[00:26:53] **Phil:** There we go,
[00:26:55] **Darrel Miller:** yeah, I think that's probably the other biggest area. The other [00:27:00] area is, is it is continues to surprise me. How a lot of people don't think of resource modeling and they just look at a URL as just a string of characters that has no necessary organizing. It's just a bunch of nice words that you string together.
[00:27:17] And they don't think of, you know, how are people going to go and use this API beyond the very specific scenario that . We are designing for today and we are shipping for a particular product. It's a case of no, you have to think about that customer who needs to get access to the data and they might want to do something different with the API than you would considered.
[00:27:43] How can we make that possible without generating a massive amount of work and building an infinitely capable machine that nobody is gonna use all a large part of the stuff that you built. So, I, think it's that just generalized design for serendipitous reuse [00:28:00] that's, that's hard for people to grok.
[00:28:01] **Phil:** Mm. Yeah. 'cause you, you either go the, this is just raw data, do with it what you will, maximum flexibility, no control. Or, or you kind of go like. These are the workflows we have really optimized for. And they're gonna be sick if you wanna do this thing with it, but if you wanna do anything else, it's awful.
[00:28:17] Yeah, that is the constant slating scale of terribleness. That is
[00:28:20] **Darrel Miller:** And you need to find some happy medium, somewhere in between. And make sure you also design it in a way that's gonna work well for the client code that we're going to project for you. Because sometimes you can design APIs that are like, oh, that's just not gonna work well in native programming languages.
[00:28:38] You know, like people who do lots of APIs that return very dynamic responses, or APIs that return raw. Oh yeah. Well, we don't wanna schematize this part of the API.
[00:28:48] **Phil:** Yeah, yeah. We've got an API that just like one endpoint, just like spits eye calendar format at you . And we've managed to get rid of that 'cause it was a bit gross and weird. But yeah, it's just like none of the tools are okay [00:29:00] because they're expecting Jason, maybe X ml. And then all of a sudden it's like, what the fuck is that
[00:29:06] So yeah, understand that. I mean, bringing it back to Kyoto for a second
[00:29:09] You just by way of wrapping up as well, could probably get into that time. But obviously you guys are doing such a wonderful job at making Microsoft Graph be very consistent and therefore any You would expect if, if the open API is fairly consistent and follows patterns and the APIs are fairly consistent and follow patterns, then those SDKs are gonna be pretty, you know, standard with each other.
[00:29:35] But for other. People like the example of a client who is talking to 10 different APIs made by 10 different people, and you've cotified a lot of them.
[00:29:45] How much does different open API affect the kind of consistency of the SDK? Well, the API client code that is then generated from it.
[00:29:55] **Vincent Biret-1:** I would say not that much because a, again, a as, as Darryl mentioned at the beginning [00:30:00] one one of the key designs aspect is that the only opinionated choices we've made were around HGTP and the conventions and whatnot, and we stuck to as close as H GTT P conventions as. As we could and, and, and for example, if you take the fluent API surface that we project for you to call the different operations and, and points and whatnot.
[00:30:19] One the way it is structured is that it. follows the path segmentation of your API. 'cause not only it's easier to map mentally to know, oh yeah, this method or this code path on in my code maps to that operation on the API, but also it allows us to. The structure, the code we generate and potentially avoid any conflicts if you have things with different names, but at with the same names, but at different levels and, and, and whatnot.
[00:30:49] So now if you look at different descriptions and different APIs, even though. Their domains are different, even though the terms they're using are different. [00:31:00] The organization of affluent API Surface and the models and the other conventions are gonna be the same. They are going to be mostly based on the HT P conventions.
[00:31:10] And there is gonna be another layer of conventions added by, by Qda. But it, we try to keep it as thin as possible. So it's, it's super easy for you to mentally map your way through the different clients we generate here.
[00:31:22] **Phil:** Brilliant. Alright, well I'm gonna recommend that all you listeners go and have a look at kta because you might think you're being clever by just doing a, like a file, get contents and bunging, A URL. And then just like hope that thing works. But every time you, you'd kind of directly just write your own little SDK, you've just built a bad SDK and it's brittle and there's a lot of things that can go wrong and it's gonna be different every time.
[00:31:52] And you don't have the ability to wrap that in beautiful, fantastic middlewares that can, can chuck in timeout logic consistently, easily, that [00:32:00] can chuck in caching logic consistently, easily. So yeah, if you have a bunch of like direct dependencies that you've written yourself. Delete those and maybe Kyoto can be the way to replace them.
[00:32:11] Thank you very much Vincent and Darryl for coming on and I think, I think this has actually recorded the whole way through, so I think we're okay. I think we did a podcast
[00:32:19] **Vincent Biret-1:** Hopefully, yeah. Thank you so much for having us.
[00:32:23] **Phil:** Cheers guys.
[00:32:24] **Vincent Biret-1:** Bye.