The underlying AWS mobile CLI used in this course has changed it's API. If you're starting to learn AWS, you may want to try the latest course. We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.

Check out a free preview of the full Rapid Development on AWS: React, Node.js & GraphQL course:
The "AWS Mobile Hub CLI Setup" Lesson is part of the full, Rapid Development on AWS: React, Node.js & GraphQL course featured in this preview video. Here's what you'd learn in this lesson:

Steve leverages AWS Mobile Hub to configure a backend authentication service.

Get Unlimited Access Now

Transcript from the "AWS Mobile Hub CLI Setup" Lesson

[00:00:00]
>> Steve Kinney: So as we switch back over to our terminal, I have the AWS Mobile CLI tool installed globally in node. And we can use this tool to, basically, configure, push, pull down publisher applications. Basically, work with all of our applications in AWSmobile hub. So the first thing that you need to do if you haven't done it already.

[00:00:26] So we're just got to have AWSmobile and configure. Now, when you hit the enter key, you're getting I'll ask the bunch of questions. Remember when I told you download that CSV of credentials? It's gonna basically ask you for those. It's like okay, I'm ready to work with AWS.

[00:00:46] Now, who are you? What's going on? I'm just a tool that you installed off the internet. Please log in and tell me what you want me to do. So in this case, once you have all that information ready to go, I have that offscreen because it's going to be impossible for me not to let that secret slip at one point.

[00:01:06] But generally speaking, you want to keep your secret keys secret. There's lots of tools out there that go through public Github requests looking for different keys. That's something we have to do deal with all the time, which is someone publishes their secret key and then some spammer uses it to send 10 billion spam emails running up that customer a huge bill.

[00:01:26] So we try to find them first and shut down those API keys. It happens. So we do AWS mobile configure, all right? And we try it out. And you can see it's just gonna as you three questions and you only need to do this once. It's gonna ask you for your access key, all right?

[00:01:40] That was that first one that wasn't hidden on that page. So we kind of put that in. You can see I've already logged in once and it remembers it. And then again, it'll ask you for your secret key which is a slightly longer key that you're not suppose to show on the screen to a while bunch of people at the same time.

[00:01:58] Let it sit there for a second. Cool, you want to put that one into that. Again, if you're done with the CSP that's the next column over or if you're still on that page you can hit show and get that secret key and you should be good to go.

[00:02:10] And then finally, what region you want to use. It's generally speaking if you are not sitting in the United States of America right now, you probably want to pick the region closest to you. Generally speaking, you want to pick the region closest to you. If you really don't care us-east-1 is usually a good bet.

[00:02:28] It is, arguably, I believe it's the oldest one, it's got the most features. But it is also because it is kind of the biggest and most popular, also the most volatile. Beyond the scope of this workshop, is multi region. Which is a thing, like at SunGrid, we have the main region that we run our code and then we have all of our code deployed to a second region.

[00:02:48] Replicating that database in case one AWS region goes down, we can fail over to the other region and have as minimum agg as possible. While we are building a scalable infrastructure today, let's not get ahead of ourselves. [LAUGH] That is tricky and hard, we're going to deploy scalably to one region and when the VC money rolls in, then we will begin to deal with the idea of multiregion.

[00:03:12] We'll pick one region, I'm gonna pick us-east-1 but again, I recommend picking whichever one is closest to you, us-east-one is northern Virginia, us-east-2 is Ohio. West One is I believe Northern California and West Two is Oregon. We're currently standing in Minneapolis, which is kinda like right in the middle, so take your pick.

[00:03:36] In Denver, where I live, it's a little closer to the west but I still pick US East One. Umm, cool. And that's it, we've now configured the AWS mobile tool. We can now use it to initialize new maps. We can use it to interact with AWS Mobile Hub in those applications.

[00:03:52] You do that once on your computer you're good to go.
>> Steve Kinney: So the next question is how do we set that up in a particular application? So we have this application, it needs a backend and some Authentication and authorization. So let's give it a shot. So we are in this grudges repo.

[00:04:13] And if you have an application, and you're like, this application is wonderful. It needs a backend, we can go ahead and we type awsmobile in it, right? And this will initialize a new AWS,
>> Steve Kinney: Backend for this application. One thing I'm gonna do real quick is I'm just gonna make sure that I don't have an old folder in here.

[00:04:45]
>> Steve Kinney: It's going to create two source files and you already have a sneak peak as to what those are going to be. But we'll go ahead and we'll start a brand new application in this case and we'll do that AWS mobile.
>> Steve Kinney: init.
>> Steve Kinney: This is gonna ask you a bunch of questions.

[00:05:05] The command line tool is smart enough to know that we're in a React app and it's create React app which is a boilerplate for React applications. So, it knows how to work with it and deal with it. So, we don't have to make a bunch of decisions. There's actually a hidden trick if you, we're going to hit enter, just say yes to everything but if you do -y.

[00:05:22] It will actually just answer yes to all the questions and not bother you with them but I want to show you what the questions are. So, I'm not gong to do that but in the further we might be like, yeah, just dash Y. If you find yourself just slamming the enter key over and over again, dash Y is probably a friend.

[00:05:39] Fun fact, if you use MPM, you MPM in it, you hit those questions, dash Y or dash dash yes will do the same thing there as well. So what are the questions that we get asked? Okay, where is your project source directory? And it's taking a lucky guess that it's in this SRC folder, which if I look, that is where my source code lives.

[00:06:02] Very cool. All right, where is your projects distribution directory that stores build artifacts? That is a very complicated question that's basically, when this application is built, what folder do you build it into? We have never built this application before. Create react out of a box built to a build directory, which it guessed correctly.

[00:06:25] Sometimes there'll be a dist directory or an out directory depending on your application's configuration. If it's in webpack, then it's usually in your webpack config what folder you build to. This case, build is gonna be the one that we have. You can see this one is Gitignore but it is the like build artifacts for when I compile my web application.

[00:06:46]
>> Steve Kinney: So we'll go with yes on that one. What is the script for building it? A lot of MPM maps, basically that's defined in the package J-son. So if we go in here, you can see Start, build, test, and eject. These are not very helpful because create react app kind of abstracts all of that so they can change it under the hood.

[00:07:06] But if you have your own React application, you might actually have very specific commands in here. You might be like Web pack, dev server for start, which is web pack for the build. And kind of figuring out all of that stuff. But in this case, start, build, test and eject.

[00:07:23] For those of you who have never used create reacta before, eject is like, hey, all this stuff where you hide reality from me. I don't like it. Right, [LAUGH] and it will, basically, open the curtain and show you what's going on under the hood. But for simplicity's sake, we gonna hide as much complexity as possible.

[00:07:40] Because, again, a lot of this stuff is complicated to begin with. All right, cool. So build works, a test for starting. It's gonna be MPM run-script start. Very cool. What project name you want to use? It's gonna try to generate a unique name for you. This is based on the directory, the current date and time, which I guess unless you create two applications in the same directory at the same, I think it's down to the second, is probably going to be unique.

[00:08:12] Cool and so you can see, it's creating a back end for our AWS mobile project. So we'll give that second. And it's basically creating a few folders for us. You can kind of see it along the way there. It's also installing, if you look right now. This yarn add aws-amplify, that's the library we talked about before, that allows us to talk to AWS Mobile Hub.

[00:08:39] It's also going to separately, for some reason, install aws-amplify-react. Why it didn't do both at the same time, I don't know. It knows you want amplify and then it goes to check probably for your react app. I don't know, we can all read the source code together during our break, it'll be a lot of fun.

[00:08:56] So there it tells you what it did. So it created a AWS mobile JS folder and in there a AWS mobile directory and that is it's own like working directory for keeping track of stuff. Your job is not to touch them Awsmobilejs in a current backend info, which is basically the last time they talked Amazon, what it things your backend is as you work locally.

[00:09:22] Awsmobilejs slash backend, is the backend code that actually runs everything for you. Now, this was generated for you. But, you're welcome to tweak it as much as you want. You need to do custom stuff and change your back-end this is the back-end code and when you push it up, you tell Amazon like hey make these changes to my code and it's like okay go for it, and it applies it all.

[00:09:46] Right, so both your back-end code and your front-end code live in the same repo. Now, this is great because all your code is together, and you can configure backend right next to your front end. It's also JavaScript has this unique problem, which is if you have a Ruby on Rails backend, you know you're working on the backend if you're writing Ruby.

[00:10:07] And you know you're working on the front end, if you're writing JavaScript or coffee script, if you write a reels, but whatever. With JavaScript, because you can write JavaScript on the backend and JavaScript on the font-end, and now they're very close together, that's great in a lot of ways.

[00:10:22] Cuz you can share code, have a lot re-use, it's also [LAUGH] slightly confusing, because sometimes you can lose track if you're in the backend of your co-base of the frontend because it's all JavaScript the whole laid down. So Double-edged sword awsmobile console will actually open up the web UI, we'll take a look at in a second.

[00:10:41] Awsmobile run will effectively push your backend changes to Amazon and then it will go ahead and do an mpm start or yarn start on your application. Mpm and yarn are effectively they're different package managers and they're also script runners. Anytime you see me type yarn start, you can probably just type mpm start.

[00:11:01] It's the same way, same either way, they're just different package manager, getting stuff from the PM repository. Whichever one you're more comfortable with is totally fine. The only place where the syntax is different is when we go to install new dependencies. But all the dependency in this application are already installed, so Effectively and will correct this if I've overlooked something.

[00:11:26] If you have npm on your system, you see me type yarn or vice versa, I'm gonna tell you a secret about me, I use them both back and forth, I will use yarn add and then npm start cuz I'm a terrible person. So you can use either one.

[00:11:41] It's totally fine for our cases. And then awsmobile publish is going to take your project and it's gonna put it on the Internet. It's gonna deploy it with a single command, and just basically take all your back-end, spin it up for production and get it rocking and rolling.

[00:11:58] Cool, so now we have this kind of back-end code. Ready to go, we haven't told our application about it. But I showed you that slide before with some features, I kinda wanna show it to you again. And what we'll do is we'll kinda take a look. And we'll just go type awsmobile, and I'm gonna type nothing.

[00:12:16] Now this by itself doesn't do anything, it's just gonna show you all the options.
>> Steve Kinney: So here are the commands you can type. AWS mobile start, which is start AWS mobile using one of our starter templates. If you go to the actual website, you can see they have a swift starter kit, they have a bunch of basically pre-built apps.

[00:12:37] Init is the one we ran, which is kinda turned an existing project into a AWS mobile project. Pull says hey Amazon, tell me what you think my backend is cuz if you go into the web UI and change a bunch of stuff well your code on your computer doesn't know about it.

[00:12:53] So you have pull it down effectively think about get push and get pull. Speaking of push will basically send my code up to the cloud. The cloud is just a nice way of somebody else's computer. It's the same thing. In this case Amazon's many computers. Delete is like this whole app was a terrible idea.

[00:13:11] Take it all down. We're closing up shop. I'm not doing this anymore. That's effectively what delete does for you. Published as we saw before puts it on the Internet, run will push up your code and then run it locally. Console will basically fire up that AWS web UI, you can see a bunch of stuff and modify some stuff there.

[00:13:31] Configure is going to change some of the settings, like we saw we set up our account before, we put in our access key and our secret ID before features is definitely the one we want to look at next. And help is effectively useful for the rest of these, as we can pull up a different feature.

[00:13:47] So it kind of shows you what the Amazon, the EWS mobile features are. I want to point out that if, you know, it's a month from now, or two months from now. And this list looks different, it's because is changing, like this tool came out in November, [INAUDIBLE].

[00:14:01] I believe it was but it came out in November of 2017. So it is about six months old. And even when I started preparing for this, AppSync wasn't on that list, right? So, that is new somewhat recently, I actually open up a poll request because in all the doc examples they show you all the features appsync isn't on there in the docs yet.

[00:14:24] So, that's how quickly some of the stuff is changing. But the kind of major things, you can see how this could be very important for a building a full stack React Node application. We have user-signin, user-files which is the ability for the user to upload files publically or kind of name space them privately.

[00:14:41] Cloud api, which is s way to spin up an api gateway and then some lambda functionality to figure out, okay this endpoint is hit, now what? A database for persisting data which we're definitely going to need. Analytics, we're not going to be using it today, but I told you about it earlier.

[00:14:56] It's like basically, you can have all sorts of different tracking events and you can actually fire your own custom tracking events. Hosting which is how we're gonna put on the internet. App sync, we're not gonna use amplifiers and I'll tell you the reasons why in a little bit.

[00:15:08] But basically, it's a way of speeding up the app sync service as well. Cool. So we've done an initialization of it. The only thing we haven't done, we created a file which we'll look in a second called AWS exports, that is all of our configuration, very cool. And then we have another one, that directory that we saw earlier, right?

[00:15:31] Those things are set up, but my react application, the code from, it didn't go in and change my application. You can be like, yeah, why write my application for me. Generally speaking, let's leave the programming to the programmers. Right, it's done enough for us. My react application still doesn't know About this AWS application.

[00:15:51] So what we need to do is basically tell the React application that all this AWS stuff exists. We'll actually take a look at that and try it out. Now, we see it made this AWS exports file but it's a very helpful warning at the top saying DO NOT EDIT.

[00:16:10] Your mileage may vary. You can choose to listen to that or not. I am a rule follower, so I don't edit it. I can't tell you what happens if you do edit it. It probably just blows away your changes cuz it told you not to edit it. And then next time you make a change but this is basically all of the Amazon configuration that your client-side app needs to know about.

[00:16:31] So, okay, analytics are enabled, our cognito identity pool, so on and so forth. What region we're in and what cloud front domain we're going to use. The analytics FID, so on and so forth. Don't touch these. These are just what your client setup needs to know to figure out where it needs to talk to when you do heroically deploy it to the Internet.

[00:16:55] This AWSMobileJS. This is where your backend lives and again, it can get sometimes confusing like this happen to me where it's. I'll tell you a more embarrassing version of where this happen to me in a second but like you think you're changing client side code, you're changing back end code and wondering why nothing is working.

[00:17:10] The more embarrassing version of this as somebody that used to teach web development, is you're writing documentation and you have a code sample in your documentation. And you keep changing the example in your documentation and wondering why your code isn't changing in your application. That's the more embarrassing version of that [LAUGH] because you're changing it in a marked down file, not in a JavaScript file.

[00:17:31] So this is our current backend and the only one we're really gonna touch is this backend directory. And right now, there's not really a lot there, there's just more configuration about how our backend is actually formed. As we build this application, we'll see a little bit more in there but for starters, this is gonna remain somewhat simple, as we add features, it'll get slightly more complex.