Subscribe
Share
Share
Embed
Creators and Guests
Host
Guest
What is APIs You Won't Hate?
A no-nonsense (well, some-nonsense) podcast about API design & development, new features in the world of HTTP, service-orientated architecture, microservices, and probably bikes.
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.