>> 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.