Hello and welcome to the Serverless
Days. My name is Vigyan and
I'm a senior solutions architect
at mongoDB. Today I'm here to
talk about MongoDB Realm,
which is an application
development service that lets
you focus on building the front
end features that you users care
about the most and without you
worrying about the servers.
We'll start by talking a little
bit about serverless in how we
have approached Serverless in
the mongo DB cloud.
We will show you some of the
features that we have built
and how you can actually use
them in your application.
Towards the end
we got a demo to show you
some of these capabilities.
So we're going to start with
just talking a little bit about
serverless at a very high level.
I think one thing that most
folks can agree on is that
Serverless has become a little
bit of buzzword over the past
couple of years. So I want to
take a step back and talk about
what we mean when we say
serverless. First point is zero
management. I think it's
generally pretty well agreed on
that with Serverless, you don't
have to think about scaling up
or scaling down, and that's
great for the application.
But it really extends beyond
that a little bit.
So if you think about building
out applications, servers,
containers, it actually goes
beyond scalability and you start
thinking about patching,
upgrading, putting together your
architecture and also security
and other best practices.
Really, with our approach to
Serverless, we have tried to
streamline not only just the
scalability, but some of those
other aspects as well.
Now, that's not to say that you
don't have to think about how
performant your code is or how
it interacts with other parts of
your architecture. That leads to
the second point, which is
logic centric.
As you start building, you want
to think about each functional
trigger that you write
or what you want to accomplish
in the context of your
application and not having to
think about the management
aspects really helps that along.
Just focusing on the business
logic, the validation logic of
your permissions. That's, that
writing your, that's part of your
writing the function trigger.
3rd is the consumption based.
For the ability to not
think about scaling up and
scaling down, that really
takes a lot off the radar.
But you also want all of your
serverless architecture to be
priced on how much you use.
I think this is one of the real
benefits of scalability, and of
Serverless in general because you
don't have to think about
managing scale and also you
don't have to think about paying
for that scale.
So the question is how
has this influenced our
approach to Serverless?
I just want to take a
moment here to acknowledge, or if
you have worked at all with some
serverless services offered by
mongo DB in the past, you might
have heard of mongo DB Stitch.
We're going to be talking
about mongo DB Realm today.
That's because we have
recently rebranded Stitch.
About a year ago we acquired
a company called Realm that
builds up create mobile
syncing technology and we
have integrated that into
Stitch and now we have
rebranded that whole set of
services as mongoDB Realm.
If you're familiar with Stitch
functions, Stitch triggers,
we're going to talk about those.
Today we will call them Realm
functions, Realm triggers
because we have rebranded.
The important thing to note is
that if you're familiar with
those concepts, nothing really
has changed here, but there are
some new things to take
advantage of. Mostly it's just
changing name. As we think,
about serverless with mongo DB
Realm there are really, three key
things that we try to build up
to differentiate ourselves from
other approaches to Serverless.
The first thing is no scaling.
And this might sound a little
bit familiar if you have heard
other approaches to Serverless.
There are a couple of things
that we do a little bit
differently with Realm functions.
First and foremost, if you have
worked with serverless functions
before, you might be familiar
with the concept of cold calling
cost or, or must have thought
about having to pre-warm your
functions or set the level of
concurrency that your functions
can operate on.
This is all to prevent higher
latency due to serverless
infrastructure spinning up. With
mongo DB Realm you don't have
to think about any of those
things. That's the concept that
we find to be very much similar
to container based or server
based workflows. The important
thing with Realm functions is
you don't have to think about
preallocating compute.
You don't have to think about
what your scale is ahead of
time. You just run your logic
and Realm will respond with the
right amount of scale. One piece
of this is that which I think is
a little bit also different.
When we talk about scale here,
we're not just talking about
function execution, but we also
work closely with your database
to ensure that your function and
your database are working
together. Now this leads to the
second point. You may, if you
have worked with serverless
functions before, be aware of
that they open up connections to
the database. This can often
lead to issues like latency if
that connection is being opened
up for the first time or it can
lead to connection storming to
your database if you have
spike in serverless functions.
With Mongo DB Realm we maintain
an keep form and pull the
connection between your
functions and your database. You
really don't have any latency
for making that initial
connection. Once you start
connecting Mongo DB Realm to
your Atlas instance, we make
connections and we really
simplify that process. We also
keep your connections warm and
we poll them.
When if you have a huge spike in
traffic, you basically would
raise the connections. It's
generally a efficient way to use
connections, and that's not the
only way that we work a little
bit more closely with the
database. We also make it simple
to define data access rules on
top of your Atlas instance.
Really ensuring that only the
right users or the right systems
have access to the right data.
We also make it simple to write
code that interacts with your
mongo DB Atlas instance.
We will get a little bit into
one of the syntax of that looks
a little bit later.
Finally, with mongo DB
Realm, the serverless
functions of little bit
more application aware.
They have simple access to your
data and it's very easy to call
them from your front end
application. Also, with that
more deeply integrated
allocation and rules that I have
been talking about earlier,
provides more often end to end way
of dealing with serverless from
tight connections to the to your
database through the
execution of your function
logic and to the connection
to the front end.
These are the three things
that set our approach to
Serverless a little bit
apart from other systems.
So what this has
led us to is a
couple of key services and
features that make it more easy
to work with serverless in
mongo DB Realm.
1st is functions.
These are just a layer of
serverless compute sitting
side by side to your mongo
DB Atlas instance.
There are a couple of
different ways that you can
call them or interact with
them. We will talk about some
of those, but the important
thing is just that you write a
standard JavaScript and
interact with the front end
and your database.
One way that actually make it
easy to call these functions is
with trigger. There are a couple
of different things that we
have. Probably the one that
most folks are using or
familiar with is database
figures. If you're familiar
with the concept of database
triggers traditionally, you
might actually think that
they have a little bit of
negative connotation.
Linking your data,
executing on the same box that
your database lives
potentially eats into the
computer available or makes it
tough to scale.
What's nice about our approach
to triggers is that the compute
for your trigger lives outside
of your database and they scale
separately, so you can have
large amounts of triggers that
are executing and you don't have
to worry about
that eating into your database
resources. 2nd.
We also have triggers that
respond to authentication events
for your application, whether
it's a user signing in or
signing up or being deleted.
Finally, we have scheduled
triggers as well. These are
basically allows you to define
define an expression with cron
syntax and then run a serverless
function on regular schedule.
In addition to triggers, we
also offer a couple of other
ways for your serverless
functions to interact from
within your application.
1st is set of SDK for
mobile and web applications.
These make it easy to call your
functions and have those
interact with the database or
other systems from in front end
of your application.
Whether it's web, whether it's
mobile, whether it's even under
the racking system.
We have a number of SDKs
that allow this.
We also let you create API
endpoints on top of your
database. We can create incoming
webhooks. Webhooks more like a
REST interface on top of your
Atlas instance or interacting
with your serverless functions.
In addition, we have Graph QL
service. This will let you
interact with Mongo DB Atlas,
but also you can use functions
to define custom resolvers and
enrich your Graph QL endpoint.
Having it interact with
this service or having
more complex interactions
on top of your database.
We're not going to dive too
much into the Graph QL
aspect of the things here.
With these features
there're really a couple of
common patterns that we see
folks building out with.
1st is propagating data.
This is a common pattern for
triggers as data is loaded into
your mongo DB Atlas instance,
ensuring that the data gets sent
out to either other systems or
other parts of the database.
This could be a couple of
things. For example, could be
archiving data in S3. It could
be sending it to another Atlas
cluster, for instance, or it
could be taking that data and
adding it to another document in
another collection. Or it could
be maybe, incrementing a counter
or set up order somewhere else
in your database.
Really just ensuring that
your application only has
to make a single write,
but that data can actually
fan out and be propagated
to a number of systems.
2nd is parsing and processing
data. Often times if you're
dealing with API endpoint or in
application, the front end or
your API endpoint in your
database don't always need data
in the exact same format.
There might be subtle
differences. There might be ways
that you want to adjust the
format or do some, like
calculations as that data
travels between your frontend and
your database. This is a great
place where you, where we see
people using functions could be
just adjusting the way that it
is structured or could be
something a little bit more
complex. Functions are flexible
enough and enable
you to do both.
Next is notification.
A little bit similar to
propagating data, but as things
change or update, data is loaded
into your database, you may want
to notify on some of those
changes. It propagating data
it's typically something where
you are taking all of the
changes and you're pushing
them to an external
system. But with notification
you're really looking for
thresholds to be met or
changes to happen that flip
the trigger, the specific trigger.
There's a lot of different
things that you can do from
there. Sometimes you might want
to send an alert with a system
like Twilio or send an email
through SES or mailgun.
Similarly,
you might want to put that on
more of an event based system.
Something like a Kafka or
event bridge. Regardless, that's
something easy to do with
functions or triggers.
Finally, building out some of
your event logic, really serving
that layer in between your
database in your application
front end. That makes it easy to
build out your business logic
and just really all of the logic
that hooks up your database
to your front end.
Before we actually move onto the
demo I want to talk a little
bit about how you actually
develop with Realm functions and
a couple of points on the syntax
and how things are written here.
At a very high level, well
functions essentially give
you standard JavaScript.
They have a couple of goals that
are unique and one of one is
ensuring that it's simple to
talk to mongo DB Atlas.
You have a Realm application
that you connect to Mongo DB
Atlas instance. Then within
your functions you can point
to that Atlas instance, issue
any standard mongo DB commands
and work with your data
without having to think as
much about setting up or
upgrading. That all
happens automatically.
Now we also give a little bit
extra context to your Realm
functions. Context on where the
request is coming from.
Sometimes that's useful for your
logic or for more application
centric functions. Giving you
information on the users who are
making the request. There are
user IDs or any custom data that
you have chosen to link to the
user. Really just giving you
the ability to understand
who's making the request and
also who has access to
functions, other
dependencies, etc that you
want to import.
In addition, there are two
models that you can use to build
with Realm functions. The first is
more of a US centric model.
As you can see here we have got
a nice development console.
We allow you to write code in
your web browser and we also
have a console where you can
execute that code.
And you can even change the
execution environment to be from
a perspective of a different
user. So if you want to test how
the function executes through
different permissions, that's
pretty simple to do.
That being said, it's easy to
move development from browser to
either local development
environment or GitHub.
Everything here behind the
scenes map down to JSON and
JavaScript files. Those can be
exported. Those can be worked
with locally or put in a repo
with mongo DB Realm to pick up
for automatic deployments.
As you start to move from this
serverless layer to the
application layer, I want to
talk a little bit more about
some of the SDK syntax.
Basically, you get to really
nice things with the SDKs.
One, built in authentication, so
you have the ability to use that
to link your front end with all
the requests that you make. As I
said before, that then can be
also used to make decisions with
your functions. It can also be
used for rules, really giving
you the ability to write and
focus on those serverless logic,
but also to have a set of data
access rules backing up there.
When you want to call functions,
it's really just simple line
here. Call app.callFunction.
Here I've got a
specific function and you
can pass whatever
parameters you want.
So now let's jump into
a demo from our annual
developer conference
mongo DB dot live 2020.
We will do a quick intro into
what you can do with triggers
and functions. This demo is
presented by Drew DiPalma,
who is the product manager
for mongo DB Realm.
Hi my name is Drew and today I'm
going to give you a little bit
of a quick intro into what you
can do with serverless triggers
and functions in the mongo DB
cloud. Typically when we talk
about the different things that
you might build with triggers
and functions, we break it down
into four categories. First,
parsing and processing data,
taking data in your mongo DB
cluster and changing the format
a little bit as you integrate it
with other parts of your
application. Second, propagating
data, taking data as it's loaded
into MongoDB and ensuring that
that data is added to another
collection in your cluster or
 sent to other parts of your
ecosystem. The third is
alerting. Looking at data as it
changes was loaded into mongo DB
and sending an email or text or
maybe just an update to another
system noting that that change
takes place or looking for
particular values or types of
updates. And finally,
integrating into your
application. Really, the ability
to integrate your mongoDB cluster
with an application without the
need for a middleware or an
application server.
Let's actually dive a little bit
deeper. Looking 1st at triggers
in Atlas. There are a couple of
neat things that you can do, so
we've created a trigger here
that takes updates to your
collection and sends them to 
AWS event bridge. Now there are
two types of triggers we offer
in Atlas first are database
triggers and these listen to
changes to the database using
mongo DB change streams. The
second are scheduled triggers.
These are essentially functions
that fire on a specific
schedule that you can set with
Cron Syntax. For this trigger
you can see that it's enabled,
processing events in order.
And we're looking at inserts and
sending them directly to event
bridge, and this is really just
a very simple way to integrate
your database with event bridge
and build more complex event
driven architectures. You want
to build more sophisticated
function or trigger. We actually
offer more tooling for that in
Realm and create a Realm
application to that.
Let's look here. There are a
couple of different functions
that I want to show you. The
first is really interacting with
an API endpoint, so I've created
a function that interacts with a
API that provides cocktail data
using axcious a popular library for
making HTTP requests in node, and
I'm getting data from this end
point. Then I'm doing a little
bit of processing of the data
really, just since the
endpoint is pretty verbose.
Cutting down some of the fields
and reorganizing things a little
bit. I'm storing a tracking
event about this call in Mongo
DB and then I'm returning the
result. And we've got a nice
developer console in function
editor. You can see that this
shows the calls that I'm making,
shows a little bit of what I'm
returning and you can see that
that's a nice clean structure to
send back to the users.
Now what do you want to do
something a little bit more
advanced? So we've got a second
function here which sends
an alert, and there're actually
two types of alerts this is
sending one text message, the
other is email and doing a
little bit of a combination of
things. We're using Twilio NPM
package. We're hitting the
mailgun API with Axios and what
we're actually doing here is
using context, which is
something that's a little bit
unique to Realm functions. So
we're calling another function
within our function that creates
text template. And another one
that creates an email template.
We're using the Twilio client to
actually send that text message,
and then we're hitting the
mailgun API endpoint and these
are just a couple of examples of
what can do from functions to
really get some of that parsing,
processing, propagating data,
alerting and integrating in your
application logic. As you build
you've got that developer console 
that I showed you, also
integrate with GitHub to make
it easier to deploy and develop
locally and we have a rich set
of logging as well so you
can see exactly what's happening
within work requests, not only
how they're performing up to
actually use console dot log to
log information as well.
If you want to see a little bit
more about how to build
advanced functions and how to
integrate them with you, why
we've gotta talk on that? Check
out seven serverless functions
to impress your friends at
parties. Hope you enjoy
building some really cool stuff
with mongoDB Realm, mongoDB
Atlas and serverless
functions and triggers, thanks.
Finally, if you want to move on
from here, if you want to think
about building your own
serverless functions on top of
Mongo DB Cloud, then the code
from this is on the GitHub.
If you want to check it out, if
you want to use it as to
bootstrap your application, for
example. You can also learn
more about functions and
triggers on our documentation.
I really encourage you to go
and see all the other things
that you can build, whether
it's via mobile, as whether
it's looking at Graph QL,
whether it's something a
little bit more to more to
our authentication, and, uh,
permissions and roles, there
really lot of great things
that you can build on top of
mongo DB with Realm.
I really want to thank you for
taking the time to listen to
this talk and I look forward to
seeing all the exciting things
that you build on MongoDB Realm.
