1 00:00:02,140 --> 00:00:07,520 So first of all, what is stitch, what is mongodb stitch? 2 00:00:07,540 --> 00:00:14,710 It's a serverless platform for building applications you could say, it's a collection of services offered 3 00:00:14,710 --> 00:00:18,780 by the mongodb company that you can use when building an app 4 00:00:18,820 --> 00:00:26,140 and with app, I mean basically a web app or a mobile app or also a desktop app, so that you get to focus 5 00:00:26,380 --> 00:00:32,590 on your user interface and your core logic even the logic which should run on a server, 6 00:00:32,620 --> 00:00:39,100 so on a backend but you don't have to write the entire boilerplate for setting up the server, for managing the 7 00:00:39,100 --> 00:00:46,570 server or for example for creating a restful API on your own, that is all handled by stitch. It all is 8 00:00:46,570 --> 00:00:54,450 kind of built around Atlas as a cloud database or at least integration with that is particularly easy 9 00:00:54,970 --> 00:00:58,130 and one core feature for example is authentication. 10 00:00:58,300 --> 00:01:04,840 Now here I'm not talking about users for the mongodb database as we manage it thus far, 11 00:01:04,840 --> 00:01:09,970 you remember in the last module we created a couple of users that could interact with the database and 12 00:01:09,970 --> 00:01:17,110 we used the user with the read write access in our node application and we had to use it in the node application 13 00:01:17,260 --> 00:01:21,000 so that the credentials don't get exposed in our user interface. 14 00:01:21,020 --> 00:01:24,910 Now I'm not talking about this kind of database authentication, 15 00:01:25,070 --> 00:01:32,110 I'm talking about the authentication we have in our app to support users or even if we don't want users, 16 00:01:32,380 --> 00:01:34,860 even in such a case, there is a solution. 17 00:01:35,050 --> 00:01:44,170 Now why is that important? Because stitch gives us access to our mongodb Atlas database and this 18 00:01:44,200 --> 00:01:50,430 access will then be available from inside our client side application, for example. 19 00:01:50,470 --> 00:01:57,460 So for example in our concrete case, it will be available in the react app. Now in the last module I mentioned 20 00:01:57,460 --> 00:02:03,330 that we shouldn't access the database from in there because we don't want to expose our database credentials. 21 00:02:03,340 --> 00:02:09,580 Now the idea behind stitch's solution here is that it doesn't expose our database credentials, 22 00:02:09,580 --> 00:02:17,800 instead our application users can sign up and log in through stitch's service and the user will get 23 00:02:17,830 --> 00:02:24,460 temporary credentials for finegrained access to the database and we can lock down what a single user 24 00:02:24,460 --> 00:02:25,050 can do, 25 00:02:25,060 --> 00:02:30,760 so we could say a user is allowed to insert documents into this collection and there, he may set that 26 00:02:30,850 --> 00:02:34,160 and that field, this field may not be changed by the user, 27 00:02:34,180 --> 00:02:40,210 we can lock that down and I will show you how to set up such rules in this module. And therefore, we can 28 00:02:40,320 --> 00:02:45,400 pass the authentication or the rights to the users of our app because they don't have full access to the 29 00:02:45,400 --> 00:02:50,570 database as they would have with our mongodb credentials which are not exposed. 30 00:02:50,710 --> 00:02:56,920 So stitch manages this behind the scenes for us, that it takes our rules into account and make sure 31 00:02:56,920 --> 00:03:02,920 that users do have access to the database but only to exactly the things they have to do like create 32 00:03:02,920 --> 00:03:05,780 new products which they did in the last module too 33 00:03:05,850 --> 00:03:06,480 but there 34 00:03:06,500 --> 00:03:10,470 we controlled access through node, now stitch does this. 35 00:03:10,510 --> 00:03:12,710 So this is one important piece. 36 00:03:12,820 --> 00:03:15,820 We can also react to events in stitch, 37 00:03:15,820 --> 00:03:21,760 so for example if something gets inserted into a database or something gets updated, we can run some 38 00:03:21,760 --> 00:03:28,780 code that does something, sends an e-mail or log something into another collection or whatever we need to 39 00:03:28,780 --> 00:03:29,360 do 40 00:03:29,650 --> 00:03:35,940 and that's the third building block, we can execute code or some kind of functionality in the cloud. 41 00:03:36,010 --> 00:03:43,660 So stitch is not just a toolset which helps us build beautiful UIs or client side code, we can still 42 00:03:43,810 --> 00:03:47,020 execute code in the cloud with so-called functions, 43 00:03:47,020 --> 00:03:53,080 so essentially just code snippets which we define where we don't have to write the boilerplate of parsing 44 00:03:53,110 --> 00:04:00,730 incoming requests or exposing routes in a restful API but where we just write a code we want to execute 45 00:04:01,030 --> 00:04:07,270 and then we can either call that code directly from inside the client or from inside another function 46 00:04:07,720 --> 00:04:12,880 or we set up a trigger with that middle position there, react to events, 47 00:04:12,880 --> 00:04:18,470 we set up a trigger to execute a certain code snippet when for example something gets inserted. 48 00:04:18,490 --> 00:04:20,170 So we're really flexible here 49 00:04:20,320 --> 00:04:26,530 and if you worked with something like firebase or AWS Lamda, well then this function part on the right 50 00:04:26,530 --> 00:04:32,140 here would essentially be Lamda or firebase cloud functions and mongodb stitch as a whole 51 00:04:32,290 --> 00:04:35,560 is kind of mongodb's answer to firebase 52 00:04:35,560 --> 00:04:43,150 you could say, if you know these tools. Now in detail, for accessing the database, we got stitch query 53 00:04:43,240 --> 00:04:48,880 anywhere which is their solution to allow us to run queries based on the rules we set up for the users 54 00:04:48,880 --> 00:04:51,480 of our app directly to our database. 55 00:04:51,690 --> 00:04:55,360 There also is mongodb mobile which I'll not touch on in this module, 56 00:04:55,390 --> 00:05:00,440 mongodb mobile is basically a local mongodb database 57 00:05:00,460 --> 00:05:06,820 you could say which you can install on mobile devices so that you can store data and sync it to the cloud 58 00:05:07,540 --> 00:05:09,130 even when you are offline, 59 00:05:09,130 --> 00:05:13,080 so store the data when you're offline, sync it to the cloud when you're back online. 60 00:05:13,090 --> 00:05:16,440 That is a whole different topic and I'll not cover it here. 61 00:05:16,570 --> 00:05:21,280 React to events, that is stitch triggers, that's simply the name of the service which allows us to configure 62 00:05:21,310 --> 00:05:25,150 triggers that will then call stitch functions 63 00:05:25,150 --> 00:05:30,730 and additionally there's a feature called stitch services which allows us to integrate stitch with other services, 64 00:05:31,030 --> 00:05:33,830 like for example AWS S3, 65 00:05:34,000 --> 00:05:39,280 that would be useful for uploading files because stitch has no built-in file storage, 66 00:05:39,280 --> 00:05:44,050 so we got no solution for storing files, mongodb itself is a bad solution, 67 00:05:44,050 --> 00:05:48,970 a database should not be used as a file storage and there is no other service that would allow us 68 00:05:48,970 --> 00:05:49,930 to store files. 69 00:05:50,140 --> 00:05:57,340 and that could be solved by using stitch services reach out to AWS S3 which is a file storage and 70 00:05:57,340 --> 00:06:03,580 then communicate with that and store files and you find plenty of examples for such use cases in the 71 00:06:03,580 --> 00:06:05,530 official stitch documentation, 72 00:06:05,530 --> 00:06:09,960 so definitely dive into that if you're interested in more details. 73 00:06:10,030 --> 00:06:12,250 So this is the big picture, 74 00:06:12,250 --> 00:06:17,290 we get our cloud database which we can work with with stitch query anywhere, 75 00:06:17,320 --> 00:06:23,900 we also got the events where we can listen to authentication or database events 76 00:06:24,110 --> 00:06:29,840 and then we can execute code in the cloud and we can always execute that code not just upon events but also 77 00:06:29,870 --> 00:06:31,800 call it manually. 78 00:06:31,870 --> 00:06:39,980 That is the idea here and the idea is that we build our client side application and we also have some 79 00:06:39,980 --> 00:06:42,910 server side logic still, we have some code that should run on the server, 80 00:06:43,010 --> 00:06:47,370 we also have our mongodb database or Atlas to be precise 81 00:06:47,540 --> 00:06:53,000 and in the last module, we built our own backend, the node rest API that talked to Atlas. 82 00:06:53,000 --> 00:06:55,830 Now this will be replaced with the stitch service you could say, 83 00:06:55,880 --> 00:07:01,700 so even though I called it serverless, there still are servers somewhere but stitch manages a lot of 84 00:07:01,700 --> 00:07:02,710 the boilerplate, 85 00:07:02,720 --> 00:07:10,430 a lot of the heavy lifting for us and we just communicate to our services, to atlas, to other services 86 00:07:10,430 --> 00:07:12,180 like database functions and so on, 87 00:07:12,290 --> 00:07:18,950 we do that with the help of the sdk. And now we can focus only on our user interface and our logic and 88 00:07:18,950 --> 00:07:20,540 not on all the boilerplate.