1 00:00:01,290 --> 00:00:06,540 Now that we are all done with the main phase of authentication inside of our application I think that 2 00:00:06,540 --> 00:00:11,580 we are at a pretty good spot where we should think about deploying our application off to Roku again 3 00:00:12,000 --> 00:00:16,690 and deploying all this new code that we have now added to our project before we do so. 4 00:00:16,690 --> 00:00:22,010 However there's one quick thing that I want to mention to you about exactly how our application is set 5 00:00:22,010 --> 00:00:22,790 up. 6 00:00:22,830 --> 00:00:29,100 So as a reminder inside of our config directory we've got that piece not just file and this file contains 7 00:00:29,190 --> 00:00:36,540 all of the different configuration API keys you our eyes cookie keys all this stuff around our application. 8 00:00:36,570 --> 00:00:41,530 So the way that we're set up right now is going to eventually maybe lead us into a little bit of trouble. 9 00:00:41,580 --> 00:00:43,170 And let me tell you why. 10 00:00:43,380 --> 00:00:46,510 At present we've got one set of all these keys. 11 00:00:46,620 --> 00:00:51,270 I'm going to suggest that we should instead have two separate sets of keys. 12 00:00:51,270 --> 00:00:57,330 So in the development development world like on your laptop on our laptops on our active development 13 00:00:57,330 --> 00:01:04,530 machines we should have one set of keys for Mongo D-B for our Google API and for all the cookies that 14 00:01:04,530 --> 00:01:10,500 we're handling and then we should have a completely separate and different set of keys for our production 15 00:01:10,500 --> 00:01:13,910 environment which would be our Heroku deployment. 16 00:01:13,920 --> 00:01:20,250 So there's two very good reasons for taking this approach of having the two separate sets of keys. 17 00:01:20,250 --> 00:01:25,650 The first reason is that when we use production keys like this we can store all these keys remotely 18 00:01:25,920 --> 00:01:32,870 on Heroku servers all the developer keys can still remain on our own personal laptops. 19 00:01:32,880 --> 00:01:39,660 Now this is a very good approach because our developer laptops like your physical laptop right now it 20 00:01:39,660 --> 00:01:45,780 is not at all outside the realm of possibility that you might at some point in time lose your laptop 21 00:01:45,810 --> 00:01:47,500 or really have it stolen. 22 00:01:47,520 --> 00:01:49,430 And that's what I'm really talking about. 23 00:01:49,440 --> 00:01:56,010 So on your local machine right now you have a plain text file with all of these different API keys. 24 00:01:56,040 --> 00:02:01,680 It is not outside the realm of possibility of someone stealing your laptop finding this file right here. 25 00:02:01,680 --> 00:02:08,250 And then all of a sudden having direct access to your Mangu database the entire Google API or at least 26 00:02:08,250 --> 00:02:13,680 your slice of it and be able to decrypt any keys that you or any cookies that you have issued to your 27 00:02:13,680 --> 00:02:15,070 users. 28 00:02:15,870 --> 00:02:20,910 Now if you have a separate set of keys for production that is only stored on Heroku then it doesn't 29 00:02:20,910 --> 00:02:25,720 matter if your laptop gets stolen or someone grabs the contents of this file right here. 30 00:02:25,860 --> 00:02:31,590 If someone finds your test database credentials will whatever just delete the test database and start 31 00:02:31,590 --> 00:02:32,890 over again. 32 00:02:32,910 --> 00:02:38,130 So again one reason that we're going to split off to having two separate sets here is that allows it 33 00:02:38,130 --> 00:02:41,910 allows us to be a little bit more willy nilly or a little bit more relaxed. 34 00:02:41,910 --> 00:02:46,860 I should say with our development credentials Now the other reason that we're going to split this into 35 00:02:46,860 --> 00:02:52,420 two sets of keys is that allows us to have two separate Mongo databases. 36 00:02:52,650 --> 00:02:58,490 And that is very important whenever we deploy our production or application to production. 37 00:02:58,530 --> 00:03:05,190 We want to have a clean database existing in production that has only our users data and we always treat 38 00:03:05,190 --> 00:03:11,860 that as absolute pristine data that we will never manually mess around with at any given time. 39 00:03:11,970 --> 00:03:17,250 But in the development world if we have a separate database we can decide to add records and delete 40 00:03:17,250 --> 00:03:22,130 records we can delete collections we can create collections we can change everything. 41 00:03:22,140 --> 00:03:29,310 As much as we want without having any fear of accidentally breaking all of our users production data. 42 00:03:29,310 --> 00:03:34,860 So having two sets of keys like this and two sets of resources is a great way to make sure that you 43 00:03:35,130 --> 00:03:41,340 can do development on your local machine and not accidentally break some very important pieces of your 44 00:03:41,340 --> 00:03:43,320 production application. 45 00:03:43,320 --> 00:03:48,720 Now I do want to make sure that's really clear the vast majority of all production applications in the 46 00:03:48,720 --> 00:03:51,450 world should do. 47 00:03:51,450 --> 00:03:55,430 I'm going to say do or at least should take a similar approach to this. 48 00:03:55,440 --> 00:03:59,450 So if you're working at a company that has you working on development with production data. 49 00:03:59,640 --> 00:04:01,740 I'm sorry I've got to say that's kind of dangerous. 50 00:04:01,740 --> 00:04:02,830 Just my opinion. 51 00:04:03,000 --> 00:04:08,940 Maybe you've got some one off case but off the top of my head I'm going to say it's kind of dangerous. 52 00:04:08,940 --> 00:04:09,160 OK. 53 00:04:09,180 --> 00:04:14,850 So anyways our goal here is to separate out the two separate sets of keys and now just to kind of dive 54 00:04:14,850 --> 00:04:17,880 into the details of exactly how we're going to handle this. 55 00:04:17,910 --> 00:04:22,190 We're going to look at one other diagram right here. 56 00:04:22,440 --> 00:04:26,610 And we looked at this diagram a little bit of go a little bit ago when we initially put together that 57 00:04:26,650 --> 00:04:32,090 he's not js file and we said that we were going to do a refactor to it at some point in the future. 58 00:04:32,400 --> 00:04:36,260 So here's what's going to happen inside of our key file. 59 00:04:36,300 --> 00:04:40,770 We are no longer going to store all of our raw API keys. 60 00:04:40,950 --> 00:04:46,710 Instead we will ask a little question are we currently running in our development environment or our 61 00:04:46,710 --> 00:04:48,220 production environment. 62 00:04:48,390 --> 00:04:52,980 And then depending on which one we're running we're going to return a different file. 63 00:04:52,980 --> 00:04:54,910 So in one case we'll return dev. 64 00:04:55,010 --> 00:05:01,510 Yes and the other case will return maybe like proj us and inside of that file we will reference a bunch 65 00:05:01,510 --> 00:05:03,600 of different environment variables. 66 00:05:03,790 --> 00:05:07,930 So we have to talk about exactly what these environment variables are and how we're going to set them 67 00:05:07,930 --> 00:05:08,920 up on Heroku. 68 00:05:08,980 --> 00:05:10,230 But that's pretty straightforward. 69 00:05:10,360 --> 00:05:12,510 So right now let's take a quick break. 70 00:05:12,520 --> 00:05:17,620 When we come back in the next section we'll start putting this structure here together and then one 71 00:05:17,620 --> 00:05:23,170 other quick thing that I want to say just to make sure it's clear we are going to have to set up a separate 72 00:05:23,170 --> 00:05:27,520 Mago database to separate Google's API count and the separate key. 73 00:05:27,550 --> 00:05:29,770 So yeah sometimes it's a pain to do all this stuff. 74 00:05:29,790 --> 00:05:33,430 But again there's a very good reason to go through all of it. 75 00:05:33,490 --> 00:05:37,760 So let's take a break and then take care of all this stuff in the next section.