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.
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?
Vincent Biret-1: Yes.
Perfect.
Phil: Fantastic.
Welcome both start with you Vincent.
Would you like to just tell everyone who you are?
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.
Phil: Nice.
And Darryl, who, who are you?
Darrel Miller: I work at Microsoft as an API architect on
the Microsoft graph and in my.
Spare time.
I spent some time working on the open API specification and a few
IETF HTP related specifications.
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.
Darrel Miller: Our lips are sealed.
We can say nothing.
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.
But first we have to ask ourselves, what is an SDK?
What is this tool all about?
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 more explicit.
Vincent, tell 'em what it does.
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.
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
Vincent Biret-1: Yes.
Phil: KTA from 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.
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.
Is that about right or have I just butchered it?
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
Phil: later.
Vincent Biret-1: yeah, 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.
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.
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.
Because KRA also offers search and discovery commands and, and, and
features as well to allow you to discover public APIs out there.
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.
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.
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.
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.
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, like figuring
out how to present in code parameters in a query string, and how to use a UI template
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.
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.
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, pattern, event bust, all these different things
and like different different naming conventions and everything else.
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
Darrel Miller: The
kit back in SDK was what it was called.
Phil: yeah, that's the one.
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
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?
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 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.
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.
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 things as well.
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.
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.
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 that.
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.
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.
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.
So, Yeah.
Darrel Miller: Did you notice?
Phil: sounds like it does.
Darrel Miller: Did, did you notice Phil in the latest 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.
And
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.
You can just always send it on a post if, if you want that post to be ideally,
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.
You know, resend this data.
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.
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
kta?
Did you just wanna save API developers from writing boring SDKs, or is
there a bigger business reason
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 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.
So that makes for 70 plus megabytes open API description for the whole thing.
Phil: Good Lord
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.
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.
And, and so this is how we set out to, or this is why we set out to 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.
And hopefully people find it useful.
Yeah.
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,
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 just, you know, us trying to offload book fixes
to the community at this point.
Right.
So.
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.
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.
Who just, who weren't using our SDKs.
And our understanding 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.
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.
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.
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 , 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.
Darrel Miller: Yeah, that's
Vincent Biret-1: Ooh, that's . a, that's a very good
Darrel Miller: We don't wanna admit that publicly.
Vincent Biret-1: yeah.
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.
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 and
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.
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.
But yeah, it, it's a non-trivial amount of work and it requires continuous convincing
of management that it is worthwhile doing.
Phil: Hmm.
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 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.
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.
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.
Right.
So.
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 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?
And is there
any difference between those two things really, apart from implementation
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.
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 more junior engineers as they join Microsoft
and we tell 'em, yeah, you've gotta go and create this XML description of your API.
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
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
provide a single surface area.
And the technology problem is not the biggest thing that we solve.
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.
Well, we provide that role as a centralized place that says, no, there
should only be one representation of a user's 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.
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.
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.
Patterns, standards, conventions, automate as much as you can so that you can then
start to focus on 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.
So
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.
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, we'll, actually you ship the API.
So it, it, it's interesting the areas we get into conversations about in
what is, you know, API governance.
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.
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.
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 things that then don't have access to anything and
we'll just copy and paste everything everywhere and everything's worse.
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,
Darrel Miller: the response is, but, but, but we have to ship this next week.
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?
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,
Phil: Role-based authentication,
Darrel Miller: role-based authentication, access control role-based access control.
That's what our backs from.
Phil: There we go,
Darrel Miller: yeah, I think that's probably the other biggest area.
The other 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.
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.
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 that's,
that's hard for people to grok.
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.
Yeah, that is the constant slating scale of terribleness.
That is
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.
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.
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 because they're
expecting Jason, maybe X ml.
And then all of a sudden it's like, what the fuck is that
So yeah, understand that.
I mean, bringing it back to Kyoto for a second
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.
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.
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.
Vincent Biret-1: I would say not that much because a, again, a as,
as Darryl mentioned at the beginning 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.
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.
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.
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.
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.
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.
And you don't have the ability to wrap that in beautiful, fantastic middlewares
that can, can chuck in timeout logic consistently, easily, that 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.
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
Vincent Biret-1: Hopefully, yeah.
Thank you so much for having us.
Phil: Cheers guys.
Vincent Biret-1: Bye.