►
Description
In this 22-minute developer-focused demo, Vincent Biret from the Microsoft Graph team outlines the process and challenges around how SDK’s are built, tested and shipped today. Introducing Project Kiota, a new project to build an OpenAPI based code generator for streamlining the process of creating SDKs for HTTP APIs. The Kiota tool enables contributors to describe Microsoft Graph APIs in a standard way and to generate modular SDKs – seen in a demo using Kiota to generate a TypeScript SDK for the messages subset of Microsoft Graph. This PnP Community demo is taken from the Microsoft Graph community call – April 2021, recorded on April 6, 2021.
Demo Presenter - Vincent Biret (Microsoft) | @baywet
Supporting documents:
• Repo – Microsoft Kiota | https://github.com/microsoft/kiota
Stay connected:
• Twitter - https://twitter.com/microsoft365dev
• YouTube - https://aka.ms/M365DevYouTube
• Microsoft 365 Developer Blog - https://aka.ms/M365DevBlog
• Microsoft 365 PnP Blog - https://aka.ms/m365pnp/community/blog
A
First
and
foremost,
we
have
a
different
services
like
sharepoint
onedrive
exchange
and
many
more
that
put
together.
Something
called
a
csdl.
Csdl
is
a
document
that
allows
those
different
services.
Saying
hey.
I
have
an
entity,
that's
a
drive
item,
it's
going
to
be
a
visa
and
that
place
in
the
api
and
it's
going
to
be
a
visa
and
that
way
contain
those
different
fields.
It's
a
way
for
us
as
microsoft,
but
also
for
you
to
understand,
what's
the
shape
of
the
apis
and
what
do
they
contain.
A
Once
we
have
that
csdl
document,
we,
the
sdk
team,
take
it
and
put
it
in
a
tool
called
typewriter,
which
parses
that
csdl
document
understands
the
different
data
conventions,
use
different
t4
templates
to
actually
generate
the
sdks,
because
most
of
the
sdk
that
you're
using
are
actually
generated.
They're,
not
handwritten,
because
vpi
is
way
too
large,
and
it
would
take
us
too
much
time
to
handwrite
all
of
that
for
each
and
every
language.
A
So
that's
what
happens
on
the
one
hand,
on
one
hand
we
use
typewriter
with
the
csdl,
and
that
gives
us
as
the
case,
but
of
course
we
want
to
make
sure
those
sdks
are
up
to
standards
very
good
quality.
So
we
have
a
second
tool
called
the
devx
api
that
generates
the
snippets
in
the
documentation.
It
also
generates
the
code
snippets
when
you
use
graph
explorer,
and
this
is
how
you
get
from
an
http
request
on
microsoft,
graph
to
a
code,
sample
code,
snippet,
in.net,
java
or
any
other
language.
A
So
we
use
that
second
tool
and
the
csdl
again
to
generate
the
different
snippets
in
the
documentation
and
once
we
have
both
the
snippets
and
the
sdks,
we
use
both
via
sdk,
in
combination
with
the
snippets,
and
we
try
to
compile
the
snippets
against
the
sdks
to
make
sure
that
the
generations
are
aligned.
Things
are
working
as
expected
and
so
on
and
so
forth,
and
if
raptor
gives
us
a
green
light,
raptor
being
the
process
that
compiles
the
snippets
against
vsdks.
A
This
is
when
we
say
all
right.
This
newer
version
of
the
sdk
that
has
the
latest
and
greatest
version
of
the
api
and
provides
the
latest
and
greatest
entities
and
fluent
api
and
so
on
and
so
forth,
actually
works.
We
can
release
it
in
the
open,
and
this
is
how
you
get
it.
So,
as
you
can
see,
it's
a
fairly
complex
process
today,
and
it
requires
some
knowledge
about
odata
and
csdl,
which
is
not
super
popular
and
easy
to
understand.
A
So
it
makes
it
a
bit
hard
for
the
community
to
to
to
contribute
here.
Some
other
challenges
that
we're
facing
via
data
complexity,
leaks
in
the
different
templates,
and
by
that
I
mean
specific
conventions.
Instead
of
being
understood
and
planned
for
and
parsed
for
are
at
one
place
they
are
being
done
in
different
different
templates
for
the
different
different
languages.
So
we
duplicate
the
effort
here.
The
t4
templates
themselves
are
great,
but
the
lack
of
tooling
they
induce
some
kind
of
duplication.
A
So
this
is
not
so
much
a
problem
for
backend
apis
on
servers
that
have
tons
of
space
and
so
on,
but
it
might
become
a
challenge
for
mobile
apis
or
front-end
mobile
applications,
sorry
or
front-end
applications
where
you
want
to
trim
down
the
size
of
the
application.
So
it's
easier
to
distribute
to
the
end
user.
So
that's
another
challenge.
Today
we
are
only
able,
via
that
tool
to
ship
sdks
for
the
full
api,
not
a
subset.
A
Also,
the
feedback
from
the
tests
become
ver
comes
very
late.
Instead
of
having
unit
testing
very
early
on
to
test
on
the
conventions
and
other
things
like
that,
we
actually
rely
on
raptor.
That
is,
at
the
end
of
a
process,
to
get
the
tests
and
to
get
the
feedback
from
the
generation
process.
Did
it
work,
did
it
produce
something
that
was
expected
and
that
slows
down
our
ability
to
innovate
and
make
major
changes?
A
So
now,
let's
talk
about
project
qrs,
so
we
still
have
the
services
that
are
onedrive,
sharepoint
exchange
and
many
more
that
are
building
that
csdl
description
of
the
service
and
the
apis.
And
now
we
have
a
tool.
That's
provided
by
the
open
api
community
that
allows
us
to
convert
that
csdl
document
into
an
open
api
description.
A
So
for
those
of
you
that
don't
know
about
open
api
open
api,
is
this
standard
that's
been
around
for
a
couple
of
years
now
it
used
to
be
called
swagger
a
long
time
ago,
and
it's
a
way
of
a
standardized
way.
That's
broadly
adopted
to
describe
your
api
and
to
say
all
right.
My
api
has
all
those
endpoints.
They
accept
both
different
parameters.
A
A
If
we
talk
about
the
high
level
architecture
before
we
dive
dive
into
the
code
again,
we
have
this
open
api
document
that
comes
in
qra
has
a
builder,
so
that
builder
uses
the
open
api,
libraries
and
parses
the
document.
Thanks
to
that
and
generates
a
code
dumb.
So
a
little
bit
like
you
have
web
browsers
that
have
a
generator
code
dom
from
the
html,
they
receive
to
understand
all
the
different
elements
that
are
on
the
page
and
what
we
need
to
display
on
the
screen
for
the
user
and
those
different
different
things.
A
Well,
we
kind
of
have
the
same
mechanism,
but
for
code,
this
code,
dom
is
a
very
high
level,
abstract
notion
of
hey.
We
need
a
class
or
hey.
We
need
a
method
or
hey.
We
need
a
property
in
within
that
class
and
so
on
and
so
forth,
and
we
describe
at
a
very
high
level
abstracted
all
the
things
we
need
to
generate
in
the
sdk.
A
Once
we
have
that
code
down,
we
use
it
and
we
feed
it
into
the
language
refiner,
which
is
a
way
for
us
to
flavor
that
code
down
in
a
dot-net
kind
of
way
or
flavor
that
code
down
in
a
typescript
kind
of
way
or
flavor
again
in
different
different
languages.
Why
are
we
doing
that?
Well,
some
languages
support
more
or
less
features.
A
A
few
advantages.
So,
as
we've
seen,
your
data
conventions
are
abstracted
away
by
the
open
api
conversion
step.
So
that's
something
what
we
are
not
responsible
for
anymore:
that's
the
open
api
and
the
data
communities
that
are
doing
that.
For
us,
it's
more
robust.
It's
at
one
place.
There
is
no
more
duplication
anymore.
A
We
have
a
very
testable
generation
process
that
was
kind
of
one
of
the
key
requirements
or
kind
of
a
key
design
we
had
in
mind
and
the
idea
that
was
that
we
wanted
to
design
and
build
a
generator,
that's
easy
to
test
and
to
unit
test.
So
we
can
get
feedback
very
early
on
and
iterate
on
that
feedback
very
early
on,
rather
than
later
in
the
process,
we
don't
have
any
duplication
within
the
languages.
A
If
I
want
to
define
how
do
I
write
a
method
in
java,
I
only
do
it
once
at
one
place
in
the
writer
and
then
it's
been
reused
whenever
it's
needed,
but
we
don't
have
duplication
of
what
is
a
method,
how
I
define
the
accessibility
of
that
method
and
so
on
and
so
forth
anymore
within
the
languages.
It
is
done
once
per
language,
it's
going
to
be
easier
to
contribute
to,
and
the
reason
is
because
we're
relying
on
plain.net
there
is
no
t4
anymore.
The
tooling
support
is
great
and
it's
easier
to
understand.
A
A
It
also
will
work
with
any
app
any
api
that
has
an
open
api
description,
so
we're
building
the
tool
in
a
way
that
it
works
first
for
microsoft,
graph
and
the
sdks
that
we're
we're
building.
But
if
you
have
in-house
apis
and
evo's
apis
have
an
open
api
description.
You'll
be
able
to
use
kyota
feed
in
that
open
api
description
instead
and
get
a
fluent
sdk
in
the.
A
Choice
for
that
specific
api
and
lastly,
it's
also
plug
and
play.
We
received
feedback
that
some
people
prefer
this
or
that
json
serializer,
for
example,
or
some
people
prefer
this
or
that
http
client.
So
it
is
also
designed
in
a
way
that
we
have
a
high
level
of
abstraction,
will
provide,
of
course
default
implementations.
A
A
So
here
I
have
and
before
we
dive
into
kyoto
itself.
I
have
this
open
api
description
here.
It's
rather
lengthy
and
we
don't
need
to
go
over
the
details,
but
that's
a
description
that
we
use,
for
example,
to
generate
the
partial
lsd
case
today,
and
the
idea
is
that
description
only
contains
mails
things.
So
things
about
sending
emails,
getting
the
emails
from
microsoft,
graph,
getting
the
attachments
all
those
different
things.
A
It
doesn't
contain
anything
else
than
things
that
are
related
to
my
to
microsoft,
graph
messages,
capabilities
and
it's
effectively
a
subset
of
microsoft
graph,
and
so
that's
the
first
thing
in
terms
of
how
kyota
is
built.
Well,
we
do
have
a
few
things
here.
First,
we
have
a
generator,
that's
contained
in
the
source.
Folder
and
you'll
see
that,
as
I
mentioned,
we
have
a
different
constructs
for
the
code
dom.
So
what
is
the
namespace?
What
is
the
method?
A
What
is
your
class
and
those
different
things,
but
we
also
have
different
writers
for
the
different
languages
for
typescript,
java
and
and
c-sharp
here
as
well,
and
the
different
writers
for
the
different
languages
here
that
are
available.
And
finally,
we
also
have
the
builder
that
I
was
mentioning
earlier
that
takes
in
the
open
api
description.
A
So
that's
that's
a
high
level
overview
of
how
kyoda
works,
I'm
going
to
fire
off
a
generation
and
show
you
what
you
get
out
of
it
and
before
I
do
that
here
I
have
this
other
project,
which
is
typescript
starter
for
a
node.js
application.
I
chose
typescript
for
today
and
I
chose
a
node.js
application
for
today
as
well,
but
this
would
work
in
a
browser.
This
would
work
in
dot
net
or
in
java
as
well.
Those
are
the
three
languages
we're
supporting
today,
so
I'm
going
to
go
ahead
and
clear.
A
So
I've
set
up
cuda
to
I've,
set
up
my
environment
to
be
able
to
generate
things.
So
here
you
can
see
that
I'm
calling
kyota
not
for
java
for
typescript
here
we
you
can
see
that
I'm
calling
kyota,
I'm
passing
it
the
open
api
description,
I'm
saying
hey,
I
want
a
typescript
thing
and
please
put
all
the
files
here
and
here's
the
namespace,
even
though
it's
not
namespace
in
typescript
that
I
want
you
to
generate
things
in
as
well.
So
I'm
going
to
kick
off
the
generation
process.
You'll
see
that
very
quickly.
A
A
So
again,
all
of
that
is
going
through
the
open
api
description,
generating
a
code,
dom
parsing
refining
the
code,
dom
you
know
typescript
flavor
and
then
calling
the
writer
to
write
all
the
different
files
to
the
local
storage
and
there
we
go
generation
is
finished
so
again
within
a
few
seconds
and
keep
in
mind
that
me
being
sharing
my
screens
only
impacts
the
performance
of
my
computer.
We
were
able
to
generate
an
sdk
for
the
messages
subset
of
microsoft
graph.
A
So
here
you
can
see
that
all
the
things
that
I
had
previously
deleted
are
back
and
one
great
thing
about
kyoda.
Is
we
try
to
make
it
so
what
we
generate
is
easy
to
map
with
the
api,
so
you'll
see
that
the
folders
or
the
namespace
segmentation
is
very
close
to
what
you
find
in
the
api.
We
know
that
messages,
for
example,
are
attached
to
users
or
are
under
users
or
groups,
of
course,
on
the
microsoft
graph
api.
So
you
can
see
that
under
users
I
have
a
message
entity
here.
A
A
So
now,
if
we
jump
into
the
application,
my
actual
application,
you
can
see
that
the
first
thing
I'm
doing
here
is
I'm
using
azure
identity
to
get
the
token
and
to
authenticate
against
microsoft
graph,
I'm
passing
that
authentication
provider
to
the
core
provider.
So
again,
that's
one
of
the
things
we've
implemented
by
default.
We've
implemented
a
way
using
fetch
to
talk
to
microsoft
graph
behind
the
scenes.
A
All
of
that
is
plug
and
play
as
well
as,
as
I
mentioned,
and
you're
ready
to
go
you're
ready
to
use
the
the
api.
So
here
what
do
I
have?
Let
me
just
because
I
made
it
bigger
here.
You
can
see
that
if
I
do
client
dot,
control
space
you'll
see
that
I
get
my
phone
api.
So
I
get
users
I
can
get
all
the
users
if
I
want-
or
if
I
get.
If
I
want
to
get
a
single
user,
I
can
get
a
single
user.
A
You
can
see,
I
get
auto
completion,
I
get
the
different
things
that
are
available
again,
I
get
the
documentation,
inbox
and
so
on
and
so
forth.
And
finally,
when
I'm
ready
to
make
my
email
folders
my
id.
Finally,
when
I'm
ready
to
make
my
request,
I
can
do
get
if
I
want
to
get
things.post.
If
I
want
to
create
things
and
so
on
and
so
forth,
all
of
that
returns
promises
in
typescript.
It
returns
futures
in
java
and
tasksin.net,
and
if
we
go
ahead
and
actually
debug
that
application.
A
There
we
go
so
here.
It's
telling
me
hey,
because
I'm
using
the
device
code
flow,
but
again
it's
because
of
azure
identity.
It
would
work
with
any
kind
of
flow
for
the
back
end
for
the
front
end
for
anything
you
want
to
do,
and
here
I'm
going
to
chrome
with
my
debugging
profile
entering
the
code
saying
signing
in
and
that's
it
I'm
ready
to
use
my
app
that
I'm
showing
to
you
here.
A
So
if
we
get
back
here,
I
have
a
breakpoint
that
stopped
here,
so
you
can
see
that
what
happened
here
using
the
fluent
api
I've
used
my
client.
I
got
my
own
user
here.
I
got
a
specific
message
with
a
specific
id
and
I
executed
a
request
with
a
dot
get
here.
If
I
can
hover,
you
can
see
that
I
have
my
decentralized
message
with
all
the
different
properties
with
sub
properties.
Eventually
it
all
visualizes
recursively
that
are
available,
and
here
then
I'm
using
this
message,
I'm
getting
the
subject.
A
A
Oops,
sorry
about
that,
I'm
creating
a
new
message,
I'm
setting
the
different
properties
I
want
to
set
all
of
that
again
supports
auto
completion
because
we're
using
typescript-
and
here
I'm
using
the
default
serializer-
that's
provided
to
actually
serialize
the
message
that
would,
I
could
eventually
send
or
do
anything
with
on
the
wire.
We
also
support
enumerations.
We
support
collections,
of
course,
and
many
many
other
things,
and
here
you
can
see
in
the
console
that
I
have
my
serialized
payload
here
with
the
different
properties.
B
C
A
Sure
that's
my
next
slide.
So
if
you
want
to
get
started
with
kyota
one
place
to
go,
github.com
microsoft,
slash
kyota,
that's
k,
I
o
t
a
and
there
you
can
do
a
couple
of
different
things.
We
still
have
a
couple
of
poll
requests
to
merge
and
clean
up,
but
you
can
go
and
try
qra,
either
on
your
own
api
or
on
microsoft
graph
and
give
us
feedback
around
that.
A
You
can
also
tell
us
your
expectations
about
typescript
fluent
api,
because
one
of
the
first
things
we're
trying
to
call
via
kyota
is
to
make
sure
you
get
a
fluent
api
for
typescript,
because
we
know
that's
been
a
consistent
request
for
the
past
few
years.
Let's
say
so.
If
you
have
expectations
in
terms
of
typescript
format,
api,
what
it
should
look
like
how
it
should
behave,
all
those
different
things
is
feedback.
A
We
want
to
hear
about
you
these
things
we
want
to
discuss
with
you
about,
so
we
make
sure
we
build
the
greatest
typescript
fluent
api
and
with
that,
if
there
are
no
questions
I'll
hand
it
to
the
microsoft
graph
toolkit
team
to
tell
us
more
about
their
new
features
and
new
capabilities.
Thank
you
very.