Introducing Stitch

Editor's Notes

• #2: Hi, Really excited to be talking to you all about Stitch right after the keynote Drew DiPalma. Cloud Product Manager…To give you a bit of background about myself Got my start working on a distributed database in Azure called SQL Data Warehouse Then came to mongoDB as a PM for Atlas As of late, I’ve been pretty focused on Stitch So. In this session we’re going to focus on getting to the next level of depth with the principles, code, and configuration of Stitch Hopefully this is going to make everything a bit more concrete for you and give you some thoughts on how you kickstart your next project with Stitch
• #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
• #4: 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.
• #5: **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
• #6: **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
• #7: 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
• #8: **Switch apps w/ clients? Now, to make this a bit more concrete…This is how I like to conceptualize how Stitch sits within your application. It sits at the center of your clients, services, and database, and lets you execute, orchestrate, and scale all of your application more easily. Stitch does this by building on top of a new or existing Atlas cluster, meaning that With Stitch three ways that you can build on top of your database: You can still build on top of Atlas directly, using things like MQL or all of the standard drivers, and you can continue to scale and configure your instance You can work with a new set of native Android, Javascript, and iOS SDKs. Taking the MongoDB language that you are already familiar with and extending them to new platforms. Finally, you can integrate with a whole host of services, covering everything from Authentication with Facebook or Google to sending push notifications with Google or messages with twilio, mailgun, or slack to using AWS services such as S3 (for storing data) … and of course there’s an Atlas service to cover all of your database operations You can even create pipelines that pass data in between services and mongoDB --------- How much time are you really saving here? Bolting things together is hard, make it into a story Dissect image and build up from scratch
• #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: We’ve actually got an app running off Stitch that you can access right now. It’s a restaurant search/review app called platespace that’s …. Show App and show pipelines… Now I want to take time to show you how quickly you can integrate this into your app and how easily you can get started
• #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 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: 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.
• #14: A pipleline is a multi-stage operation built out of partner service and database actions. So for an example, let’s say that you had two services – MongoDB and Twilio. You could create a pipeline that uses both of these services. Now, you can actually create pipelines in the UI and then reference them in code later, but right now I’m going to show you how you can simply build a pipeline directly in your application. So, Pipelines are built up in simple stages. Let’s say in the first stage you want to you want to find all the users within your database that are in Chicago – this can easily be accomplished with a simple find statement. Now, with the second stae you want to send all of those users a message, let’s say telling them that it’s going to rain. But how do you transfer data from on stage in the pipeline to another? Well, Stages lave a let clause that allows you to define values for a stage, but what you actually need is a way to bring in data from the previous stage, and we can do this with expansions.
• #15: So, here are two simple expansions, %%vars, which allows you use a variable defined in the let clause of the stage and %%item, which allows you to leverage data from the output of the previous stage. Together these expansions allow you to easily find a subset of your users and send them a targeted message. But expansions aren’t just limited to this, in fact they open up a whole slew of outside data that can be incorporated into your pipelines.
• #16: There are really 4 types of expansions that we’ve included in this launch, and they can be used in everything from rules to pipelines. We’ll start with… Global – Global values that span across all pipelines and rules User – information aobut the User including authentication and metadata MongoDB – Access the the current and previous states of fields and documents Stage-specific – Stage specific variables, Reference data in prior stages, and even kick-off nested pipelines within the current rules or pipelines And with all of this you can really see the value of pipelines and services really expand. To Re-iterate, pipelines: Can contain service or database actions Can simply string together stages and pass information between them Can easily bring in outside information or call nested pipelines You can really see that with this framework you can begin to push a lot of your logic and computation off of your devices and into Stitch. In the long run this is going to help you: streamline your functionality over lots of different platforms Adapt and upgrad functionality or integrate new services all without changing the application code or adding new infrastructure (or, on the other hand, accomplish at the client level even more quickly without looking at ) And as a reminder, you don’t need to build your whole app on stitch, you can bring an existing database or application and begin to add to it right off the bat. And, while we’ve been talking about pipelines in your application, they can be easily defined at the UI as well as within the code Now, with all of this power and flexibility, you want to make sure that you are being really precise about access to your services and underlying data. This is where rules really come into play…
• #18: In MongoDB Stitch we have the ability to create precise rules that cover all the major surfaces of your application – MongoDB, services, and pipelines. For MongoDB, you can create read, write, and validation rules And for other services you can create rules that precisely define when the service can be run, allowing you to limit service actions, paramaters to the services and the types or roles of users executing those services Rules are defined with the same simple JSON that you use for pipelines. So, for example you can create a simple read/write rule that check is the user id of the authenticated user is equivalent to the user that is defined as the owner of the document. Meaning that a user can only read or write documents that they own. You can also create more complex rules that contain conditionals and expressions, even including pipelines. For example, if this were defined as a write rule it would allow users to edit documents that they owned OR create net new documents. To make this a bit more concrete, let’s talk about how the rules work in action. ------- Differentiate between MongoDB and Service Rules Rules are declarative, easy to write and powerful For MongoDB, Read, Write, and Validation rules at the document or field level
• #19: 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
• #20: 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
• #21: 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?
• #22: 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.
• #23: Defining field level rules for Atlas is as simple as going into the Stitch UI and defining a specific database and collection And let me know that we’re very focused on safetly with Stitch, so all reads and writes are off by default. You get to explicitly turn on and control everything. After defining your namespace, you go and add specific field and then you can define read, write, and validation rules for each field. Or just for the document as a whole if you don’t need that level of fine-grained control.
• #25: We’ve actually got an app running off Stitch that you can access right now. It’s a restaurant search/review app called platespace that’s …. Show App and show pipelines… Now I want to take time to show you how quickly you can integrate this into your app and how easily you can get started
• #26: Now, as you all know, Stitch has just been released in beta today. 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
• #27: 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!