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 "API and Auth Modules" 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 reviews a few Auth and API methods provided by AWS Amplify.

Get Unlimited Access Now

Transcript from the "API and Auth Modules" Lesson

>> Steve Kinney: So, we used a few things earlier. I just wanna kinda take a quick moment, we saw them in action but kinda want to talk about them now. We were in the weeds dealing with them, and now I kinda want to step back up to the ivory tower and take a look at them again.

[00:00:13] So we used that width authenticator component, and that basically did everything, and it's like kind of interesting. If you use your app dev tools you can actually see it's basically a state machine. It's like, nothing in terms of signing up. Then it moves into now they're gonna sign up flow.

[00:00:29] And now it's waiting for confirmation code. And it kinda handles all these different states. It's great cuz we can just pull it out of the box. You can theme it. But depending on what you're working with, especially if you wanna have routes for your sign in. For all the different states that that authenticator component was in, it wasn't clear through the URL.

[00:00:50] And so there might be different things that you want to do with that. So it's like, hey, I just need a simple sign up form that's got everything I need, cool, great. If you have something kind of a little bit more specific that you need to do, you can actually just pull the Auth module from AWS amplify, just a generic JavaScript library.

[00:01:09] And that module like API has a bunch of methods, and those methods are useful for just doing a whole bunch of stuff kinda by hand. So like there's a sign in method, and you send it like a user name and a password. And it will like resolve or reject.

[00:01:23] If you want to implement sign out, like you can have a button that like when they click it. It's just Auth that sign out and then what you want to have happen in that case. For every high level, it's some black magic component there is a lower level that you can access as well.

[00:01:42] So some of Auth. And then if you need some information from the user like in this case, the user name or something along those lines, you can get a lot of that information from off that current authenticated user, which will go ahead and get you all that information.

[00:01:58] Or you can get like Auth that current web session which is the adjacent web token. So it's all the kind of actual credentials that they need to, all the stuff that is checking along those line,s is available for you as well in this Auth current section, right? We took advantage of the fact that MFI wired a lot of it up for us, right, but if you needed it for something in particular you can actually pull out that information as well.

[00:02:25] We saw the API module. It has a whole bunch of methods. There's a few more than this but these are kind of the, I would say the most common ones. All of your HTTP verbs, so get, post, patch, put, and delete, all take the same arguments. There's another one that we'll see later today called GraphQL operation.

[00:02:47] GraphQL and it takes a GraphQL operation. And we'll see that one later like that's kind of a known other way to talk to a API but you need a GraphQL API. If only there was an easy way to make one and spin one up very quickly. Well cool, so again we talked about all those three arguments.

[00:03:04] There is apiName which is the name of the API gateway you wanna hit. Or the cloud API in our Mobile Hub parlance that you're looking for, the actual path at that API. So you can think about the API name as effectively almost like the name of the server, or like the Like domain name that you're hitting, and then the path is like everything past it.

[00:03:24] Like slash grudges, slash grudges, slash object, one two three will get you the one with the ID of one two three. And init is any other additional information that you need to send, so in this case, we saw header, like I just briefly mentioned but also body was really important for put and post.

[00:03:40] What is the information you'd like to save to the database? That's the kind of third object that we can send along with everything else. These are like what they're officially called under the hood. You might have seen Visual Studio codes typescript definitions kind of hinting at these things.

[00:03:54] But like effectively, name of the gateway, name of the path, any other stuff you want to send through. Getting grudges we saw, we just used the grudgeCRUD API and then we hit that end point, and we got back all of the grudges. Get an individual grudge as well we just need to give it the ID.

[00:04:14] We'll get that one back. For posting, we hit that endpoint and we hit the endpoint on the grudgesCRUD API gateway, and we need to send in a body of all the things that we wanna save. And those all get kind of passed through and put into the database.

[00:04:33] Putting and deleting we implemented, all right. Putting works very similar to post, where we send an entire body along with it. But again, Dynamo DB doesn't, this is not like dictated by Dynamo. This was simply the JavaScript code in that serverless express app that took like something, and turned it into a dynamo DB call.

[00:04:56] So you could actually, this is what we got out of the box, but like I said a bunch of times you could go in there and manipulate and do whatever you want. It's kinda up to you. And deleting is very similar to getting a single one. But like I said, any request to the API gateway that matches.

[00:05:14] The verb and the endpoint is gonna trigger that route, and you could change like what exactly those routes are like how it works, all that kind of stuff. Whatever works for you. But generally speaking, if you're just trying to get something up really quickly, it behooves you to kinda go with the conventions.

[00:05:30] I mean for me, part of the argument is it's great to have a very scalable infrastructure with very little work. The second I start to get very opinionated and change things they don't really care about. Especially in a more complicated app, you're likely to abstract this in other API calls, anyway, right?

[00:05:44] It might be in a Redux Epic, or Redux Thunk, or something along those lines. And you're just firing the actions, anyway. You write this code one place. You don't really care. But if there's additional stuff, default things that you need, you can put that all in that code.

[00:05:57] That's definitely stuff that you can do, as well. The point is, you get some really great default options but if you have custom needs, this is real industrial strength infrastructure.