MongoDB Stitch Introduction

Editor's Notes

• #3: When you are building an app, you have an idea and your goal to translate that into an experience as quickly as possible, and this is true whether you’re creating the next billion $ startup or incrementally building on top of a production system ….unfortunately there’s a lot of ground work that goes into this and there are a few things that we tried to target specifically with Stitich Since you’re all at a database conference, I’m going to assume that working with data is at the top of your mind. So your new app is going to have to effectively work with your data, either data in an existing database or data generated by your applications To do this you’re going to need to manage a bunch of database infrastructure and scaling, …but you’re also going to need to make sure that your database is serving the right data to the right users. Nothing more and nothing less. **Switch apps w/ clients? On top of that you need to work with a growing host of 3rd party services. It used to be that you needed to write your own authentication, push notification, photo storage, or e-mail sending, but now there are 3rd parties that handle these operations cheaply, effectively, and at any scale However, you need to: write the code to integrate with these services, coordinate data movement between your database and these services in a safe and efficient manner and keep up with any changes that they make on their side **Switch apps w/ clients? Finally, you need to safely and scalably serve requests for all the clients out there… This requires making sure that you can scale the actual request processing hardware and deal with peaks and troughs in demand, But also that you can work with all of the latest devices and platforms, whether it’s the latest phone, browser, or whatever comes next All this adds up to many, many of lines of code, and hours working to set everything up, Not to mention all of the maintainence that need to be consistently done, and the overhead of keeping up This really gets us to the core of what we’re trying to tackle with MongoDB Stitch, seamlessly joining the database and service interactions and bringing them closer to the client layer, allowing you to tie everything together in a simple, unified way Because we build a lot of different things on top of MongoDB, we’ve created MongoDB Stitch to help you orchestrate all of these pieces, and make it easier for you to translate your idea into an experience
• #4: At it’s Core… Stitch provides a REST-like API to MongoDB with full access to CRUD and aggregation functions It’s accessible by a set of native iOS, Android, and JS SDKs that preserve the MongoDB syntax you know and love. On top of this, it’s also integrated with a whole set of 3rd party services You can the also organize all your complex actions through pipelines And best of everything sits on top of a set of comprehensive rules, leaving you in full control of your data without introducing more overhead Access to data, safely and managed in Atlas to abstract management of backend Security (Differential Privacy rules ) Flexible Programming/Access (SDKs, Pipelines, Database Access) Service Integration MongoDB Stitch is… A scalable, managed Backend API + Services Integrated Read/Write/ Validation Rules … with key services So let’s zoom out and see how this all fits together The API is what makes the BaaS useful, as it allows to store and query data, run server-side code, authenticate users, and more. This is usually implemented as a multi-tenant cloud service on an Infrastructure-as-a-Service (IaaS) provider such as AWS. As a developer, build your website or mobile app using either a REST API or an SDK. The high abstraction layer of BaaS often comes at a cost: performance, expressiveness and scalability are usually quite limited. But this does not have to be the case. Let’s look at how to actually build a BaaS. – Not the case here
• #5: The database must be highly available, which is extremely difficult if you also like consistency, according to the CAP theorem. The server needs to be scalable, which is difficult when shared state such as user sessions are involved. All the heavy lifting involved with scalability and high availability is now shifted to the Database-as-a-Service. All of MongoDB Full feature set Not just key-value store Scale up or out Retain traditional access methods No lock-in Be aware: at start of beta, works with Atlas in AWS US region 2
• #6: **Switch apps w/ clients? So, now let’s take a look at how a typical request flows through Stitch. First a client makes a request. Depending on the request, this can be a simple database operation or a long, complex pipeline The request is sent to Stitch, and if it’s a write request then Stitch immediately checks it against its write rules. If a write request is not permitted, it won’t even get sent to the database Next Stitch coordinates the actions that are being executed with all the services involved. It may simply reach out and request data from Atlas, or complete a more comlex interaction that requires it to pass data between the database and other partner services. After these actions are complete, Stitch checks the final data set against the read rules. Here any data that the end user is not permitted to see is filtered out, and done so in a way that ensures that they do not know what data has been removed. Finally, Stitch passes the appropriate data back to the clients
• #7: **Switch apps w/ clients? So, now let’s take a look at how a typical request flows through Stitch. First a client makes a request. Depending on the request, this can be a simple database operation or a long, complex pipeline The request is sent to Stitch, and if it’s a write request then Stitch immediately checks it against its write rules. If a write request is not permitted, it won’t even get sent to the database Next Stitch coordinates the actions that are being executed with all the services involved. It may simply reach out and request data from Atlas, or complete a more comlex interaction that requires it to pass data between the database and other partner services. After these actions are complete, Stitch checks the final data set against the read rules. Here any data that the end user is not permitted to see is filtered out, and done so in a way that ensures that they do not know what data has been removed. Finally, Stitch passes the appropriate data back to the clients
• #8: **Switch apps w/ clients? So, now let’s take a look at how a typical request flows through Stitch. First a client makes a request. Depending on the request, this can be a simple database operation or a long, complex pipeline The request is sent to Stitch, and if it’s a write request then Stitch immediately checks it against its write rules. If a write request is not permitted, it won’t even get sent to the database Next Stitch coordinates the actions that are being executed with all the services involved. It may simply reach out and request data from Atlas, or complete a more comlex interaction that requires it to pass data between the database and other partner services. After these actions are complete, Stitch checks the final data set against the read rules. Here any data that the end user is not permitted to see is filtered out, and done so in a way that ensures that they do not know what data has been removed. Finally, Stitch passes the appropriate data back to the clients
• #9: **Switch apps w/ clients? So, now let’s take a look at how a typical request flows through Stitch. First a client makes a request. Depending on the request, this can be a simple database operation or a long, complex pipeline The request is sent to Stitch, and if it’s a write request then Stitch immediately checks it against its write rules. If a write request is not permitted, it won’t even get sent to the database Next Stitch coordinates the actions that are being executed with all the services involved. It may simply reach out and request data from Atlas, or complete a more comlex interaction that requires it to pass data between the database and other partner services. After these actions are complete, Stitch checks the final data set against the read rules. Here any data that the end user is not permitted to see is filtered out, and done so in a way that ensures that they do not know what data has been removed. Finally, Stitch passes the appropriate data back to the clients
• #10: **Switch apps w/ clients? So, now let’s take a look at how a typical request flows through Stitch. First a client makes a request. Depending on the request, this can be a simple database operation or a long, complex pipeline The request is sent to Stitch, and if it’s a write request then Stitch immediately checks it against its write rules. If a write request is not permitted, it won’t even get sent to the database Next Stitch coordinates the actions that are being executed with all the services involved. It may simply reach out and request data from Atlas, or complete a more comlex interaction that requires it to pass data between the database and other partner services. After these actions are complete, Stitch checks the final data set against the read rules. Here any data that the end user is not permitted to see is filtered out, and done so in a way that ensures that they do not know what data has been removed. Finally, Stitch passes the appropriate data back to the clients
• #11: Getting start with an app like I just showed is easy, we’re going to skip ahead of installing the js sdk, and you just start by creating a new Stitch client instance and pointing it to the Atlas instance that you linked to Stitch After that you can point it to any database and collection within your instance Now, to make a request, you just need to authenticate the client From there you can use simple and familiar syntax to access your data. You can pretty much complete whatever CRUD options you like within the code The same way that you define and work with MongoDB can also be extended to other patner services. It’s quite simple to link a service to Stitch in the UI, and then reference it and kick-off actions in your application code.
• #12: Getting start with an app like I just showed is easy, we’re going to skip ahead of installing the js sdk, and you just start by creating a new Stitch client instance and pointing it to the Atlas instance that you linked to Stitch After that you can point it to any database and collection within your instance From there you can use simple and familiar syntax to access your data. You can pretty much complete whatever CRUD options you like within the code The same way that you define and work with MongoDB can also be extended to other patner services. It’s quite simple to link a service to Stitch in the UI, and then reference it and kick-off actions in your application code.
• #13: Getting start with an app like I just showed is easy, we’re going to skip ahead of installing the js sdk, and you just start by creating a new Stitch client instance and pointing it to the Atlas instance that you linked to Stitch After that you can point it to any database and collection within your instance From there you can use simple and familiar syntax to access your data. You can pretty much complete whatever CRUD options you like within the code The same way that you define and work with MongoDB can also be extended to other patner services. It’s quite simple to link a service to Stitch in the UI, and then reference it and kick-off actions in your application code.
• #14: Getting start with an app like I just showed is easy, we’re going to skip ahead of installing the js sdk, and you just start by creating a new Stitch client instance and pointing it to the Atlas instance that you linked to Stitch After that you can point it to any database and collection within your instance From there you can use simple and familiar syntax to access your data. You can pretty much complete whatever CRUD options you like within the code The same way that you define and work with MongoDB can also be extended to other patner services. It’s quite simple to link a service to Stitch in the UI, and then reference it and kick-off actions in your application code.
• #15: See with Stitch, all you need to do is provide the identifying information for your service, such as a key. Stitch stores and encrypts these keys so there is no need to have a separate management service for your application. Once the link is made you can reference these services and use pre-built actions to reference them from your code. For instance you can: Create a slack service and post a message to slack Create a twilio service and send a text message with twilio Or even do something more complex, like creating an S3 service and using it to upload data to S3 You can even use our HTTP service to integrate your own favorite service or API Now, the great thing is that these actions don’t live in isolation, they can interact with each other to produce complex interactions, and this is where pipelines come in.
• #16: Of course, MongoDB and Atlas have authentication & authorization built in but that is actually authenticating the application rather than the users of the application. That left the developer to code their own layer to control which users can see and write what. Stitch has implemented that layer, all you need to do is configure what collections, documents, or individual fields a user can access. This can be based on a unique attribute of the user’s data (such as their ID), some attribute such as their role in the enterprise, or something more complex such as their age being 18 or greater. The default behavior is that an end user can read and write just the data that they’ve added. In the example shown, the receptionist can read and write appointment data; they can also read test results. The doctor has read and write access to all of the medical data for the patients they’re responsible for. The nurse can see what appointments they have scheduled and record test results. Finally, the researcher can’t access any patient data directly, instead, they have permission to view the results of some pre-approved, anonymized aggregations that let them look for trends or corelations (such as between location, age, and cancer rates. This is all configured through Stitch’s browser-based GUI.
• #17: Getting start with an app like I just showed is easy, we’re going to skip ahead of installing the js sdk, and you just start by creating a new Stitch client instance and pointing it to the Atlas instance that you linked to Stitch After that you can point it to any database and collection within your instance From there you can use simple and familiar syntax to access your data. You can pretty much complete whatever CRUD options you like within the code The same way that you define and work with MongoDB can also be extended to other patner services. It’s quite simple to link a service to Stitch in the UI, and then reference it and kick-off actions in your application code.
• #18: Getting start with an app like I just showed is easy, we’re going to skip ahead of installing the js sdk, and you just start by creating a new Stitch client instance and pointing it to the Atlas instance that you linked to Stitch After that you can point it to any database and collection within your instance From there you can use simple and familiar syntax to access your data. You can pretty much complete whatever CRUD options you like within the code The same way that you define and work with MongoDB can also be extended to other patner services. It’s quite simple to link a service to Stitch in the UI, and then reference it and kick-off actions in your application code.
• #19: Of course, MongoDB and Atlas have authentication & authorization built in but that is actually authenticating the application rather than the users of the application. That left the developer to code their own layer to control which users can see and write what. Stitch has implemented that layer, all you need to do is configure what collections, documents, or individual fields a user can access. This can be based on a unique attribute of the user’s data (such as their ID), some attribute such as their role in the enterprise, or something more complex such as their age being 18 or greater. The default behavior is that an end user can read and write just the data that they’ve added. In the example shown, the receptionist can read and write appointment data; they can also read test results. The doctor has read and write access to all of the medical data for the patients they’re responsible for. The nurse can see what appointments they have scheduled and record test results. Finally, the researcher can’t access any patient data directly, instead, they have permission to view the results of some pre-approved, anonymized aggregations that let them look for trends or corelations (such as between location, age, and cancer rates. This is all configured through Stitch’s browser-based GUI.
• #20: So lets make the benefit of rules a bit more concrete. Let’s say you’re builing a banking app (now, I’m going to use banking as an example, but we see this pattern across pretty much every vertical.) So, in this app we have 3 types of users: First, we have end customers who need to be able to read all of their account data Next we have tellers, role-based users who need to be able to access some, but not all, or an end user’s data. Finally we have Analysts who need to view aggregate infromation (say…the total value of the banks assets, the balances at different branches, or analyze demographic information about users) Typically to satisfy all of this you would need to take your database, build a who set of roles and permissions on top of it and then build a separate application layer. You’d probably even want to build a separate datamart for your analysts, which adds all the infrastructure and logic of keeping two systems in sync. Now, you can bake all of this into Stitch with simple rules that can be defined to adapt as your system grows and can be easily changed. --- Familiar with MongoDB role based rules, underline the value in addition to what currently exists
• #21: So, let’s talk about how this all plays out in action. A customer will ask to see their account details, making a request to Stitch. Stitch will then grab the document from Atlas and then check it against the existing read rules. Here we have a few read rule – first the user profile can only be read if the requesting user matches up with the user on the document. This checks out. Next the balanace and transaction fields can only be read if the requesting user is the document owner OR if a pipeline checking the role of the user evaluates to ‘teller’. Because the document matches with all the read rule, the whole account will be returned to the user. Now, what happens when a teller wants to look at the same data? ---- Explain pipeline/current role Pipeline
• #22: For a Teller… A Teller will look to grab a customer’s account details, making a request to Stitch. Stitch will then grab the document from Atlas and then check it against the existing read rules. First the user profile can only be read if the requesting user matches up with the user on the document. This is false, maybe the user profile contains sensitive information that shouldn’t be available to all tellers. If you wanted to expand this later, it would be easy to add an additional clause that opened it up to certain tellers, or even a differect role – say a financial advisor. Next the balanace and transaction fields can only be read if the requesting user is the document owner OR if a pipeline checking the role of the user evaluates to ‘teller’, and since this user is a teller, it evaluates to True. Now Stitch passes the pieces of the document that the user is able to read, omitting the user profile in such a way that the user doesn’t even know what data they are not permitted to read. Now with rules like this it’s easy to define access based on a whole host of users roles, criteria, and metadata. You can define this at the document level or the field level, and you can bring in additional data from expansions to make the rules more powerful…but what about for the aggregate case that we described?
• #23: For the analyst, they may need to view aggregate data, but don’t actually have access to any of the base documents. What you can do is define a special pipeline for these users, coupled with a rule that only allows it to be run by the analysts in question. This allows them to make a request to Stitch that reaches out to Atlas and can take many of the documents within the database and run aggregations on them or process them with the help of other services. Then Stitch can pass the ata back in an aggregate form that is appropriate for the Analysts. One of the best pieces of rules is how easily they can be defined in the UI.
• #27: The purpose of the pricing is to be simple and transparent. Customers should be able to pay in the same ways as for Atlas. Firebase has a complex planning scheme with 3 different plans. For each plan, there are limits, costs across 20 different dimensions. E.g. you pay for storage, uploads, download, invocations, authentication requests,… Meteor have 4 prepaid plans + pay as you go (paying for a computing instance). No free tier. Support is extra
• #28: Now, Stitch has been in beta for a bit now. Up since the beta we’ve been laser focused on increasing the stability and scalability of the product as well as improving some core usability pieces, such as user management We think you can use it to build some pretty amazing things right off the bat, but I also want to give you the first sneak peak at what our focus is going to be for the foreseeable future. First, we wanted to make Stitch available For MongoDB users everywhere This means expanding Stitch hosting to other cloud regions and providers But it also extends to self-hosted and on-prem instances. We want Stitch to help you build on your data no matter where it resides. Next is enabling realtime for Stitch For everyone at the keynote, I’m sure you heard about the change notifiation work that is coming We’re working super closely with that tealm to build realtime data and even pipelines for Stitch. So, whilte others have hacked together realtime on top of MongoDB, we’re going to do this in a way that is really optimized for the database Finally, we are laser focused on making sure that Stitch has all the capabilities to make developers successful This is going to include everything from from code deployment and versions Continually improving our debugging infrastructure And finally continuing to advance our
• #29: So, now that we’ve gotten a chance to talk a bit about Stitch…what next? Well, if you’ve got time this afternoon one of our developer advocates and I will go even deeper with Stitch and show you how to build the app that I demo’d a bit earlier But regardless, try out Stitch ASAP, it’s 100% free during world and then after that the first 25 GB of data downloaded is free, and each GB after that is only $1! And, even though I’m not going to be able to take any questions during this sessions, please take a look at all the code and docs that we’ve released and come by the Stitch booth. I’ll be there alongside a lot of the engineers who brought Stitch to life. So thanks again for taking time to learn a bit more about Stitch, now go and create something cool!