WEBVTT NOTE This file was generated by Descript 00:00:00.000 --> 00:00:03.060 Phil: Hello everybody, and welcome to another episode of APIs. 00:00:03.060 --> 00:00:04.470 You won't hate this time. 00:00:04.470 --> 00:00:07.470 It's just me, Phil, with no mic. 00:00:07.770 --> 00:00:09.090 I, I don't know what I'm doing. 00:00:09.090 --> 00:00:11.850 He, there's a lot of buttons on my screen and I'm a little bit scared and 00:00:11.850 --> 00:00:13.865 confused, but I I think it's recording. 00:00:13.865 --> 00:00:17.595 I think this is a podcast and thankfully to keep me company with 00:00:17.625 --> 00:00:19.155 this world of confusing options. 00:00:19.485 --> 00:00:23.115 I have two wonderful guests Darryl Miller, who has been on the show 00:00:23.115 --> 00:00:25.874 before, and a new guest Vincent Bere. 00:00:26.505 --> 00:00:27.165 Did I get that right? 00:00:27.410 --> 00:00:27.609 Vincent Biret-1: Yes. 00:00:28.064 --> 00:00:28.484 Perfect. 00:00:29.360 --> 00:00:29.990 Phil: Fantastic. 00:00:29.990 --> 00:00:31.710 Welcome both start with you Vincent. 00:00:31.830 --> 00:00:34.230 Would you like to just tell everyone who you are? 00:00:34.985 --> 00:00:35.435 Vincent Biret-1: Yeah, sure. 00:00:35.735 --> 00:00:36.425 Hi everyone. 00:00:36.425 --> 00:00:37.115 Nice to meet you. 00:00:37.205 --> 00:00:39.005 Nice to meet you in person. 00:00:39.035 --> 00:00:41.105 Making our quotes at the same time, Phil. 00:00:41.145 --> 00:00:43.235 And I am based out of Montreal. 00:00:43.235 --> 00:00:47.214 I'm a principal developer on the Microsoft Graph client experience team. 00:00:47.605 --> 00:00:50.515 And I work a lot with Darl on the day-to-Day basis. 00:00:51.015 --> 00:00:51.495 Phil: Nice. 00:00:51.500 --> 00:00:53.055 And Darryl, who, who are you? 00:00:53.515 --> 00:00:57.170 Darrel Miller: I work at Microsoft as an API architect on 00:00:57.170 --> 00:00:59.169 the Microsoft graph and in my. 00:00:59.425 --> 00:01:00.355 Spare time. 00:01:00.355 --> 00:01:03.775 I spent some time working on the open API specification and a few 00:01:03.775 --> 00:01:06.874 IETF HTP related specifications. 00:01:06.874 --> 00:01:07.534 Phil: Nice. 00:01:07.744 --> 00:01:11.945 And I'm really glad that you could both come today to talk all about open AI and 00:01:11.945 --> 00:01:13.445 the latest happenings with Sam Altman. 00:01:14.095 --> 00:01:15.295 Darrel Miller: Our lips are sealed. 00:01:15.595 --> 00:01:16.045 We can say nothing. 00:01:16.684 --> 00:01:16.894 Phil: Okay. 00:01:18.149 --> 00:01:21.359 Yeah, no, I do often confuse open AI and open API. 00:01:21.359 --> 00:01:23.320 So yeah, let's, let's talk about that one. 00:01:23.859 --> 00:01:27.489 So you guys have made with a lot, a lot of other people involved. 00:01:27.489 --> 00:01:31.289 I'm sure you've made another SDK tool that's a little bit 00:01:31.294 --> 00:01:32.669 different from some of the others. 00:01:32.769 --> 00:01:35.919 But first we have to ask ourselves, what is an SDK? 00:01:36.280 --> 00:01:37.509 What is this tool all about? 00:01:38.009 --> 00:01:41.814 Darrel Miller: Well, I, I, first of all, I wanna say we, we are trying not 00:01:41.814 --> 00:01:44.394 to call it an SDK generator because. 00:01:45.024 --> 00:01:50.244 SDK is a term comes with a lot of baggage and is confusing and people have different 00:01:50.664 --> 00:01:56.274 understandings of what it means, and so we like to call it an API Client Code 00:01:56.274 --> 00:02:00.834 generator, which is a bit more of a mouthful, but it is a bit more explicit. 00:02:01.224 --> 00:02:02.049 Vincent, tell 'em what it does. 00:02:02.615 --> 00:02:06.609 Vincent Biret-1: Well, it will for any rest, API that you have, that has an 00:02:06.609 --> 00:02:12.410 open API description, it will take that and generate client code to call your. 00:02:12.965 --> 00:02:19.780 Rest API with fluent API in the code and models, and it'll handle ization, ization 00:02:19.915 --> 00:02:24.444 and a number of different aspects for you so you can get going calling your API and 00:02:24.449 --> 00:02:28.855 you focus on what matters, writing the code for your application and not just, 00:02:28.855 --> 00:02:32.784 you know, handling ization digitalization and, and nitty gritty details like that. 00:02:33.634 --> 00:02:34.054 Phil: Brilliant. 00:02:34.144 --> 00:02:38.775 And so we've had, we've had a couple of cool, a couple of podcasts about kind of 00:02:38.775 --> 00:02:41.835 SDK generators, client stuff in the past. 00:02:41.840 --> 00:02:46.234 I think depends on what happens between recording and actually publishing stuff. 00:02:46.234 --> 00:02:48.064 But like one of the last ones was about that. 00:02:48.344 --> 00:02:53.314 We've talked about Fern in the past and we've talked about amatic and so. 00:02:54.709 --> 00:02:57.229 Now we're talking about Kyo, not 00:02:57.394 --> 00:02:57.574 Vincent Biret-1: Yes. 00:02:58.339 --> 00:03:00.739 Phil: KTA from Microsoft and. 00:03:01.474 --> 00:03:02.404 It's a little bit different. 00:03:02.584 --> 00:03:04.294 I noticed that you are trying to take the approach. 00:03:04.354 --> 00:03:09.214 I mean, some of these SDK generation tools kind of come across like you 00:03:09.214 --> 00:03:13.144 are the API development team and you don't have time to be right in a Go 00:03:13.149 --> 00:03:17.614 library and our library and other languages that you might not know. 00:03:17.734 --> 00:03:19.534 So just run this command. 00:03:19.539 --> 00:03:22.084 And then tadda, it's been published and all different, A 00:03:22.084 --> 00:03:23.554 PA developers use all different. 00:03:23.944 --> 00:03:27.664 SDK generators and some they write by hand and some they use different tools. 00:03:27.844 --> 00:03:30.904 And so everyone's A-P-I-S-D-K looks a little bit different. 00:03:31.264 --> 00:03:35.554 It seems like you folks were going for a slightly different approach of kind 00:03:35.554 --> 00:03:39.224 of you're an API client and you could, you could grab a bunch of different 00:03:39.254 --> 00:03:43.244 open APIs from different people and generate a whole bunch of SDK well 00:03:43.314 --> 00:03:49.254 API client libraries yourself so that you can work with other people's APIs. 00:03:49.374 --> 00:03:51.234 Is that about right or have I just butchered it? 00:03:52.269 --> 00:03:52.989 Vincent Biret-1: No, it's perfect. 00:03:52.989 --> 00:03:53.319 Actually. 00:03:53.319 --> 00:03:56.699 You could, you could do the podcast on, on your own by yourself. 00:03:56.699 --> 00:03:58.619 You already know everything here, but 00:03:58.619 --> 00:03:58.919 Phil: later. 00:03:59.519 --> 00:04:00.179 Vincent Biret-1: yeah, exactly. 00:04:00.209 --> 00:04:02.304 I'm, I'm gonna grab a coffee instead, but yeah. 00:04:02.314 --> 00:04:03.544 The idea is to. 00:04:04.044 --> 00:04:09.654 As you can still use Kda to as an API producer to put SDKs out 00:04:09.654 --> 00:04:13.424 there to reuse your own term and, and offer those to your customers. 00:04:13.424 --> 00:04:16.814 You can perfectly do that with Kda of course, but we set out on a 00:04:16.814 --> 00:04:18.404 different approach, as you said, to. 00:04:18.784 --> 00:04:24.064 Make sure that you have a consistent experience across multiple APIs. 00:04:24.334 --> 00:04:28.904 More and more nowadays projects or applications have to integrate between 00:04:29.214 --> 00:04:34.404 multiple APIs, multiple vendors that we use, and having to, you know, find out 00:04:34.404 --> 00:04:38.304 whether or not they have a package for you in your language first, and then 00:04:38.334 --> 00:04:42.324 learn the semantics and the different aspects of this specific package 00:04:42.324 --> 00:04:44.274 for each and every API you consume. 00:04:44.554 --> 00:04:48.424 Potentially get into, de dependencies, conflicts and having to resolve 00:04:48.424 --> 00:04:50.494 that, which is always awesome to do. 00:04:51.069 --> 00:04:54.339 We, we really want to get rid of all that, that experience for, for 00:04:54.339 --> 00:04:58.419 people and instead say, all right, you have your API consuming tool and 00:04:58.419 --> 00:04:59.979 API discovery tool for that matter. 00:04:59.979 --> 00:05:04.104 Because KRA also offers search and discovery commands and, and, and 00:05:04.104 --> 00:05:07.764 features as well to allow you to discover public APIs out there. 00:05:08.034 --> 00:05:11.424 And then you pick and choose not only the different APIs you're interested 00:05:11.424 --> 00:05:14.814 in from the different vendors or partners or whatnot, but you can 00:05:14.814 --> 00:05:17.174 even get down to choosing a specific. 00:05:17.314 --> 00:05:19.624 Operation under specific endpoint. 00:05:19.624 --> 00:05:23.734 So now you get a client that is very specific to you, what you actually 00:05:23.734 --> 00:05:27.994 need to do, and you get this consistent experience code writing experience 00:05:27.999 --> 00:05:30.634 across multiple API providers. 00:05:30.689 --> 00:05:31.169 Darrel Miller: Yes. 00:05:31.439 --> 00:05:34.799 So Phil, the problem is developers have opinions. 00:05:35.519 --> 00:05:40.019 We all have opinions about HTTP and when people go and say, Hey, 00:05:40.019 --> 00:05:44.879 I need to build an SDK for my API, so that everybody will use it. 00:05:44.879 --> 00:05:48.149 So PHP developers will use it and Ruby developers will use it. 00:05:48.449 --> 00:05:53.459 We all go and build these libraries that say, well, this is the way that 00:05:53.909 --> 00:05:59.639 an H-T-P-A-P-I should be projected into into the native programming language. 00:05:59.969 --> 00:06:03.029 And the problem with having every API provider. 00:06:03.494 --> 00:06:06.704 Have their opinions on how their API should be projected. 00:06:07.004 --> 00:06:13.244 It means that poor API consumer now has to deal with everybody's opinions 00:06:13.274 --> 00:06:15.074 of every API that they go and talk to. 00:06:16.064 --> 00:06:20.054 So the Kyoto approach is, well if you can put it with our opinion, the 00:06:20.054 --> 00:06:25.274 Kyoto opinion on how you project H HB APIs, you can then use K for every 00:06:25.274 --> 00:06:28.874 API that you want to talk to and you only have to learn how to do it once. 00:06:29.444 --> 00:06:31.124 And we are. 00:06:31.784 --> 00:06:39.149 We are as un opinionated other than . Having HTTP opinions, like we don't take 00:06:39.209 --> 00:06:42.569 the HP methods and say, well, usually when it's a post, it means create. 00:06:42.569 --> 00:06:44.879 Therefore we're gonna use the create verb on a method. 00:06:45.059 --> 00:06:48.299 We just tell you, there's your post, here's how you put HP headers in. 00:06:48.479 --> 00:06:50.249 Here's how you put query parameters in. 00:06:50.399 --> 00:06:52.139 Here's how you format a request body. 00:06:52.684 --> 00:06:56.524 You understand the uniform interface, we're just translating it into your 00:06:56.524 --> 00:07:00.454 programming language, and we'll deal with the really annoying stuff, like figuring 00:07:00.454 --> 00:07:05.224 out how to present in code parameters in a query string, and how to use a UI template 00:07:05.224 --> 00:07:06.034 to construct. 00:07:06.274 --> 00:07:06.664 Yeah, yeah. 00:07:06.664 --> 00:07:08.194 All those ugly things. 00:07:08.504 --> 00:07:11.024 That those edge cases of HP we take care of. 00:07:11.534 --> 00:07:16.274 But you take our projected code, which people have said, yeah, 00:07:16.274 --> 00:07:19.634 this is not how, this is not an optimum experience for this API. 00:07:19.634 --> 00:07:22.424 And I'm like, yeah, I know it's not an optimum experience for the API 00:07:22.634 --> 00:07:27.164 put an adapter in front of it and create a perfect experience for your. 00:07:27.539 --> 00:07:31.649 A particular application that you're building and use it as a 00:07:31.649 --> 00:07:35.609 mocking interface and then hide our projected code behind it. 00:07:35.699 --> 00:07:37.619 You're never gonna get beautiful projected code. 00:07:37.859 --> 00:07:40.949 And we keep trying to do that based on a whole bunch of people's 00:07:40.949 --> 00:07:44.699 opinions, and you'll never get everybody to agree on what the 00:07:44.699 --> 00:07:47.069 perfect projection of an HT P API is. 00:07:48.644 --> 00:07:49.544 Phil: Yeah, absolutely. 00:07:49.544 --> 00:07:52.424 I mean in, in most kind of worlds of frameworks, there's 00:07:52.424 --> 00:07:53.384 a whole bunch of different. 00:07:53.729 --> 00:07:56.189 Coding patterns that people prefer. 00:07:56.459 --> 00:07:58.499 And then, you know happens in Laravel all the time. 00:07:58.499 --> 00:08:02.669 Everyone goes from repository, pattern, event bust, all these different things 00:08:02.669 --> 00:08:05.489 and like different different naming conventions and everything else. 00:08:05.489 --> 00:08:09.209 So yeah, certain communities can't be consistent with themselves and 00:08:09.209 --> 00:08:12.179 even if they do reach consistency at any point, it changes. 00:08:12.179 --> 00:08:14.689 So it can be really hard to try and make something that, 00:08:14.694 --> 00:08:16.009 that, that makes everyone happy. 00:08:16.009 --> 00:08:23.509 And I saw Remember, I remember seeing you give a talk at one of God knows how many 00:08:23.509 --> 00:08:26.519 conferences a couple of years ago about 00:08:27.094 --> 00:08:27.314 Darrel Miller: The 00:08:27.599 --> 00:08:29.594 kit back in SDK was what it was called. 00:08:31.169 --> 00:08:32.129 Phil: yeah, that's the one. 00:08:32.129 --> 00:08:34.199 It was like, yeah, how to make good SDKs or whatever. 00:08:34.199 --> 00:08:36.089 And a lot of it was talking about Middlewares. 00:08:36.279 --> 00:08:40.719 Do you still have a bunch of middleware logic in Kyo Did you manage to get that in 00:08:40.869 --> 00:08:41.499 Darrel Miller: Yes, indeed. 00:08:41.499 --> 00:08:43.089 It's all built on that patent. 00:08:43.359 --> 00:08:46.389 Vincent, you wanna go into a bit of the details of the underlying bits? 00:08:47.944 --> 00:08:48.284 Vincent Biret-1: Sure. 00:08:48.464 --> 00:08:49.864 So the. 00:08:51.404 --> 00:08:57.004 code we generate only relies on a set of abstractions that we publish, of 00:08:57.004 --> 00:09:02.294 course which means that as soon as we, you generate a client for an API 00:09:02.384 --> 00:09:06.344 and that you pull the abstractions package, you'll be able to build your 00:09:06.374 --> 00:09:08.224 project solution application whatever. 00:09:08.584 --> 00:09:10.624 It won't do anything, of course, because you'll be missing 00:09:10.624 --> 00:09:13.024 a bunch of implementations, but at least it will build. 00:09:13.194 --> 00:09:18.384 And then for those attractions that are for executing the HTP request 00:09:18.434 --> 00:09:22.424 serializing, decentralizing, and the authentications aspects as well. 00:09:23.169 --> 00:09:26.789 We provide default implementations that you're more than happy more 00:09:26.789 --> 00:09:31.159 than welcome to use and import in your project or your application. 00:09:31.459 --> 00:09:34.549 But if you're not happy with those because you need a different ization 00:09:34.549 --> 00:09:39.429 format or you prefer a different library, for example you can re-implement those 00:09:39.429 --> 00:09:41.499 abstractions and, and swap those away. 00:09:42.039 --> 00:09:46.599 And if we focus on HTP and executing the request one of the abstractions 00:09:46.599 --> 00:09:52.089 we have is the request adapter and we have a default implementation that also 00:09:52.089 --> 00:09:56.529 provides a bunch of middlewares for retry handling, compression handling, 00:09:56.534 --> 00:10:00.579 redirection handling, and a different of of things set of our things as well. 00:10:00.939 --> 00:10:04.279 And, and now if you want to add custom behavior to that, 00:10:04.279 --> 00:10:05.929 you can of course just write. 00:10:05.974 --> 00:10:06.964 Additional middleware. 00:10:06.964 --> 00:10:11.074 If you're happy with a client of choice, we've selected, or if you're not happy 00:10:11.074 --> 00:10:14.174 at all with a client, which typical client we've selected you can of course 00:10:14.204 --> 00:10:18.109 reimplement the whole interface and, and, and, and do whatever you prefer here, but. 00:10:19.264 --> 00:10:19.924 Phil: That's brilliant. 00:10:20.134 --> 00:10:20.344 Yeah. 00:10:20.519 --> 00:10:24.869 'cause middlewares are just increasingly becoming the thing I'm the most interested 00:10:24.869 --> 00:10:27.889 in when it comes to . Pretty much any part of working with APIs, right? 00:10:27.919 --> 00:10:33.229 'cause the, the actual business logic of, of most APIs is quite small. 00:10:33.439 --> 00:10:35.869 It's usually like, oh, we're gonna call a model and add some 00:10:35.874 --> 00:10:37.189 stuff and do a bit of validation. 00:10:37.189 --> 00:10:40.159 But that's like three lines of code and it punts it off to a whatever 00:10:40.549 --> 00:10:42.119 service some sort of service class. 00:10:42.479 --> 00:10:48.639 But the most important, like API logic, Both, both client side and server side. 00:10:48.669 --> 00:10:52.939 Most stuff can be implemented as middlewares and everything from you 00:10:52.939 --> 00:10:55.009 know, rate limiting and caching. 00:10:55.009 --> 00:10:58.629 And I was just doing a whole series of posts about like item potency, 00:10:58.629 --> 00:11:00.219 keys and, and things like that. 00:11:00.219 --> 00:11:04.509 And both the client and the server can just kind of install one package and 00:11:04.509 --> 00:11:06.669 just register it and, and, and use that. 00:11:06.979 --> 00:11:10.099 So is there a bunch of like pre-built stuff? 00:11:10.424 --> 00:11:14.174 For Kyoto, you like, do you have support for item parent C keys? 00:11:14.174 --> 00:11:14.834 'cause that'd be fun. 00:11:15.089 --> 00:11:17.679 Vincent Biret-1: Now, so this one specifically we don't have but it'll 00:11:17.679 --> 00:11:22.749 be very easy for you for any language we provide and support today to say I 00:11:22.749 --> 00:11:26.859 wanna add support for potency, keys, and write up a middleware and add it 00:11:26.864 --> 00:11:30.759 to your chain and use the same exact client you just generated with qal. 00:11:31.069 --> 00:11:32.389 You don't need to change it for generated. 00:11:32.564 --> 00:11:34.484 Code at all or touch any of that. 00:11:34.794 --> 00:11:37.644 You just need to add your crosscutting concern, implementation 00:11:37.704 --> 00:11:38.694 and, and, and you're good to go. 00:11:38.694 --> 00:11:43.139 And, and better than that we work a lot in the open as an open source project, so 00:11:43.379 --> 00:11:46.829 if you feel like what you've built will be valuable to others, we'll be more than, 00:11:46.829 --> 00:11:52.019 well, happy to see pull requests coming our way and, and, and, you know, make 00:11:52.199 --> 00:11:54.089 others benefit from your hard work here. 00:11:54.089 --> 00:11:54.509 So, Yeah. 00:11:55.114 --> 00:11:56.014 Darrel Miller: Did you notice? 00:11:56.254 --> 00:11:57.034 Phil: sounds like it does. 00:11:57.184 --> 00:12:00.844 Darrel Miller: Did, did you notice Phil in the latest update to the item 00:12:00.844 --> 00:12:04.024 potency, item potency, spec in the ITF? 00:12:04.024 --> 00:12:09.094 That hasn't quite . Been gone through last call yet there was some wording 00:12:09.094 --> 00:12:14.254 that was changed that now allows a client to send an item potency key, 00:12:14.584 --> 00:12:17.254 even if they don't know whether the server supports it or not. 00:12:18.844 --> 00:12:18.964 And 00:12:18.969 --> 00:12:20.884 this, this came from browser vendors. 00:12:20.974 --> 00:12:24.634 cause the browser vendors were like, Hey, it would be really handy when we're. 00:12:26.194 --> 00:12:30.844 To send an item potency key in the hope that maybe the server supports it. 00:12:31.294 --> 00:12:34.264 And then if a server does, then, then, then, cool. 00:12:34.804 --> 00:12:37.564 So you don't need this pre-negotiated contract and Oh, 00:12:37.564 --> 00:12:41.194 I know that the server implements it, therefore I'm gonna send it. 00:12:41.199 --> 00:12:46.744 You can just always send it on a post if, if you want that post to be ideally, 00:12:47.239 --> 00:12:48.349 Phil: that makes a lot of sense. 00:12:48.439 --> 00:12:51.979 I mean, they already kind of take a huge amount of guesses at various cash in logic 00:12:51.979 --> 00:12:53.839 and, and do a bunch of things for you. 00:12:53.989 --> 00:12:56.509 And like most browsers will already say like, are you sure 00:12:56.514 --> 00:12:57.769 you want to refresh this page? 00:12:57.769 --> 00:12:59.089 'cause that means you're gonna. 00:12:59.944 --> 00:13:01.384 You know, resend this data. 00:13:01.654 --> 00:13:04.384 Now they can change that to be like, are you sure you wanna refresh this? 00:13:04.384 --> 00:13:06.784 Because it might resend the thing. 00:13:07.114 --> 00:13:09.664 Or, but if they've had like good responses and they know that it 00:13:09.664 --> 00:13:12.544 does support it, then they can be like, yeah, you can refresh this and 00:13:12.544 --> 00:13:13.594 not have to show you the message. 00:13:13.894 --> 00:13:14.584 So that's pretty handy. 00:13:14.584 --> 00:13:18.814 I cool Bit of a tangent on item potency keys there, but there's a blog post. 00:13:18.994 --> 00:13:19.954 I'll tell you all about it. 00:13:20.044 --> 00:13:21.904 I wrote one for the APIs. 00:13:21.904 --> 00:13:22.624 You won't hate blog. 00:13:22.624 --> 00:13:26.194 That was mostly just me complaining about getting charged three times for a hotel. 00:13:26.414 --> 00:13:29.894 But then I wrote another one for HT TP toolkit on their 00:13:29.894 --> 00:13:31.514 blog, which is actually useful. 00:13:31.694 --> 00:13:33.134 So go and check that one out. 00:13:33.914 --> 00:13:38.534 Now that I'm done plugging my stuff on my stuff, I am curious what 00:13:38.534 --> 00:13:40.274 Microsoft's interest in all this is. 00:13:40.274 --> 00:13:41.534 Why did you start building 00:13:41.804 --> 00:13:42.464 kta? 00:13:42.494 --> 00:13:46.544 Did you just wanna save API developers from writing boring SDKs, or is 00:13:46.549 --> 00:13:47.564 there a bigger business reason 00:13:48.099 --> 00:13:50.589 Vincent Biret-1: Both, like both actually. 00:13:50.639 --> 00:13:56.859 I think so, so for context both Darl and I work for Microsoft Graph, which is one 00:13:56.859 --> 00:14:02.439 of the largest rest APIs in the world, both in terms of traffic and in terms 00:14:02.439 --> 00:14:05.139 of number of o of operations we support. 00:14:05.859 --> 00:14:05.889 I. 00:14:05.889 --> 00:14:10.894 To give you an idea, we have about 20,000 different unique operations 00:14:10.954 --> 00:14:12.154 in, on the V one endpoint. 00:14:12.724 --> 00:14:17.179 So that makes for 70 plus megabytes open API description for the whole thing. 00:14:17.695 --> 00:14:18.225 Phil: Good Lord 00:14:18.469 --> 00:14:19.099 Vincent Biret-1: yeah. 00:14:19.459 --> 00:14:23.839 And, and so we, we found ourselves in a situations where the traditional, 00:14:24.049 --> 00:14:25.639 the existing generators out there. 00:14:26.279 --> 00:14:31.080 Would not scale in terms of how fast we can generate things they would not scale 00:14:31.199 --> 00:14:36.029 in terms of naming conventions and other things that, that Darl mentioned earlier. 00:14:36.459 --> 00:14:40.480 Because they would try to generate clever methods name and that would 00:14:40.485 --> 00:14:42.250 not work at that scale of course. 00:14:42.430 --> 00:14:44.340 And they would also not allow. 00:14:45.485 --> 00:14:49.175 For more advanced scenarios like selecting the different endpoints you 00:14:49.180 --> 00:14:53.105 care about or not selecting the different operations you care about or not, and 00:14:53.105 --> 00:14:55.355 generating code just for those things. 00:14:55.660 --> 00:15:00.545 And, and so this is how we set out to, or this is why we set out to build yet 00:15:00.545 --> 00:15:05.865 another claim code generator for REST APIs a couple of years ago with Darl to 00:15:05.925 --> 00:15:10.065 not only solve our business needs, but we built it in such a way that is not. 00:15:10.105 --> 00:15:14.094 Just for Microsoft Graph and and the Devex developer experience 00:15:14.094 --> 00:15:18.225 for Microsoft Graph, but also that it's really useful for the broader 00:15:18.225 --> 00:15:19.725 community and the industry at large. 00:15:19.725 --> 00:15:21.745 And hopefully people find it useful. 00:15:21.745 --> 00:15:21.865 Yeah. 00:15:22.855 --> 00:15:23.515 Phil: Oh, I see. 00:15:23.515 --> 00:15:26.635 So you just released the, you, you really, you've released the software so that 00:15:26.635 --> 00:15:29.815 other people can fix your bugs for you, and then you can say, well, open source, 00:15:30.205 --> 00:15:30.895 Vincent Biret-1: yeah, of course. 00:15:30.895 --> 00:15:31.825 Our personas is great. 00:15:31.825 --> 00:15:33.205 We get people work for us for free. 00:15:33.205 --> 00:15:38.065 No, but we, we, we are already collaborating with Red Hat on, on, on, 00:15:38.065 --> 00:15:43.450 on qda and, and we made a a key decision to ship a bunch of clients based off Qda 00:15:43.820 --> 00:15:46.040 for different, set of projects they have. 00:15:46.310 --> 00:15:50.020 We are also working with GitHub for their client experience as well there are a 00:15:50.020 --> 00:15:53.410 number of different players out there that not only, you know, get benefits 00:15:53.415 --> 00:15:57.400 from the open source, and the fact they can use it right off the bat, but they 00:15:57.400 --> 00:15:59.020 also contribute back to the project. 00:15:59.020 --> 00:16:02.570 So it's not just, you know, us trying to offload book fixes 00:16:02.575 --> 00:16:03.530 to the community at this point. 00:16:03.535 --> 00:16:03.680 Right. 00:16:03.680 --> 00:16:03.860 So. 00:16:04.010 --> 00:16:06.890 Darrel Miller: So the other benefit of the approach that we've took, 00:16:06.890 --> 00:16:07.940 well there's, there's two benefits. 00:16:07.940 --> 00:16:11.690 There's, one is, as Vincent said, it's really big, our api, so 00:16:11.750 --> 00:16:13.550 nobody wants to use the entire API. 00:16:14.210 --> 00:16:17.560 So they want this ability to just project Code just for the parts 00:16:17.560 --> 00:16:18.730 of the API I they care about. 00:16:19.330 --> 00:16:22.750 But the other thing is a lot of our customers who are doing work with 00:16:22.750 --> 00:16:28.160 Microsoft Graph which stores like all your, your data for if you have an an M 00:16:28.160 --> 00:16:33.290 365 license, so your email, your calendar, your contacts, all of that kind of stuff. 00:16:33.720 --> 00:16:35.550 A lot of it is integration scenarios. 00:16:36.255 --> 00:16:39.135 Either integration with internal systems or integration with 00:16:39.135 --> 00:16:40.545 other third party systems. 00:16:40.875 --> 00:16:46.185 And we found a lot of our customers were doing work where they are 00:16:46.185 --> 00:16:50.325 making two APIs talk to each other, which is where this consistency 00:16:50.325 --> 00:16:52.515 story starts to come into play. 00:16:52.825 --> 00:16:54.980 And we found there were a lot of our customers. 00:16:55.575 --> 00:16:58.035 Who just, who weren't using our SDKs. 00:16:58.475 --> 00:17:03.335 And our understanding was yes, it's just another SDK that they have to learn. 00:17:03.335 --> 00:17:07.115 And this was, this was a big piece of feedback that we got from customers 00:17:07.120 --> 00:17:10.835 that people are just tired of going and learning yet another SDK. 00:17:10.835 --> 00:17:13.955 And they're like, I know how to make HTTB calls, and they'll just. 00:17:14.140 --> 00:17:17.860 Go do it themselves because they don't want to have to deal 00:17:17.980 --> 00:17:19.600 with multiple different SDKs. 00:17:19.600 --> 00:17:24.250 And so Kyoto was, was a reaction to that kind of scenario that our 00:17:24.250 --> 00:17:27.960 customers are running into and we need to go build them anyway. 00:17:28.290 --> 00:17:32.610 And Vincent and I had lots of conversations about how, how 00:17:32.610 --> 00:17:33.985 open source this would be. 00:17:34.050 --> 00:17:38.520 And it's taken us a little while to really convince our management that we should 00:17:38.520 --> 00:17:41.970 be building things that for customers who are not directly our customers, 00:17:42.420 --> 00:17:47.380 there's a lot of indirect benefits to shipping something that conforms 00:17:47.380 --> 00:17:49.875 very well to a standard like open API. 00:17:49.875 --> 00:17:51.405 Phil: that's, that's always a really hard. 00:17:52.410 --> 00:17:53.640 A hard one to push, isn't it? 00:17:53.640 --> 00:17:58.230 It's like, Hey, can we do loads of work that won't make us money 00:17:58.230 --> 00:18:01.860 directly , because they're like, yeah, open source, the SDKs. 00:18:01.860 --> 00:18:02.550 That's great. 00:18:02.550 --> 00:18:03.420 You don't need to open source. 00:18:03.420 --> 00:18:07.470 The thing that makes the SDKs, I mean, how, how much extra work has gone in 00:18:07.540 --> 00:18:10.570 that's like how long has a piece of string, but like how, how much extra 00:18:10.570 --> 00:18:14.800 work has gone into making it something you could, you know, confidently 00:18:14.800 --> 00:18:18.520 release to the public versus something that was just fine for your needs. 00:18:18.520 --> 00:18:19.155 Darrel Miller: Yeah, that's 00:18:19.475 --> 00:18:21.155 Vincent Biret-1: Ooh, that's . a, that's a very good 00:18:21.615 --> 00:18:23.265 Darrel Miller: We don't wanna admit that publicly. 00:18:24.780 --> 00:18:25.070 Vincent Biret-1: yeah. 00:18:27.195 --> 00:18:30.885 Darrel Miller: So the, and and this is the challenge is it's usually when 00:18:30.885 --> 00:18:32.895 you run into, there's two scenarios. 00:18:32.895 --> 00:18:35.685 One is when you run into a problem that we have with our API. 00:18:36.660 --> 00:18:41.190 And there's an obvious easy shortcut that you can take that will solve it 00:18:41.190 --> 00:18:42.900 for us, but won't solve it for anybody. 00:18:43.290 --> 00:18:46.410 And you've gotta sell that to management as like, no, we can't 00:18:46.415 --> 00:18:50.100 take the shortcut because that won't deliver the bigger picture. 00:18:50.520 --> 00:18:53.400 And then there's the other scenario, the classic one that we keep 00:18:53.400 --> 00:18:57.910 running into is we'll call an API and they'll return a list of things 00:18:57.910 --> 00:19:01.060 as an array, adjacent array and 00:19:01.435 --> 00:19:04.585 We don't ever do that in Microsoft Graph because we follow a set of O 00:19:04.585 --> 00:19:07.885 data conventions that says everything has to be an object at the root. 00:19:08.065 --> 00:19:12.725 And even collections are an object with a values property that contains an array. 00:19:13.085 --> 00:19:17.045 And so we'll keep going and we'll try it against an, oh damn, there's a 00:19:17.050 --> 00:19:19.295 scenario that doesn't exist in graph. 00:19:19.445 --> 00:19:22.145 And then we've gotta justify going, spending the time to go fix that. 00:19:22.415 --> 00:19:24.275 And our, our management are. 00:19:24.525 --> 00:19:25.035 Great. 00:19:25.035 --> 00:19:30.185 They have, they have come to terms with the fact that integration scenarios 00:19:30.185 --> 00:19:34.325 are an absolutely worthwhile thing, and we're starting to gain a lot more 00:19:34.325 --> 00:19:37.805 traction with other teams, either across Microsoft and across the industry, 00:19:37.805 --> 00:19:40.735 which again, helps to justify doing it. 00:19:40.740 --> 00:19:46.285 But yeah, it, it's a non-trivial amount of work and it requires continuous convincing 00:19:46.285 --> 00:19:48.625 of management that it is worthwhile doing. 00:19:48.625 --> 00:19:48.705 Phil: Hmm. 00:19:48.715 --> 00:19:48.985 Vincent Biret-1: Yeah. 00:19:48.990 --> 00:19:54.385 And, and I think also another part that we spend time on, which we wouldn't, if we 00:19:54.450 --> 00:19:57.010 had not open sourced the, the generator. 00:19:57.030 --> 00:20:01.710 Is the experience of a tool itself, like how to well structure the commands 00:20:01.740 --> 00:20:06.810 and provide actionable feedback to users using the the generator. 00:20:07.200 --> 00:20:11.190 We also built a vs code extension, an an integration of the tool in VS code. 00:20:11.620 --> 00:20:15.710 All of that, of course, is not directly supporting our core business. 00:20:16.405 --> 00:20:21.085 But it brings broader adoption, it bring of the tool itself, and it brings 00:20:21.085 --> 00:20:22.765 more people to contribute to the tool. 00:20:22.980 --> 00:20:26.845 And, and that has largely paid off in case any of our managers are 00:20:26.845 --> 00:20:28.945 listening to it post ca, post cast. 00:20:29.025 --> 00:20:30.135 It has paid off already. 00:20:30.140 --> 00:20:32.875 Like for example, on the Java front red Hat. 00:20:32.880 --> 00:20:39.230 Has done tremendous work to get to a much better Java story in terms of generation. 00:20:39.560 --> 00:20:43.840 And, and if we had not open source for generator, if we had not, you know started 00:20:43.840 --> 00:20:48.270 building a community around, around Kda, we would not have gotten those benefits. 00:20:48.270 --> 00:20:48.480 Right. 00:20:48.480 --> 00:20:48.720 So. 00:20:48.720 --> 00:20:51.810 Phil: Ah, that is brilliant and I'm glad you threw that in there just for your 00:20:51.810 --> 00:20:53.220 managers in case they are listening. 00:20:53.865 --> 00:20:55.425 Slightly different topic. 00:20:55.455 --> 00:20:58.395 I mean, I don't think we've talked about Microsoft graph on it before 00:20:58.395 --> 00:21:02.445 and that that sounds like a massive API that sounds blooming complicated. 00:21:02.595 --> 00:21:07.755 So is it a, a series of smaller APIs or is it just one massive 00:21:07.755 --> 00:21:09.465 API with loads of operations? 00:21:09.495 --> 00:21:10.965 And is there 00:21:11.595 --> 00:21:14.295 any difference between those two things really, apart from implementation 00:21:14.550 --> 00:21:16.050 Darrel Miller: hundreds of APIs. 00:21:16.725 --> 00:21:22.695 Produced by completely different organizations at Microsoft that in 00:21:22.695 --> 00:21:28.695 different languages, on different tech stacks, that all gets sewn together 00:21:28.875 --> 00:21:34.485 into kind of like a federa, like a GraphQL Federation data, a gateway, 00:21:34.785 --> 00:21:38.055 but using O data conventions instead. 00:21:38.425 --> 00:21:40.765 And this is one of our other interesting challenges. 00:21:40.945 --> 00:21:45.955 We actually Don't natively use open API to describe our APIs. 00:21:46.295 --> 00:21:47.070 It's ironic. 00:21:47.070 --> 00:21:50.760 It's like in some of the backends do use open API as they're building 00:21:50.760 --> 00:21:53.640 it, but then when they come to Microsoft Graph, they have to provide 00:21:53.645 --> 00:21:58.455 us with what's called A-C-S-D-L description, which is XML based format. 00:21:58.460 --> 00:22:02.295 And it should see some of the, the more junior engineers as they join Microsoft 00:22:02.295 --> 00:22:06.015 and we tell 'em, yeah, you've gotta go and create this XML description of your API. 00:22:07.725 --> 00:22:10.185 Phil: Use this language that's like, it sucks and there isn't 00:22:10.185 --> 00:22:12.465 types and everything's like a Boolean or a string, and just 00:22:12.465 --> 00:22:14.625 Darrel Miller: there's lots of, there are lots of types, but, but, 00:22:14.655 --> 00:22:18.105 but it's, it, it has its challenges, but we're using that language. 00:22:18.105 --> 00:22:23.065 We can basically sew the the ap, all of these different APIs together 00:22:23.245 --> 00:22:26.605 into one coherent, description and 00:22:26.605 --> 00:22:29.565 provide a single surface area. 00:22:29.985 --> 00:22:33.045 And the technology problem is not the biggest thing that we solve. 00:22:33.285 --> 00:22:35.835 It's getting different parts of Microsoft's organization 00:22:35.835 --> 00:22:36.855 to talk to each other. 00:22:36.855 --> 00:22:36.885 I. 00:22:37.350 --> 00:22:41.700 Like how many different companies have you dealt with where you ask them to 00:22:41.700 --> 00:22:45.840 change your address and then you change your address and then you get a letter 00:22:45.840 --> 00:22:49.510 from them three weeks later that's going to the wrong address because 00:22:49.515 --> 00:22:52.060 they have your address stored 74 times. 00:22:52.555 --> 00:22:56.785 Well, we provide that role as a centralized place that says, no, there 00:22:56.785 --> 00:23:00.715 should only be one representation of a user's profile photo. 00:23:00.715 --> 00:23:04.585 There should be only one representation of a user's contact information. 00:23:04.775 --> 00:23:09.330 And that's, that's kind of the, the business value of Microsoft Graph 00:23:09.330 --> 00:23:13.860 is it provides that one unified surface area to our customers for 00:23:13.860 --> 00:23:16.310 doing integrations with that data. 00:23:16.310 --> 00:23:16.850 Phil: That's awesome. 00:23:16.850 --> 00:23:20.030 So yeah, that's, that's the more interesting part I feel like of 00:23:20.030 --> 00:23:23.030 API governance that a lot of people don't get round to talking about. 00:23:23.030 --> 00:23:25.250 'cause they haven't quite got that far yet. 00:23:25.250 --> 00:23:27.620 Like when, when people start trying to figure out. 00:23:28.030 --> 00:23:30.040 What API governance is and how to do it. 00:23:30.040 --> 00:23:34.120 Then it's mostly just like looking at pull requests and saying, don't do that. 00:23:34.210 --> 00:23:37.530 But it's, it's usually kind of focused on that's not the right 00:23:37.530 --> 00:23:39.420 naming and convention, that's not the right security thing. 00:23:39.425 --> 00:23:41.700 Like I, you know, I've, I've been pushing this for a long time 'cause 00:23:41.700 --> 00:23:43.350 I build tools that help you do that. 00:23:43.600 --> 00:23:46.120 But it's kind of getting people started with the idea of it. 00:23:46.120 --> 00:23:50.020 But the, the more interesting thing has always been trying to 00:23:50.020 --> 00:23:53.740 automate some of that dumber stuff, some of that more simple stuff. 00:23:54.440 --> 00:23:58.460 Patterns, standards, conventions, automate as much as you can so that you can then 00:23:58.460 --> 00:24:04.280 start to focus on more domain modeling where you're like, yeah, don't, there's, 00:24:04.340 --> 00:24:05.780 there's already a dress over there. 00:24:05.990 --> 00:24:07.340 How are you gonna keep it in sync? 00:24:07.550 --> 00:24:10.130 Oh, you're gonna do a two-way sync, not on my watch son. 00:24:10.300 --> 00:24:13.775 You know, and, and just kind of just bounce in I bad ideas out of the entire 00:24:13.775 --> 00:24:16.060 ecosystem is, is far more interesting. 00:24:16.060 --> 00:24:16.330 So 00:24:16.540 --> 00:24:19.840 Darrel Miller: one of the most interesting conversations that we have with teams 00:24:20.170 --> 00:24:27.460 is when they show a user's name, and the first question we ask is, are you getting 00:24:27.460 --> 00:24:30.320 that from our central identity location? 00:24:30.530 --> 00:24:30.710 No. 00:24:30.710 --> 00:24:34.580 We, we, we keep a copy of it over here and we're like, oh, no, you don't, 00:24:35.030 --> 00:24:36.770 because people change their names. 00:24:37.490 --> 00:24:42.980 And it can do serious damage to people if they change their name. 00:24:43.100 --> 00:24:47.240 And that doesn't immediately get propagated throughout our entire system. 00:24:47.550 --> 00:24:50.700 And we get some funny looks from teams when we're like, oh, no, no, no. 00:24:50.700 --> 00:24:52.350 You've gotta go back and change your system. 00:24:52.800 --> 00:24:53.880 You can't store that. 00:24:54.435 --> 00:24:57.945 You can cache it for a short period of time, but no, you have to guarantee 00:24:57.950 --> 00:25:01.635 that you are going to sync that name before, we'll, actually you ship the API. 00:25:02.205 --> 00:25:05.715 So it, it, it's interesting the areas we get into conversations about in 00:25:05.865 --> 00:25:07.575 what is, you know, API governance. 00:25:09.210 --> 00:25:09.690 Phil: Mm. 00:25:10.050 --> 00:25:10.320 Yeah. 00:25:10.325 --> 00:25:10.740 Awesome. 00:25:10.740 --> 00:25:14.460 I mean, we had the same, same problem that WeWork where users could live in 00:25:14.490 --> 00:25:18.480 multiple different systems and there was a, a three-way sync between, you know, 00:25:18.480 --> 00:25:22.740 two different monoliths that had roughly half the data that everything needed. 00:25:22.770 --> 00:25:24.290 And like Salesforce, I. 00:25:24.865 --> 00:25:28.255 That we also had a copy of Bloom and everything, and they all 00:25:28.255 --> 00:25:29.635 had different validation rules. 00:25:29.635 --> 00:25:33.595 So when you updated it in one place, it might make it to one or two of the 00:25:33.595 --> 00:25:37.705 other systems, but it might not . So you just had all this like, crazy different 00:25:37.710 --> 00:25:42.180 information and they all used like email as a unique key across all the systems, 00:25:42.180 --> 00:25:44.070 which would change and break everything. 00:25:44.290 --> 00:25:47.290 So yeah, trying to keep data in sync is. 00:25:47.795 --> 00:25:52.895 The dumbest part of the, kind of, was the hardest, most annoying and often 00:25:52.895 --> 00:25:55.685 dumbest part of microservice architecture. 00:25:55.715 --> 00:25:58.685 'cause you're like, what if we split up all this code into multiple 00:25:58.685 --> 00:26:03.155 separate, distinct things that then don't have access to anything and 00:26:03.155 --> 00:26:05.855 we'll just copy and paste everything everywhere and everything's worse. 00:26:06.155 --> 00:26:08.735 So you really need those very experienced people that can just sit 00:26:08.735 --> 00:26:10.805 there and say, yeah, not under my roof. 00:26:11.025 --> 00:26:12.495 Whenever someone triess to copy stuff, 00:26:12.590 --> 00:26:15.375 Darrel Miller: the response is, but, but, but we have to ship this next week. 00:26:15.375 --> 00:26:16.995 Phil: Yeah, it'll be okay this time. 00:26:16.995 --> 00:26:19.155 I promise it won't be like every other time. 00:26:19.665 --> 00:26:19.905 Cool. 00:26:19.905 --> 00:26:23.745 I mean, what other, what other troubles do you have corralling that many 00:26:23.745 --> 00:26:27.525 different APIs into one architecture? 00:26:28.610 --> 00:26:31.875 Darrel Miller: I mean, it, it's the reinventing of the wheel, which is 00:26:32.565 --> 00:26:37.545 no, please don't implement another RAC type security system that's 00:26:37.545 --> 00:26:41.670 specific to your particular . Product in the corner of the system. 00:26:41.700 --> 00:26:44.550 I think that's one of the other common things that we get into. 00:26:44.950 --> 00:26:45.460 I mean, 00:26:45.955 --> 00:26:47.695 Phil: Role-based authentication, 00:26:48.070 --> 00:26:51.820 Darrel Miller: role-based authentication, access control role-based access control. 00:26:51.825 --> 00:26:52.660 That's what our backs from. 00:26:53.725 --> 00:26:54.210 Phil: There we go, 00:26:55.480 --> 00:26:59.080 Darrel Miller: yeah, I think that's probably the other biggest area. 00:26:59.260 --> 00:27:05.020 The other area is, is it is continues to surprise me. 00:27:05.380 --> 00:27:09.860 How a lot of people don't think of resource modeling and they just look 00:27:09.860 --> 00:27:15.380 at a URL as just a string of characters that has no necessary organizing. 00:27:15.380 --> 00:27:17.630 It's just a bunch of nice words that you string together. 00:27:17.970 --> 00:27:22.980 And they don't think of, you know, how are people going to go and use this 00:27:22.980 --> 00:27:30.045 API beyond the very specific scenario that . We are designing for today and we 00:27:30.045 --> 00:27:32.175 are shipping for a particular product. 00:27:32.505 --> 00:27:38.325 It's a case of no, you have to think about that customer who needs to get 00:27:38.325 --> 00:27:41.205 access to the data and they might want to do something different with 00:27:41.205 --> 00:27:42.855 the API than you would considered. 00:27:43.155 --> 00:27:46.845 How can we make that possible without generating a massive amount of work 00:27:47.055 --> 00:27:52.360 and building an infinitely capable machine that nobody is gonna use all a 00:27:52.360 --> 00:27:53.800 large part of the stuff that you built. 00:27:53.860 --> 00:28:00.035 So, I, think it's that just generalized design for serendipitous reuse that's, 00:28:00.095 --> 00:28:01.025 that's hard for people to grok. 00:28:01.025 --> 00:28:01.475 Phil: Mm. 00:28:01.505 --> 00:28:01.805 Yeah. 00:28:01.835 --> 00:28:06.305 'cause you, you either go the, this is just raw data, do with it what you 00:28:06.305 --> 00:28:08.855 will, maximum flexibility, no control. 00:28:09.205 --> 00:28:10.465 Or, or you kind of go like. 00:28:10.740 --> 00:28:13.290 These are the workflows we have really optimized for. 00:28:13.290 --> 00:28:15.960 And they're gonna be sick if you wanna do this thing with it, but if you 00:28:15.960 --> 00:28:17.580 wanna do anything else, it's awful. 00:28:17.870 --> 00:28:20.330 Yeah, that is the constant slating scale of terribleness. 00:28:20.330 --> 00:28:20.570 That is 00:28:20.810 --> 00:28:23.720 Darrel Miller: And you need to find some happy medium, somewhere in between. 00:28:24.140 --> 00:28:28.400 And make sure you also design it in a way that's gonna work well for the client 00:28:28.400 --> 00:28:30.260 code that we're going to project for you. 00:28:30.780 --> 00:28:35.400 Because sometimes you can design APIs that are like, oh, that's just not gonna 00:28:35.400 --> 00:28:38.280 work well in native programming languages. 00:28:38.655 --> 00:28:42.375 You know, like people who do lots of APIs that return very dynamic 00:28:42.375 --> 00:28:45.415 responses, or APIs that return raw. 00:28:46.195 --> 00:28:46.615 Oh yeah. 00:28:46.615 --> 00:28:48.985 Well, we don't wanna schematize this part of the API. 00:28:48.985 --> 00:28:50.095 Phil: Yeah, yeah. 00:28:50.095 --> 00:28:53.155 We've got an API that just like one endpoint, just like spits eye 00:28:53.155 --> 00:28:56.005 calendar format at you . And we've managed to get rid of that 'cause 00:28:56.005 --> 00:28:57.145 it was a bit gross and weird. 00:28:57.405 --> 00:29:00.375 But yeah, it's just like none of the tools are okay because they're 00:29:00.405 --> 00:29:02.505 expecting Jason, maybe X ml. 00:29:02.695 --> 00:29:04.820 And then all of a sudden it's like, what the fuck is that 00:29:06.110 --> 00:29:07.670 So yeah, understand that. 00:29:07.880 --> 00:29:09.740 I mean, bringing it back to Kyoto for a second 00:29:09.800 --> 00:29:12.560 You just by way of wrapping up as well, could probably get into that time. 00:29:12.560 --> 00:29:17.910 But obviously you guys are doing such a wonderful job at making Microsoft 00:29:17.910 --> 00:29:25.200 Graph be very consistent and therefore any You would expect if, if the open 00:29:25.200 --> 00:29:29.160 API is fairly consistent and follows patterns and the APIs are fairly 00:29:29.160 --> 00:29:33.120 consistent and follow patterns, then those SDKs are gonna be pretty, 00:29:33.540 --> 00:29:35.520 you know, standard with each other. 00:29:35.790 --> 00:29:37.380 But for other. 00:29:37.830 --> 00:29:42.000 People like the example of a client who is talking to 10 different 00:29:42.000 --> 00:29:45.540 APIs made by 10 different people, and you've cotified a lot of them. 00:29:46.020 --> 00:29:51.870 How much does different open API affect the kind of consistency of the SDK? 00:29:51.930 --> 00:29:54.810 Well, the API client code that is then generated from it. 00:29:55.030 --> 00:29:58.000 Vincent Biret-1: I would say not that much because a, again, a as, 00:29:58.000 --> 00:30:01.780 as Darryl mentioned at the beginning one one of the key designs aspect 00:30:01.780 --> 00:30:06.520 is that the only opinionated choices we've made were around HGTP and the 00:30:06.520 --> 00:30:10.660 conventions and whatnot, and we stuck to as close as H GTT P conventions as. 00:30:10.775 --> 00:30:15.155 As we could and, and, and for example, if you take the fluent API surface that 00:30:15.155 --> 00:30:19.385 we project for you to call the different operations and, and points and whatnot. 00:30:19.775 --> 00:30:22.325 One the way it is structured is that it. 00:30:22.325 --> 00:30:25.025 follows the path segmentation of your API. 00:30:25.610 --> 00:30:30.605 'cause not only it's easier to map mentally to know, oh yeah, this 00:30:30.605 --> 00:30:36.275 method or this code path on in my code maps to that operation on 00:30:36.280 --> 00:30:39.490 the API, but also it allows us to. 00:30:39.745 --> 00:30:44.665 The structure, the code we generate and potentially avoid any conflicts if 00:30:44.665 --> 00:30:47.555 you have things with different names, but at with the same names, but at 00:30:47.555 --> 00:30:49.925 different levels and, and, and whatnot. 00:30:49.930 --> 00:30:54.135 So now if you look at different descriptions and 00:30:54.135 --> 00:30:55.575 different APIs, even though. 00:30:56.025 --> 00:30:59.445 Their domains are different, even though the terms they're using are different. 00:30:59.775 --> 00:31:04.725 The organization of affluent API Surface and the models and the other 00:31:04.725 --> 00:31:06.885 conventions are gonna be the same. 00:31:06.945 --> 00:31:10.095 They are going to be mostly based on the HT P conventions. 00:31:10.335 --> 00:31:13.985 And there is gonna be another layer of conventions added by, by Qda. 00:31:13.985 --> 00:31:16.445 But it, we try to keep it as thin as possible. 00:31:16.595 --> 00:31:20.475 So it's, it's super easy for you to mentally map your way through the 00:31:20.475 --> 00:31:21.855 different clients we generate here. 00:31:22.785 --> 00:31:23.265 Phil: Brilliant. 00:31:23.895 --> 00:31:28.695 Alright, well I'm gonna recommend that all you listeners go and have a look 00:31:28.700 --> 00:31:35.205 at kta because you might think you're being clever by just doing a, like a 00:31:35.205 --> 00:31:37.425 file, get contents and bunging, A URL. 00:31:38.185 --> 00:31:40.615 And then just like hope that thing works. 00:31:40.855 --> 00:31:45.715 But every time you, you'd kind of directly just write your own little SDK, you've 00:31:45.715 --> 00:31:50.155 just built a bad SDK and it's brittle and there's a lot of things that can go wrong 00:31:50.335 --> 00:31:51.865 and it's gonna be different every time. 00:31:52.045 --> 00:31:56.575 And you don't have the ability to wrap that in beautiful, fantastic middlewares 00:31:56.575 --> 00:32:00.415 that can, can chuck in timeout logic consistently, easily, that can chuck 00:32:00.415 --> 00:32:02.575 in caching logic consistently, easily. 00:32:02.905 --> 00:32:05.785 So yeah, if you have a bunch of like direct dependencies 00:32:05.785 --> 00:32:06.865 that you've written yourself. 00:32:07.430 --> 00:32:11.090 Delete those and maybe Kyoto can be the way to replace them. 00:32:11.480 --> 00:32:15.710 Thank you very much Vincent and Darryl for coming on and I think, I think 00:32:15.710 --> 00:32:18.620 this has actually recorded the whole way through, so I think we're okay. 00:32:18.625 --> 00:32:19.640 I think we did a podcast 00:32:19.875 --> 00:32:20.715 Vincent Biret-1: Hopefully, yeah. 00:32:20.715 --> 00:32:22.520 Thank you so much for having us. 00:32:23.390 --> 00:32:23.990 Phil: Cheers guys. 00:32:24.890 --> 00:32:25.160 Vincent Biret-1: Bye.