>> We received a lot
of feedback about
the previous version of our
JavaScript SDK for Azure Cosmos DB.
We took that feedback
and completely redesign
the SDK to improve
the developer experience.
Chris Anderson is here to show us how
much easier it is to work with
Azure Cosmos DB from JavaScript
today, on Azure Friday.
[MUSIC].
>> Hey everyone, Donovan Brown here,
with another episode of Azure Friday.
So Chris, show me
how the SDK has been
improved for using Azure
Cosmos DB from JavaScript.
>> Yes, one of the things we
really wanted to improve was,
we wanted to make it modern.
It was still using callbacks for
everything no promises anywhere.
We wanted to really
embrace fully open-source.
So, now everything is
open source. We're accepting.
We're doing all of
our PR is on GitHub.
You can actually see that we've
got seven outstanding things.
You've got to get track here.
We have a project for actually
tracking all of our works.
You can actually see
what our priority of
workers and things along those lines.
So, we're really trying
to make sure everything
happens in the open and we
can be very collaborative.
>> Right. When you said modern,
so give me some examples of what
modern JavaScript looks like today.
>> Yes. So if we scroll down here,
for anyone who's used the old SDK,
we wouldn't be able to fit
a sample on a single screen.
Here I've got the sample,
all showing on one screen,
and you can see or we are using
the new Azure AD Azure
namespace and npm.
You can trust that
this package as us.
Some friendly person
out there publishing
and packaged with
the similar sounding name,
all the Azure npm modules out there,
you can trust their Microsoft
because I control the keys.
Inside of here we
made the cosmos client lot
simpler to understand.
Previously it was lots of different
arguments you had to append.
>> Okay.
>> Now we're actually just
going ahead and taking
in a giant property bag of objects.
>> Okay.
>> And there you can
actually use "Discovery",
when you're using Type Script you
can go ahead and "control
space" and you get
all your options presented to you
for what options you can have.
>> All right.
>> Then the other nice thing
we've got here
is of course it got promises.
So, we can go ahead and use
"Async" await inside of
newer JavaScript and Text
Script environments.
>> Okay.
>> Then we've actually
got the ability
to return a response type
that has lots of
default properties on it.
We're actually using "Object
Construction" in order to
go through there and rip out
the specific objects we want to.
>> So this Syntax here that you're
highlighting right now is saying,
"I only want you to pull
the container property from
what got returned and
just give me that".
>> Exactly.
>> What about this one
here with a colon,
are you saying "I only
want the database but
map it to the variable called Db".
>> Exactly.
>> Got it. So.
>> Wow, cool.
>> Because I have a lot of code
that gets this big object back,
and then I'm pulling out
the properties that I
care about and pretty much
throwing away the rest,
and that's boilerplate code
over and over again.
And this new Syntax here
just allows me to say,
"This is all I care about. Just
give me those variables.".
>> I was very intentional, right?
Before we had basically a
callback that had lots of
different things that kept on
appending to the parameters
we could return back.
And we've got to go
and collapse this all
into some object to return.
So, we have basically
a very flat object and then we'd
go with object deconstruction.
So, you can still grab
just the one you want.
>> Okay.
>> Well, the nice thing
with this isn't
previously you'd have had
to go through there and
create an argument for
your body that you got batter.
What if you only wanted
the Headers Objects,
you'd have to basically just create
that and then throw it away.
You never do anything. In
this case, you only grab Headers.
>>So, I'm a note I'd
ride in a lot of no JS.
But I'm embarrassed to admit that
I've never seen this before.
Should I be embarrassed
that I've never
seen this before? This is new.
>> Not really at all.
This was one of those things that
came out with ES-6 I believe.
>> Okay.
>> You sought a lot more
with the other way around,
where libraries would
go ahead and use
this internally for doing things.
But you do want to
take a look at some
of the interesting things you
can do with this in JavaScript.
For instance, if you're used to using
Object Data Sign to go ahead and new
up an object so that we've got
two different references to
the same content and an object.
Your new way of doing that
is to actually go through
and do object structuring
into an object like this.
So,that would be like Bracket
dot-dot-dot my existing object.
That'll give you a new Clone of
that object and I use
all the same properties.
But it's a shallow Clone.
So, if you have
any Nested properties,
you have to remember to do
a deep Clone and that'll
probably involve some jQuery.
>> Absolutely. But now it's really
cool to see how, like you said,
in just that one little
screen real estate
I was able to get so much
done using the new API.
So, tell me some other
new things about
the API as well, with the SDK.
>> Yes. So, one of
the other things we're doing is,
we're trying out
some pretty advanced things
inside Java-scripts and trying
to keep the cutting edge
inside of the library.
>> There was a optional
to use these things.
>> So, for instance
before you would go ahead
and call a queryiteratorfor.forEach,
and that allow you to iterate
over a bunch of different items.
>> Sure.
>> The problem with that was it
was a callback based system,
and of course that's going to
go ahead and lead to
issues where you've got
to return a promise called
a call back for a moment,
and we all screw that up
and I get that little arrow
saying "unhandled promise
exception, you're a bad person".
Or at least that's what
I've heard environment.
But I think that's what I see.
So, we really wanted to go
and find every single one of
those cases where we
were using callbacks,
what could we do, and
you can't really do
just a promise for each, right?
Because you want to
iterate over the items.
>> Sure.
>> That's where Async Iterators
came to the rescue.
In this case it's actually
using Typed Scripts.
One of the things we did when
we started to change the SDK,
is that we actually
started by just taking
the entire Codebase converting
it to Type Scripts.
>> Okay.
>> If you go into our GitHub, you
can actually go and see results.
All the Arzure process,
I think it was like
50 thousand lines of code touched.
In the end, we ended up
deleting a lot of code which is
great big props to move in
a type script is you can
just remove a lot of code.
>> Nice.
>> And of course it gave us
a lot of type checking we found.
And the old SDK thanks to
the Type Script stuff.
>> Yeah I know a lot of
people who actually run
their pure JavaScript through
the Type Script compiler,
even though it's not Type Script to
fine a lot of those
weird little bugs and.
>> Exactly.
>> It's really cool. Experience and
exercise to go through and
find those little edges.
But this right here, what I liked
what you just said is that,
you don't have to use
these cool new features, right?
If your code is already written
refactoring it doesn't mean I have
to go to the latest and
greatest bleeding edge,
JavaScript technology and
try to learn and catch up.
I can still do it the way
I did it before and it'll
still work, but it worked better.
If you're ready, then
you can go right to
the bleeding edge and we're in
you're ready for them as well.
>> Exactly. Using this feature
right here is called Async Iterators.
One of the tricks to
using them today is,
if you want to use them in
JavaScript you've got to use
some bleeding edge version
of one of the JavaScript
engines out there,
in sediments of Lags and
things along those lines.
Type Script is like, yeah,
we can make that work for you and
I look through there and create
kind of a shim implementation
for it for you when you build,
but it still looks
for the symbol.async
iterator property existing on
your iterator you pass in.
So you actually have to
set an iterator global.
If you're on an older
version of Node,
it still works from
node six and beyond.
>> Okay.
>> But you got to go and
set some global symbols
to make sure things work.
There's somewhat polyphenols.
You do even a node to make this work.
So, it's really pretty far out
there for a lot of people.
When I did a poll for what versions
and of no people were
on, there was no date.
And node it doesn't support
this. So, this is looking
towards node ten and what's
going to be beyond there.
But, we want to go ahead and keep
pushing the edge with this SDK.
This is really trying to do that.
Now for cosmic anomaly
for Cosmos we're actually
sharing a lot of these ideas
with the other folks here at
Microsoft to bring
all of that node SDKs
the same kind of
bleeding edge standard.
>> So, I've seen a lot
of changes in the SDK,
the landscape and the way
that you using the syntax.
Were there any other changes like PR
for security or anything else that
was done to the SDK as well?.
>> For the most part it ended
up being relatively clean.
One of the things we did is we,
thanks moving to Type Script.
It was a lot easier
to refactor things.
>> Sure.
>> So, the original SDK when
they had first written it
was actually quite simple.
It was basically just calling
a couple of rest methods.
>> Okay.
>> Then they added a query in there,
and queries of very complex beast.
The other thing they did is
they had a flat structure.
So, one of the things that might
be really attractive to people
who are using the old SDK,
is you'll never see inside
of any of this code a URL.
Today with Cosmos DB
libraries all of them
across things not just Java-scripts
but we also got NET Java, ex cetera.
They actually have to pass in a URL.
>> Okay.
>> So, you've got to instruct
this URL and know what
the structure of
the URL is for Cosmos,
and it's relatively easy,
it's databases,
collections, documents.
>> But, why have the overhead?
>> Of what we did is
we actually created
this hierarchy model
inside of the SDK.
So, like if we go down here to
the first method that we
call, we call it net.
And we've got this great
if not exists method.
This is also great because
NodeJS you'd have had to
do this before yourself
where you basically try to read
the database and if it failed
then go and create it.
We actually just had
this because when
we were doing user testing
we found everyone
struggled to figure out
how to make this work
and by adding this method everyone's
succeeded another user tests.
>> Awesome.
>> So, all this is one of those
like really good things that
came from testing with users early
on as you're designing the SDK.
>> Okay.
>> From here we actually go ahead
and grab the database
object directly,
and this is a database
object that now has
a reference to self release.
So, here when I typed database,
I can actually see there is a URL.
We still exposed as
Apollo property and case.
For some reason you wanted to
include that you're logging,
we didn't want to break
too many existing models.
>> Okay.
>> But, basically you don't ever
have to construct that URL.
It's constructed from
the object itself.
So this is a read-only property.
>> Right, there's this still follow
the pattern that you just said
that you don't have to use it.
If I were to upgrade to
the latest version of the SDK,
would my code that was
using the full URLs break?.
>> Yeah. So in this case
we did move you towards
this builder pattern.
So, if you will eventually have
to move away from those URLs.
>> Okay.
>> That's somewhat intentional.
>> Sure.
>> The URLs themselves and of adding
overhead like you having to
construct strings and stuff.
We know that we don't want people
to have to do right guidance.
If you go and do a perk test
on any piece of code,
it's the string manipulations
and then most of the time,
because we do that internally now.
So, you never actually
have to think about what's
the right way of doing
perfect that yourself.
>> Okay, cool.
>> Then yeah, that's
protected all the way down.
So you'll never actually
see us construct
a URL for any of these items
that we're trying to update.
You can see as we get back.
In this sample you can go ahead,
and this is a sample of
all the different types
of methods you can do to an item.
>> Okay.
>> So, in this case we've got,
making sure that everything exists.
We're doing the same kind of
restructuring thing here.
You can see that the S cozy man and
a nice little hints that
we don't need database.
So I can go ahead and remove this.
>> I see because you never you
are never referencing it below.
>> Yes. So, VS code just make.
I got to say VS Code,
it saved me months of time.
>> It's brilliant. It works more.
>> Inside of this, I'm
basically going through
there and creating items.
I'm putting all these things into
an array and then I
can go through there
and do an await on promised
at all for all of them.
So I can go out and do a bunch of
parallel inserts and I wait
for all of them and with
promises, that's easy.
No more having to use Async.
Paralyze a bunch of different work.
Then we go ahead and we can
read all those items back out.
Then in this case we're
using the old school model.
We didn't want the samples
to kind of push
people too hard. So, we
have the technology.
We have that kind of bleeding
edge stuff inside of the code.
>> Yes.
>> But all of our samples are
still trying to play more of
a middle ground where like object
is structuring, it looks nice.
So, we're trying to push
period towards that.
Yeah. But for await has
a big overhead still,
and you don't use Type Scripting for
the most part and make it work.
>> Okay.
>> So, here we're
staying away from that.
But then I get
a reference to an item.
I can go through there and just do
container.item to get a reference.
Then I can go ahead and
do itemFixed.Me.read
and now I have the definition
of the item that I read.
Then if I wanted to update the item,
I can then go through there
and try to read it with
an axis condition and
those things are now
here and the read property
is still like all this stuff
used to be like one big long line.
You'd have like five different
arguments to pass into the method.
One kind of design goal we had was,
could we construct a SDK where
most methods take one parameter.
We didn't want you to have
five different arguments.
Those are really hard to read.
We wanted the code to read
like it was behaving.
Now having to parse every little
line of code you won't want it.
You just look at the method
and know it was happening.
>> Awesome. Yeah I know,
I'm looking at this code and then I
have a lot of refactoring to do on
my own JavaScript because this
is much cleaner and
simpler like you said.
Simpler to read, something in
a digest which is going to
make me more efficient.
>> Yeah.
>> I don't want them to come through.
>> We definitely learned a lot
from doing the conversion.
I think the codebase it was around
50 thousand lines of code when
we started and had to
go through each one of
the things to figure
out how to go and
break that up into
the right components.
After we've converted everything,
we then started to do refactoring.
So we took out
this giant middle layer.
You stood existing SDK and
it completely refactored it.
So it's no longer there. So, that was
because of the US Code and Type
Script that was easy
as a lot of F2's.
It was really great.
>> Nice. Well, this is really
cool and exciting stuff.
Actually I'm going to be
distracted this afternoon.
I'm actually going to
go start playing with
aloneness and go refactor my code.
But it's cool to see how
our SDKs are making sure
that they're not behind,
and that they're actually
leading the charge
and actually helping shape
the future of a lot of what we're
doing in the fact that
it's open source.
Just, I say this all the time
that this is not
your daddy's Microsoft.
Right? This is amazing
that we're taking
this Incredible technology and we're
just giving it to everyone so
they can help us improve it,
and they can see exactly how
it's written and use a lot of
these same patterns
like I'm going to go
do in the code that
I write for myself.
>> The last four years
or at Microsoft,
I haven't written a line
of closed source code.
>> I think I'd have
to agree with you.
I think everything
I have is in GitHub
right now and everything and I'm
working on is taking poor Question
from the public which is fantastic.
So, thank you so much for
showing us all this stuff.
We're learning all about
the new Azure Cosmos DB JavaScript
SDK here, on Azure Friday.
