Hybrid Cloud Development with Next.js, AWS, and Tailwind

So, as long as everyone can see this, that's great. This is the workshop materials that we're going to go by. And it's kind of broken up into two main parts. There's the actual README, which is kind of like the tutorial and documentation itself for the workshop. And this is what we're going to be following along with. So everything in this README, of course, is just kind of displayed here. And the way that this is going to work is that we're going to just kind of walk through this step by step and build out this app. Now, everything in this workshop should be copy and pasteable. So all of the code should work, you know, as expected, I guess you could say. So, of course, when you're doing a workshop like this, it's often recommended to not copy and paste it, to actually type it out. But if you do run into like a bug or something like that and you can't figure out if you did something wrong, you can always kind of resort to that. And then the other thing that is here is the actual completed project. So you can actually go into this amplify next folder right here and you should see a completed version of the project. So if you do get stuck somewhere between actually copy and pasting the code and running it yourself or going into this completed project, you should kind of be able to kind of not get stuck. Or if you do get stuck, you should be able to get unstuck. So take that into consideration kind of when you're building this up. And with that being said, I guess I'll go ahead and give an introduction and kind of talk about what I'm doing and who I am and stuff like that. So my name is Nader Dabit. I've been a senior developer advocate on the aws Amplify team for a couple of years now. And the name of the team is aws frontend Web and Mobile. And I started there in 2018 in January and actually worked there up until last Friday. So last Friday was my last day at aws. And now I'm working at a new company called Edge and Node, which is kind of in the graphql and web3 and crypto DeFi space. But I'm still going to be doing a lot of aws stuff. I'm not like not doing that anymore as well. So I'm kind of like now going to be doing this new world of things, which is kind of like the decentralized DeFi web3 and kind of like even crypto space a little bit. But I'm also going to be continuing to do aws stuff. I still have my book, react Native in Action and Full Stack serverless. Full Stack serverless B2 is coming out in a couple of months. So yeah, I'm going to be keeping up with all that stuff. But yeah, this is kind of my first workshop I'm giving where I'm not an employee of aws, but I still am really, really excited and kind of like passionate about this technology. And I kind of have seen the potential of it, the growth of it, all of the big companies like picking it up and stuff. And it's exciting to be part of this space as well. So I'm just wanted to kind of throw that out there that I'm not really like going anywhere. So what I'm going to be doing is kind of like switching between my terminal, the workshop and my text editor and building along and you can follow along. And there's a couple of ways to follow along. And we were talking about this earlier in the Slack or Discord earlier. You can either follow along and try to build this out step by step with me. Or you can actually take this workshop and watch me build out the first hour or the full three hours and then go and build it yourself after that. It's kind of up to you. It's completely up to you. You can follow along. You can do this later after you kind of get an idea of how this all works. You can actually like get ahead of me. So if you're like building and I'm going too slow because I'm trying to kind of, you know, with over 100 people, it's kind of like you have to just draw a line somewhere where you're going to be a little bit too fast for some people, a little bit too slow for other people. So, you know, I'm not expecting everyone to kind of like follow along exactly. But, you know, feel free to go ahead or feel free to fall behind. And I would not worry about it because, again, everything should be able to be copy and pasted. And hopefully the value that you get out of this is kind of being able to ask questions of me explaining the things from my perspective of being within this technology for a little over three years. And then the other thing is that since this is a an open source project, you can actually just submit issues or pull requests. So if you have any questions or issues, you can submit these and hopefully like I can answer those within like 24 hours or something like that. I'm going to be keeping a close eye on the workshop for the next week, at least as far as issues are concerned. So if you kind of run into any issues, feel free to open up an issue. Feel free to also reach out to me on Twitter and ask me any questions that you might have if you run into any issues. Cool. So the prerequisites for this are essentially going to be kind of like already your basic development environment. If you're a front end or a full stack developer, so you're going to need that JS installed and which will automatically have npm installed. Other than that, you just need to have an aws account and you need to have the aws account activated. Now, for me, for the last three years, I've always been using my aws account for as an employee. So today I'm using my own personal aws account. So hopefully like if I run into any issues or you'll run into the same issues, but I've already tested this stuff out. You shouldn't run into any issues. But I guess what I'm saying is like me and you, we're all like working on the same, you know, the same stuff with the same credentials and all that stuff. You know what I'm saying? So I'm going to be I'm not operating like from the perspective of an aws employee anymore, which is which is fine. OK, cool. So yeah, the one thing I would recommend is once you've kind of like, you know, once you're ready to start building, just go ahead and sign into your aws account. And you should see a dashboard like this. And we're going to be kind of like, you know, going back and forth a little bit there. So that's that's that. Before we get started, does anyone have any questions? And if you do, feel free to ask them. And I'm going to see if I can open up. I have the discord open. Looks like I have the Q&A open and I have the chat open. So I don't know where the best place to ask questions are, but maybe discord would be a decent place for me to keep an eye on. Someone asked, will a recording of the session be available? And it looks like it will be, which is good. OK, cool. So let's talk about what we're going to be building. We're going to be building a full stock app with next.js, Tailwind and aws. And the aws technologies that we're going to be working with are aws Amplify. And under the hood, it's going to be Amazon DynamoDB. It's going to be aws AppSync, which is a graphql api service. We're going to be working with Amazon S3 for image storage. And we're going to be working with Amazon Cognito, which is a managed authentication service, something like Auth0 if you've ever used that. And we're going to be using the next.js features that a lot of people like really enjoy and that they're excited about. So for a while, if you were a react developer, a front-end developer, we had a kind of a big explosion of this single page application type of app. And everything that was happening in that whole, I would say, like, renaissance of like maybe front-end web development where we had all these great single page application frameworks coming out like angular, we had Ember, react, you, all these other ones. The next thing that we kind of saw happen in this whole ecosystem is the jamstack, which was kind of like static site generation mixed with a little bit of dynamic. And then what you're kind of seeing now is kind of like this progression past jamstack into kind of like Guillermo Rauch, the guy that founded next.js in Brazil, kind of had a really interesting talk about it at Next.com, kind of like talking about what's coming past jamstack. And it's kind of this hybrid approach. And that's kind of what we're going to be taking advantage of. Where we're doing a combination of static site generation, ssr, we're also going to be doing dynamic data fetching on the client. And kind of when you build something, you can take advantage of the things that work the best for the use case that you're working with. So instead of saying we're going to be 100% bought into a single page app, or we're going to be bought in 100% to a static site generated website, we're going to instead combine these things and kind of see where they work best and kind of take advantage of those things. A couple of people are asking about ssr. So ssr is like a topic within, you know, I guess whatever technology stack that you're working with, and then there's always the question of like, what is supported, what isn't supported and things like that. When you're working with Amplify, and you want to work with ssr, there are two main areas where you kind of have to take into consideration. One is ssr hosting. So when you're actually deploying the next JS site, you want to have, you know, the api routes and ssr and all that stuff working. So that's like the hosting side. And then the other is the client library side where you actually want to be able to make the client side or even the server side api calls to the different aws services, like AppSync, like api Gateway and all those things. And you want to make sure that those are working on the server. So as of like today, like as we speak, Amplify supports ssr on the client completely, meaning that you can When I say the client, I mean the client libraries, which kind of again are often used on the server. So the client libraries, I guess you would say are supported ssr, meaning that you can call an api endpoint from an api route, you can call an api endpoint or authentication from an ssr route and from the client and it's completely like built in where we have, we deal with, you know, the sessions and the cookies and all that stuff for you. Then the other thing is the ssr support for the hosting. As of like right now, Amplify hosting does not support ssr. There is actually a preview version of this that you can use if you kind of sign up for it. So it's coming out in the next couple of weeks, maybe the next month or something like that. So in the meantime, if you want to deploy a next.js app and take advantage of ssr like we're doing, you have a couple of options. You can use, of course, something like Versel, which is kind of like built in with ssr support, which is great. A lot of people that are that are like building on aws like to stay on aws. So there's also other aws options. One option, of course, is to wait a couple of weeks until ssr support on Amplify hosting is there. The other option that we're going to be using today is going to be the serverless framework, which allows us to kind of really deploy this super easily to aws using like literally like one or two lines of configuration. And it's pretty simple to do that. And then the last option is if you want to actually deploy this into a container and Amplify also supports that. So if you wanted to deploy next.js to a container, you run Amplify add hosting and you kind of like set that up. You have to create your Docker file and all that stuff. Let me see here. I think I have a video or blog post or something going over this. Yeah, I have a blog post. So if you're looking to kind of deploy next.js to a container, you can use this. But what we're going to be using is containers kind of just it's great, but it's just kind of like a little bit overkill, I think, for what we're doing. So instead, we're just going to use a serverless framework. It's super simple and really good DX. Okay, cool. With that being said, let's take a look at the actual app that we're going to be building. How does the different hosting options affect pricing is a question that we got. They're all they're all going to be priced a little bit differently. Fargate, which is the container is like not serverless. So you're going to have to pay that would have like some type of pricing involved. I think there's a free tier there as well. But at the end of the day, it's not serverless. I kind of tend to. I tend to go for the serverless options these days because you're not going to pay for those unless they're actually getting a lot of usage. So the serverless framework is a serverless option and it's going to be a completely free tier. That's what we're using here. Amplify hosting ssr. That's going to be in the free tier as well in a couple of weeks. Okay, cool. So I just answered that question. I'm going to probably hold off on a couple of questions, but keep coming and I'll probably address those. What we're going to do is we're going to work until for another 35 minutes. So right now it's eleven twenty five a.m. And central U.S. time. I'm going to work until twelve o'clock. So for the next 35 minutes, we're going to work. Then we're going to take a 15 minute break. And during that 15 minute break, I'll try to address as many questions as possible. So what we're going to build be building is a multi user blogging app that allows you to create blog posts with Markdown. It allows you to upload images and put them like as part of your blog post. It allows you to edit and delete your existing blog posts. It allows you to view all of the blogs that have been created, all the posts that have been created by any user. Like if you went to medium or something, you would have like the main feed of all of the different posts. We're going to be building something like that you can think of. And then we're going to also have a separate view where when you're signed in, you can only see your own images. I'm sorry, your own posts. And you can also edit and delete your own posts. We're going to be implementing all of the different things that make this happen, including security, authentication, authorization, fine grained access control, all the stuff that you would typically need for any type of application. And I think like if you think about if you go back really far and think about when Rails became like really a big thing and it was kind of like a super awesome revelation and kind of mind shift and full stack development. One of the reasons was like you can actually use Rails and generate a project and do all of the stuff that you would need to do for almost any project. So when you think of like most apps, let's think about Twitter or Facebook or Instagram or many of these types of applications. When you're building out an app like this, they all are, you know, of course, different apps, but they have a similar core set of functionality that you can learn and then use and take and build all types of stuff. So that functionality is this. It's typically going to be some type of authentication and authorization layer. You have some type of data storage. You have some type of api access for that data. And then you also have some type of file storage. So you can kind of bucket those things into all data and storage. Now, if you can understand how to take advantage and build using these building blocks, you can actually build out probably 80 or 90% of the apps that most people have in their head. And then the other 10 to 20% are going to be like the things that might differentiate your app from everyone else. So I think like understanding how to build with these core building blocks sets you up for success and allows you to build all the stuff that you might want to build. So that's kind of like what I like to include in most of my workshops is how are we going to understand how to build all of these fundamental core features? And how can we actually build them in a way that is scalable? And when you're building something, a lot of times when you're getting started and just like learning how to do stuff, the last thing you want to worry about is scale. Because like in reality, like we're just maybe building out a demo app and we're just going to be playing around with it. But what if you could spend the same amount of time and effort building out something that could or could not scale? Like it doesn't matter like if it does scale, but if it did, it would continue to work and not not blow up. And I think that's the value that you get out of using something like a cloud provider like aws, because what we're building is like really, really going to be something we can get up and running in a few hours. But if you decided to kind of take this and run with it and you ended up with a million users, it would continue to work. I think that since we're using the same underlying technologies that Netflix and Amazon and Airbnb and all these big companies are using, it's really interesting that we can kind of build these abstractions on top of it to make it a little bit easier for people to get started with. And I think Amplify is kind of like the ultimate, that's the ultimate tool that we're kind of working towards. At least I was on that team and that team is still working towards to kind of lower that barrier to entry to cloud computing. So that kind of gives you a general philosophy around this workshop and the ideas behind it and stuff. And I also chose like a modern stack, so next.js and Tailwind, continuing to gain a lot of momentum. I think, you know, when you build with tools that are popular and continue to gain momentum, you get opportunities in your career and stuff. So that's kind of why I chose this. So this kind of gives you a general idea around the user interface. This is actually outdated. There's actually a place to upload a cover image now. So you create a post, you can write your post and mark down, you can preview the post. You can like view an individual post. We're going to have a profile view where you can kind of like see your user profile. You can sign out and kind of see, you know, your username and email address and stuff, just like many apps. And then we have this view here, which is kind of like the My Post view, where we're only viewing our own posts and we're able to edit, delete or view an individual post. All right. So with that being said, are there any major questions before we keep going? Someone asks, are we also going to use CloudFront for distribution in the workshop? Yes, the serverless framework that plugin that we're using uses CloudFront along with lambda Edge to kind of deploy all of the different features that you would expect out of next.js. And if we can kind of take a quick look at this component. And if we go to features, we can kind of get a good idea around the features. So I'll go ahead and paste this in. We have ssr rendered at the edge. We have api routes, dynamic routes, pretty much everything. The only thing that is missing, if you go to this link here, you'll see a few of the new features for next.js 10.0, which are in progress aiming for a 1.19 release. So not everything, but almost everything is supported. So get static props, get server side props and get static pods. We're going to be using all of that stuff. Does Will Amplify support incremental static site generation for next.js? Yeah, that's kind of part of the ssr support that we're working with. That support is actually already available for preview. So if you go into the Discord, you could probably jump in on that and try it out. It'll probably be available for actual production release in the next couple of weeks. All right, so that being said, let's continue on and we're going to go ahead and get started. So the first thing we're going to do is go ahead and create a new next.js app. So again, a lot of this stuff is straight up copy and paste. So I'm going to be doing some copy and pasting even with my code, but I'm going to be walking through it. So to create a new next.js app, I'm just going to run npx, create next app, amplify next. And I want my son's computer, Victor, to have it because my computer is owned by Amazon and I ordered a new one and it hasn't come in yet. All right, so after we create our next.js project, we should be able to just go ahead and change in there and see that we're in a basic Next app. And if you've ever worked with Next, you know, you're probably familiar with all this stuff. But let's say we wanted to kind of run this app, we could just run npm start, this should open it up on localhost 3000. At least it should have. I'm sorry, npm run dev, I think, for next.js. All right, so this is our base Next app, and we're going to be completely, you know, creating everything from scratch. But yeah, to run the app, npm run dev, and we're going to be doing that later on. So with our next app, we're going to go ahead and get started by installing our dependencies. So the dependencies that we're going to be installing are going to be amplify dependencies. We're also going to be installing a few other dependencies, and we're going to be installing Tailwind dependencies. Now, there is a way to create a next.js app that already has Tailwind installed and configured, which is great. But for me, for a workshop, I kind of like to show people how to do everything themselves. So like if you run into a project, you know, like how this stuff was set up. So we're going to be setting everything up like from scratch. And this is the way that I learned the best. And from what I understand, a lot of other people kind of learn this way as well. But just for just for future consideration, let's say you want to create a next.js app and you want Tailwind, there is an NPX command that you can kind of just run and get all this stuff configured for you. But what we want to do is let's just install our amplify and our other stuff, and then we'll install Tailwind separately. So what we're going to be installing is aws Amplify. This is the main javascript library for amplify. We're also going to be import installing the amplify UI component library. And there is a component library for vue, angular, react. I think that's it. And also react Native. And each of these has these UI components that are specific for that framework. Now, we could build this ourselves from scratch using just the amplify library, but it would take us a lot of code to kind of get up and running with a few core pieces of functionality. So one of those and the only one that actually we're going to be using is the authentication layer. When you build out an app, you typically need a way for people to sign up, sign in, sign out, reset their password, all this stuff. And it's typically the exact same like base business logic every single time. So for for getting up and running quickly, it's perfect for stuff like workshops. A lot of people actually use this in production. There's a UI component that we can use that literally takes like one or two lines of code to implement all of that. And that's going to be part of this library. So that's why we're installing that. The other two things that we're going to be installing have to do with Markdown. So when a user authors a blog post, we want to be able to allow them to kind of have some type of rich text formatting. Now, there's two ways to go about that. You can either use something like a WYSIWYG editor, which is like, you know, it stands for what you see is what you get. You see that a lot. And of course, like wordpress and other CMSs. But there's also Markdown, which is a lot simpler, I think, for a workshop like this, where we just want to kind of get something up and running. And we're going to be using simple Markdown editor, which kind of gives us almost like a combination between a WYSIWYG editor and Markdown, meaning that I can just write some text. I can highlight it, press a button and automatically like formats it for me. And then react Markdown allows us to just render that Markdown and display it in a nice way. And then UUID is a library for creating unique identifiers. In our case, we're going to be creating an ID to kind of like give a unique ID for a post. So let's go ahead and install that. And you can install this using either npm or yarn. I'm doing npm install here, but I'm going to instead on my computer to like yarn and just paste all these dependencies. All right. So we've installed our initial dependencies. Now we're going to install all the Tailwind dependencies. So we're going to be installing Tailwind as well as a couple of other plugins. One of them is the Typography plugin, and we're going to be kind of using this plugin to allow us to style our Markdown editor as like a parent class. So we don't have to kind of like write a bunch of css for that, meaning that like if there's an H1 or an H2 or some code, we want it to kind of be looking nice with some css. And this plugin allows you to do that pretty easily. So I'm going to go ahead and install those. I'm going to be using yarn. Of course, you could use npm as well. yarn is like a lot faster, at least it has been for me. All right. So still in that same directory. The next thing we want to do is initialize a Tailwind configuration. And this basically is going to create a file called Tailwind.config.js and maybe one other file. But this allows us to kind of get up and running with Tailwind pretty easily. So npx Tailwind init-p. So it looks like we're getting a post css config and a Tailwind config. The only file we're going to be playing around with at all is going to be this Tailwind config. So we haven't opened our text editor yet. So let's go ahead and do that because we're going to need to go ahead and configure something. That is cyberpunk, indeed. It's my favorite theme. So our project is here. And then when we ran that command, we got this file here and we got this file here. Tailwind config and post css config. We're going to be updating the Tailwind config. And here we want to add the plugin that we're going to be working with, which is this typography plugin. And all you have to do is just plug that into that array. The array was already there. We just kind of added one item. And we're good to go. So we can go ahead and close that file. We won't be using that again. The next thing we could do is completely empty out our styles slash global css. So we're going to delete all that. And we're just going to add these three Tailwind classes or Tailwind imports, whatever these are. Basically, it's kind of like going to do a reset and then it's going to give us some base, all the different classes and stuff that have to do with Tailwind. And then when we want to use Tailwind, we can just basically, I think, import that into our project. All right. And I guess since next.js, I think, already imports this, we go to pages slash index. There we go. So it's already imported into App.js. So we don't really have to do that actually. So we're done configuring next.js. We have our base projects going. So now we need to move to the Amplify stuff. So the way that we're going to be interacting with aws is via the Amplify CLI. Amplify is kind of made up now of a few pieces, a few parts, and they can all be used individually or they can be used together. So the three main parts, I think, are going to be the Amplify command line interface or the CLI. The CLI is what we're going to be using to create, update, delete, and modify aws services. So if we wanted to create a database, we could run a command from the CLI and it would create that database in our account. If we wanted to create an authentication service, we could run a command line command and it's going to do that. It's going to create that authentication service. So that's kind of like the flow where we're kind of working from our CLI and we'll run like an Amplify, like do something and then it'll do that. And it'll also create like a local artifact that we can use in our local project. So it's great for full stack development. And then the CLI is going to create artifacts like let's say we create an api endpoint. It's going to actually create a file locally with that api endpoint. So we can then just import that using the Amplify client library. So that's the other part. So the CLI, you create services. The client libraries is what you use to interact with the services. So if you've ever worked with HTTP requests, you've probably worked with something like Fetch or Axios. If you've ever worked with graphql, you've probably worked with something like the apollo client. Those are examples of like HTTP client libraries that send requests to different, you know, endpoints. The Amplify client libraries, you could kind of bucket in that same category of tools in the sense that they are created specifically to interact with aws backends. We're going to be interacting with we're going to be interacting with things like a graphql endpoint. We're going to be interacting with things like an S3 bucket. We're going to be interacting with things like an Amazon Cognito user pool, which is kind of like an authentication service. And those credentials are going to be stored locally, and we just kind of use the client libraries to interact with those. And the CLI and the client libraries work pretty well together because when the CLI creates or updates something, then it creates the local, you know, endpoints for those things that were created. And then you can consume those and use the client libraries. So that's kind of an overview of the CLI, but we're going to kind of, of course, learn a lot more when we use them. But to use the Amplify CLI, you know, once you have it installed, you'll be able to just run Amplify. You'll see kind of like, you know, a bunch of different commands that you can use, but it needs to be installed first. And if you're if you're using a Mac and you're not on an M1, I would recommend using curl because this is going to install a much faster version of the CLI. And I don't know for sure if this M1 has been fixed yet or not, like where you can use this command. But I know the last time I checked this command only works on Mac and Linux. That's not our Mac. That's not the M1. And then it should also work on Windows. If you are on an M1, then you want to use the npm install dash G. So this is kind of the only time you would use the npm installation is if you're like on an M1. If not, I would recommend the curl. So you would just like run this command. So if I copy this and just go to my command line and paste it, it's just going to install the Amplify CLI. And this CLI is like four times faster, I think, than the npm version. So, you know, executing that command, you should have the Amplify binary. You should be ready to go to the next step. So I mentioned that we're going to be creating aws services from our CLI. Now, how does that actually work in, you know, in real life? Well, if I was signed out of my aws account and then I signed in as like this user and I wanted to go and like create a lambda function or something, I am essentially creating this function on behalf of the signed in user, meaning that I've authenticated myself and I am creating this. And if I wasn't authenticated, then I wouldn't be able to do that. And if someone else was authenticated, it would be creating on behalf of that person. So we are signed into this dashboard and we are creating things based on the fact that we are that person. How can we associate a user that is like in a signed in console but do that locally? The way that we do that is we use a combination of like a key value pair where we have an access key ID and a secret access key that kind of acts on behalf of a user. And to make that work, we need to do two things. We first need to actually go into our aws management console here and create that user. And then we then need to go back to our CLI and set that user somewhere locally. So when we run Amplify add, it can then go look up that user. Now, the way that that essentially is going to be done, the CLI is going to do that for us. So let me kind of walk through and just show you where this stuff is added in your local machine. And you don't have to follow along with this. I'm just kind of giving you an idea around where this stuff is. So if I go to like the root of my of my computer and I kind of examine, you know, well, let me actually open this window. If I examine all the different files and folders on my computer, I'll see that I have this dot aws folder. This was created when I ran Amplify configure for the very first time. If you've never run Amplify configure, this isn't going to be there unless you've already used maybe the aws CLI. If you have run Amplify configure, the CLI is going to create this folder. And if we go in there, we're going to see two new files. We're going to see a config and a credentials file. This is going to kind of hold the credentials for the user. So these are kind of like very secure credentials. You never want to expose these and let anyone see them. And the config is going to be kind of the name of that user. So the config might have like a value of Natter's CLI user. And then in credentials, there would be a reference to Natter's CLI user with the key value pair. So we want to create that key value pair for the first time. Or maybe you want to add additional ones. So the way that we do that is we run Amplify configure. So let's go ahead and do that. Amplify configure is going to first open up your aws management console. And if you're not signed in, it's going to kind of want you to go ahead and sign in. And then once you're signed in, you can go back to the terminal and continue. So it's kind of like saying, sign in to your aws admin account and then come back. Next, we want to specify the region where we want to create this user. I would just choose a region that is closest to you. So, for instance, Asia Pacific. We have Canada, US East, European Union. So I don't know the locations for all of these, but US East is kind of like the US East Coast. US West is the US West Coast. EU Central is Frankfurt, Germany. So it doesn't matter a whole lot. If you pick somewhere that's a little bit further than another place, it's not a big deal. Especially for this workshop, it's not a huge deal. I would just choose one that you feel is the closest. For me, that's going to be like US East one because I'm on the East Coast in Mississippi. Next, I want to go ahead and give the user a name. I would just kind of make this whatever you want, but let's make this a name that kind of resonates with what we're doing here. So I think I kind of set a name of Amplify CLI user. So I'll just go ahead and do that. So after we set that user, it's going to go ahead and open up in the IAM console. And this is going to be the identity and access management. This is going to kind of walk us through creating that user, which is then going to give us that key value pair. So when this opens up, it's going to automatically set up everything for us. We don't really need to change anything. We just need to go ahead and just click next, next, next and don't change anything because it's automatically going to kind of get it ready for us. So don't worry about what's going on here. But let's just kind of like give you just a brief overview of what is going on here. There's two ways to create a user. One is programmatic access, which is going to be that key value pair that I mentioned earlier. The other is console access. So let's say you wanted to create a user or your friend and you want them to be able to log into your account for whatever reason. But you didn't want to give them your actual username and password. You can actually create their own their own username and password. And that would be console access. But we're not doing that. We're only doing programmatic access. Next, we want to go ahead and attach permissions. So for Amplify, it uses dozens of different services. So you can either walk through and kind of create a permission list for whatever services you want that user to be able to access. But most of the time, we just say give them administrator access because there's a lot of different services that need to be accessed. And this way, it kind of makes sure that there are no issues. Next, I'm going to go ahead and click review. And then I'm going to see that we have the username, programmatic access, administrator access, and then I can click create user. Now, this is going to go ahead and give me the access key ID and that secret access key. This is what we need to now copy and paste in our Amplify CLI walkthrough. So to do that, I can go ahead and copy the access key ID first. So it's copied to my clipboard. I'm going to go now to my CLI. And I'm just going to paste that in here. And then we hit enter. And now it's asking us for our secret access key. So what I'm going to do is I'm just going to move this off screen a little bit. And I copy that to my clipboard as well. And paste that in. And now we've configured those properties. So I'm just going to go ahead and copy the name of the user that we gave in the actual aws console to be consistent with the name that we're going to be storing locally to reference that user. So this is kind of the local profile name. So once that is done, then you should have your user set up. Now someone mentioned that that was too fast. Let me go ahead and get a video that I actually created that walks through this again in about four minutes. And I'm going to share this. This is a video that kind of will walk you through how to go ahead and install and configure that CLI. And don't worry, we're actually going to also be taking a little break in about five minutes. So hopefully everyone can kind of get caught up at that point if anyone did get left behind. But the whole idea is like everything I just did like in the last two minutes is all right here. It's all in this this step right here. We run amplify configure, then it should kind of walk you through all the stuff that we just did. This along with that video should get you going. But I think like the initial configuration is something that takes some time, especially if you're new to aws and it kind of tricks people up sometimes. But after you're done with that, you never really need to configure your CLI again. You can create 10 projects, you can create a thousand projects, you can create a million projects using that one configuration. So you configure it once, you're kind of good to go unless you have a reason to create another user. Maybe you want to deploy in a different region or you want to kind of like give different access or whatever. But once you've run amplify configure once, you're kind of good to go. So we have four minutes left. So I think what we're going to do is we're going to run amplify and that's to go and create our first amplify projects. And then we're going to take a 15 minute break. All right, so let's go ahead and run an amplify create an amplify project. So after we run amplify configure and we kind of set up our user, we should be able to go run amplify amplify in it. And you typically are going to run amplify in it within the client project that you're working in. So if you're working with a mobile app, you can run amplify in it, you know, within that folder, iOS, Android, react Native, Flutter, all are all supported. If you're building a web app, it's just going to be in that main root directory. So if you're in a react app, it would be like one level up above SRC and next. Yes, we're in that root directory. Anytime you want to create a amplify app, just create that in that kind of like top level root directory. All right, so we're going to give the project a name. I'm just going to take the default there. I'm going to take the default name or the environment. And of course, you know, walking through here, a few of these things can be updated like with whatever you want. You can put whatever you want as the name or the environment name. But this other stuff that we're going to walk through like like the source directory path needs to actually be exactly what I put here. So we're going to see what that looks like for the for the actual default text editor. It's kind of up to you. I use Visual Studio Code. If you don't see your option there, you can choose none. I'm going to choose Visual Studio Code. For the app that we're building, I'm going to choose javascript. For the framework, I'm going to choose react. It would be cool if we had an actual next.js option there. But for now, we just choose react. For the source directory, since we're in next.js, there is no like SRC directory. All of the all the code kind of lives in that top level directory where we have the pages, we have the api and stuff like that. So we're just going to choose the top level directory as the root directory by just putting a dot there. For the distribution directory path. When you run a build, it's going to create a folder called .next. So we're going to go ahead and just set that as as the distribution directory path is .next. This is next.js specific. For the rest of the questions, we can just choose the default so we can choose npm run script build and run script start. We're good to go. And then I think the last thing here, this is going to be where we're able to choose that aws profile that we just created when we ran Amplify configure. So we can choose aws profile, we should now see we have the user that we created. So the user I just created with Amplify CLI user. So I can go ahead and just highlight that. And this is going to go ahead and initialize the Amplify project. And while this is happening, it is now we are now at the hour. So we've been doing this for an hour. Let's take a 15 minute break and come back at 15 minutes from now. So for me, that would be it's 12 o'clock every 12 15. And we'll I'm going to go ahead and try to answer some questions between now and then. If someone asked, are there any alternatives that you can use without CloudFront? The other alternative would be to probably use something like the container option that I mentioned earlier. That would definitely be another option. And I don't even know if you would be able to use Vercel because I believe they also use CloudFront. If you're working with the team, do you have to create IAMs with full access to every dev? You really only have to create an IAM role scope to whatever services that you want to use. So it's kind of up to you. If you know that this developer is only going to be making updates to, say, S3 or whatever, you could create a policy that scope to just those services and you should be good to go. Why Tailwind versus style components? That's a good question. I mean, I think style components is extremely, extremely good and powerful and popular. I think it's a very, very good option. I think if you look at the ecosystem right now, the top three, maybe even top four, you could say would be next.js. I'm sorry. As far as css stuff would be Tailwind, Chakra UI, style components and maybe even something like Emotion. So I think any of those are great. I'm kind of starting to just get used to Tailwind because it's so different than anything I've ever used. And it seems to be gaining momentum. And I kind of like got used to using Tailwind and it became very, very efficient with it. So I kind of have enjoyed it. But I'm not like one of those people that's like 100% pro using one thing over the other all the time. I'm kind of the type of person that's going to always be trying new things and seeing what works for me. I think right now the two that I use on all my projects are either Tailwind or Emotion. So but I don't think you can go wrong with anything that's like got to the point of popularity of style components. Can Amplify be used in conjunction with Next Off? I'm not sure. I would say that you can probably use Amplify. It is Federated Identities with Next Off, meaning that you could basically use it as like an authentication layer with Cognito Federated Identities, which is kind of like not going to work as good as some of the stuff we're doing. But if you're using Amplify, a lot of people like Next Off because they can do stuff like Google and Facebook authentication. You can actually do that really, really easily with Amplify as well. And it integrates well into the entire system. So I think one of the benefits of using something like Amplify or Firebase even is that the authentication and the api and the storage layers all are integrated together. So that means that if I make an api call and I'm signed in for my client application, then I don't have to worry about packaging up the headers and sending the proper access or ID token, parsing out on the server, checking to make sure that it's actually verified, and then passing that on to the api and then doing all that work. All that's done for you when you're using Amplify. You just make the api call. It automatically sends the access token in the header. AppSync verifies the token, passes it to the resolver in the context, and you automatically have that user's identity if they're signed in. If they're not, it's not there. And it's just super, super simple and integrated. And you don't have to write any of that business logic. The free tier will 100% be enough to cover all of the workshop and then some. Yes. I would just, if you're worried about anything like costing you, it's not even if you left this app running for the next year, it's not going to cost you anything. But at the end of the workshop, if you go down here to removing services, this is going to show you how to remove individual services or if you actually would like to make, might make more sense for this workshop and you're done with it, you can just delete everything by running Amplify delete. This will delete all of the services in your account that you've created for this workshop. Someone said, I had quite a few issues with aws exports. It was quite hard to get it generated when sharing a project with a colleague. Is there some issues with that or is it related to some bad config? The Amplify console should walk you through how to do that. It's going to show you how to do that. It's going to show you how to do that. It's going to show you how to do that. It's going to show you how to do that. The Amplify console should walk you through how to do most of that. Like if you go to, I don't think I have any projects deployed, but we'll actually have this one. Actually, it looks like if you go to edit backend, you should be able to kind of like copy this and share it between different projects. So I'm not sure exactly the issues you ran into, but if you had some issues that look like they might be related to like some bug or something, I would probably open a GitHub issue. Do I recommend using Amplify for commercial projects or some traditional stack, CloudFront ECS, EC2 and so on? I think it just depends on the project. We have a ton of really like at this point, there are hundreds of thousands of production kind of like workloads in the sense that they're 30 day actives and they've been making api calls consistently for 30 days. But we also have like really pretty large names at this point using this stuff like BMW, Ticketmaster, Aldo, and a bunch of other pretty large companies. So I think the answer to like, is this ready for commercial projects? I'm never going to say that one thing should be used for everything. I think like it just depends. If Amplify supports the services that you need to build out something, I think it's the fastest and easiest way to kind of get up and running with aws. But if there's something that Amplify doesn't support, it's harder to extend Amplify than it is to extend something like cdk. So typically the way I look at it coming from someone that doesn't even work at aws anymore, if I was to build something on aws, the order in which I would choose tooling today would be Amplify if I can use it. If Amplify doesn't fit the use case in the sense that the services that I need are not supported, my next choice is going to be cdk for the infrastructure. But I'm still going to be using Amplify client libraries just because they're the easiest ways to kind of interact with the services. So infrastructure, Amplify CLI, and then cdk. I'm not a huge fan of CloudFormation just because it's so complicated and so robust, but cdk generates CloudFormation and I'm loving cdk as my second option. aws error monitoring. We don't have anything that's as good as Sentry or anything like that, unfortunately not. If I wanted to build an SPA dashboard, would you recommend using something other than next.js? Single page dashboard. That seems to be a pretty solid use case just for a typical like Create react app. The one thing that you get out of next.js that I really like that you don't really get out of Create react app is the routing. The file-based routing is just so simple and it's just one less thing to deal with. At the same time, it's probably not going to be as performant for a single page app as something like just a react router or something. Because once the app loads on a single page app, you never have to really fetch that bundle again, it's there. So for stuff like brochure sites and marketing sites and blogs and stuff that needs to be seo-able, next.js seems to be the go-to for that, but for actual apps, single page apps and stuff, I would say I would still probably use something like react Router and just straight-up react for that, unless you need something that next.js offers you at this point. Someone asked, using the differences between graphql api versus Datastore. Datastore is built for two main reasons. One is that it offers a slightly easier api to work with for people that aren't used to working with graphql. So you don't need to know graphql at all, really, to use Datastore. So that's one benefit, I would say, over what we're doing with graphql api. And the other is the real reason that it's created is for people that need offline functionality out of the box and they don't want to build it themselves. So for most web apps, you don't really need that offline functionality. I think it's a lot more often something you see in a mobile app, a native iOS, native Android, Flutter, or react Native. And even then, it's not even always necessary. So for me, and this isn't really the view of the Amplify team, they like to tend to say, use Datastore unless you run into some limitation. I'm kind of the opposite. I'm like, use the Amplify api category unless you run into a limitation that you need offline or something, and then use Datastore. The Amplify api category is used in massive, massive production apps at scale, and it's super solid. There's not a lot of bugs or anything that I've ever seen in it, and it just works really well with AppSync. So I'd probably only use Datastore if you need the offline stuff. And maybe down the road, six months or a year from now, Datastore will get even better, but I would only use it for the offline stuff, honestly. Which one would you suggest for the best next app, S3 and CloudFront, Amplify or ECS with Fargate? I think once Amplify supports ssr, then S3 and CloudFront or Amplify are going to be kind of the exact same thing. And I would probably choose Amplify at that point because you're going to have a much better user experience and developer experience on top of S3 and CloudFront. Today, though, I would probably choose S3 and CloudFront just because Amplify doesn't support ssr on the hosting side, like I mentioned, for a few more weeks. But what we're doing today in the workshop is going to be essentially S3 and CloudFront. Since we're using the next.js serverless component, that actually uses S3, CloudFront, and lambda Edge under the hood. The only reason I would use ECS with Fargate would be if there was some limitation that I had that something like lambda Edge isn't a good fit for. So I think one of those might be if you need a persistent RDS or SQL database connection. lambda Edge is like ephemeral. So it's going to be created and spun up, and it's kind of like a temporary thing. And it's not like a single location where this thing is running, whereas ECS with Fargate is kind of like that single place. So I would kind of like only use ECS with Fargate if I really had a reason to. Someone was asking about Elastic Beanstalk. I don't really have a ton of experience with Elastic Beanstalk, to be quite honest. But I know a lot of people kind of bucket, or they often will bucket Amplify and Elastic Beanstalk in the same maybe category. But I think we've really had a ton more growth than Beanstalk lately. So I don't know if that is because we offer a better service or a different service or what. But I don't know enough about Elastic Beanstalk to answer that. Can this workshop set up work on aws GovCloud? I don't I don't believe so. lambda and lambda Edge. So lambda is going to be basically a function living in a single region and a single like location. So if you just deploy a regular lambda function, it's going to be like sitting in US East 1, and you're only going to have that one way to invoke it. lambda Edge is basically going to be distributed across over 200 different points of presence. And anytime that someone tries to invoke that function, it's going to be given to them at the closest edge location. And that way, it's just a lot faster. So that's kind of the main the main the main difference. lambda Edge is kind of part of like the whole cloud front edge computing type of service and stuff. And it's starting to become extremely, extremely well utilized and popular. I think a lot of people are using it under the hood, like Brazil and stuff like that. And also caching, I believe, as well. So lambda Edge, I believe, is cached. I need to learn more about actually how a lot of stuff works under the hood. I don't know the exact answer to that, though, as far as how the caching works. So someone asked, is there an estimated date for ssr and Amplify? If I go to someone on our team kind of opened up. Like a GitHub issue or something where you can like sign up. So you can basically sign up and try it out today if you just send your your name and your account ID to this email address. And you can go ahead and try it out now. But I think it's going to be released to the public and maybe a couple of weeks. I don't know the exact date. All right, cool. So let's go ahead and continue since it's 17 minutes. After the hour now, and we'll take another break at probably 10 minutes after the hour of next hour. And we'll just take like a 10 minute break. Or we have two breaks. So after Amplify and that has has completed. You're going to see. Oh, yeah, we don't have an SRC folder. Okay, so we're going to see two new files and folders. We're going to see this Amplify folder. And we're going to see this aws exports.js file. Amplify folder is going to hold all of the Amplify related stuff that we're going to need. So we have this back end folder. And this is really I would say the only the only folder we're going to be working in. And the Amplify folder is the back end folder at some point. But there's nothing in there right now for us. It's just kind of there. And then the other file is the aws exports.js file. And this right now only has a property setting the region. But like once we start adding services like Amplify add storage or Amplify add api or off, it's going to start populating this this this object with additional key value pairs. So it might say something like graphql endpoint. And then it'll be like the endpoint and it'll have like maybe the api key and it'll have like the api key. So if we go ahead in our text editor again, we should kind of like to see, you know, same thing. So we have that. So now that we've had our Amplify configuration done, we've created our project can now start adding services. Anytime that we want to see the services that we've enabled, we can run Amplify status. And this will just give us like a list of all the different services that have been created. Right now, we don't have any, of course. And we can also actually open up the Amplify console, which I had done earlier. We can open our project up in the actual user interface by running Amplify console and choosing Amplify console. And we're not really going to be working here right now too much. But you can do stuff like see if you've had authentication added. Let's say you add a function. You'll be able to see the logging for that function and stuff like that. So that's just to kind of like for reference. But what we want to do now is we want to start adding some functionality to our app. So the first thing we're going to do is we're going to add an api. Then we're going to add authentication and then we're going to build out user profile. So to get started, let's go ahead and add the api. So to do that, we can run Amplify add api. I want to choose graphql. And we're going to call this next blog or whatever you'd like to call it. For the default authorization type, we're going to start with api key. Now there's, again, when we talk about these types of applications like Instagram or Twitter or Facebook, when you view Facebook as like a user from like an incognito window or not signed in, you can actually still see certain things like posts and stuff like that. If you go to Twitter, you can read tweets publicly. But if you sign in, you get like a different set of permissions. So most apps have this idea or this concept of multiple authorization types. And that's what we want to build today. We want to be able to show both public access, private access. We want to be able to kind of manage the interface based on that user's identity and stuff like that. But to start off, we're just going to start with a public api. And then later on, we're going to integrate authentication and authorization. So we're going to start with public and then we're going to add multiple. And for public access, you typically either have a completely open api endpoint, like if you go to Imgur or, yeah, you go to Imgur, for example, or dev.to or something, you can pretty much upload an image. They give you an endpoint and anyone can view it. You can basically, you know, view blog posts if you're not signed in, all that stuff. And that's kind of what we're going to start off with. And then later on, we're going to add the security. For the description for the api key, this doesn't really matter. I'm just going to put public. For the expiration, I typically choose 365 because it's the furthest away. If you run an update, you can automatically kind of make this update as well to be another, you know, 365, 365 days later. Do we want to configure advanced settings? We do not. If we had an existing graphql schema that we wanted to kind of use for this app, we could choose that, but we don't. So I'm just going to choose no. And it's going to now give us the option of two different basic like templates to start off with. And these are just going to be kind of like example graphql schemas that we're going to then update. So I'm just going to choose either one. It doesn't really matter because we're going to kind of be overriding this anyway. So I chose the single object with fields. And now I'm going to choose yes to go ahead and edit the schema. So if I go to the workshop, you'll see that the file path is right here. So amplify slash back in slash api and then the name of the api. And then there we have the schema that graphql. So amplify back in right here. So what we want to do is we want to go ahead and update this with the graphql schema that we're going to be working with to start off with, which is pretty basic. I just like copy this paste it here where we have a post type. And for right now, that's pretty basic. We only have a post ID, a title field and the content field. Later, we're going to be adding a cover image and we're going to be adding a author. But theoretically, since we're going to be allowing the user to write markdown, you could think that we could just maybe stringify the markdown and put it into a content field and then serve that. And then you know, parse it and do whatever we need to do with it. So that's kind of what we're going to be doing here. We're going to have a content field that's going to have the actual blog post. But since it's a markdown, we can just stringify it, shove it in the database and we're good to go. So I'm going to go ahead and update the schema to look like this and save it. And we're going to go back to our workshop and we're going to go ahead and deploy this. To deploy, we're going to run amplify push. And amplify push is going to go ahead and kind of walk us through a couple of steps. The first time we deploy our api, because when you're working with something like a rest api, you can just send the request to fetch data from that api using like a library like fetch. And you don't really need to send anything if you're requesting data. You just kind of like send the endpoint and maybe some headers and you get the data back with graphql. On the other hand, you have to send a query that goes with that, that that operation or the request, you could say. And the query could be either a query like where you're fetching data. It can be a mutation where you're updating data or it can be a subscription where you're kind of opening a WebSocket connection to listen for real time data. But anyway, the whole idea is like you have to send that graphql operation along with the request. And that means someone needs to write this code. Or if you use a lot of the modern tooling, it will automatically generate that code for you. It's called kind of like graphql code generation. So we want to go ahead and enable that. And the CLI will do that for us. So we can just run amplify push. And when prompted, we're going to go ahead and choose yes to update or yes to continue. We're going to choose yes to generating code for the schema. We're going to choose javascript as the language target. For the file pattern name, by default, we kind of look at SRC. But in our project, we don't have an SRC directory. So we kind of chose this. It would go ahead and create that SRC folder and it would work fine. We would just need to like import from SRC. But instead, let's kind of go by our file path, which is at the root. So we can just say slash graphql. And then we're going to create it. We can now just choose the defaults for the next two. Do we want to generate everything? And then what is the maximum statement depth, which is two. We'll just check defaults for both of those. All right. So this is going to go ahead and deploy everything. So let's go ahead and go back to our schema for a second while this is deploying and take a look. Now, when you create a graphql api, you typically need to take into consideration your types, but also your queries and mutations. So for most apps, you can think of them as CRUD and list apps. So like if you think again, we keep going back to Twitter and Facebook. But essentially, those are CRUD and list apps. When you view a feed, you're viewing a list. When you view an individual post, you're viewing a post by ID. When you edit a post, you're editing. When you delete a post, you're deleting. So these are kind of like the core fundamental concepts of most software development. Create, read, update, delete and list. Taking that into consideration, most apps need this base functionality. So what if we could just give our schema like a base type and we go ahead and generate all of that base functionality? And then you can kind of update it from there. That's kind of what's going on here. We created the post type and we added this at model directive. The Amplify CLI is going to automatically see that directive and it's going to go ahead and create all of the different additional schema that you need for create, read, update, delete and list. So we're going to get the queries, mutations and even the subscriptions for listening to the updates all generated for us. So it's going to take this base schema and it's going to kind of like, I guess, blow it up into something much larger with all this additional schema that we can use. The other thing that it's going to do, it's going to go ahead and create the database table or the actual database itself. You can think of it in DynamoDB for the post, where when we store a post, it needs to go in a table. So it's going to kind of generate that. So the at model directive does a few different things. It generates the additional schema. It generates the table to save the data. And then the last thing it does, it generates the actual graphql resolvers that map the operations into the database. You don't really have to kind of like think about all this stuff or know about it in practice, getting started. But just so you kind of know what's going on so it doesn't seem like complete magic. All of this code, though, is generated locally so you can update it as well. So if you needed to kind of either update a resolver or create your own resolver, your own custom business logic, you can do that as well. All right. So the next thing we'll do is let's go ahead and continue on to the workshop. So what we want to do is go ahead and test out the api. So once this is done being deployed, we can go into the aws console. We can open AppSync and we can start using it. So what we want to do is we want to send a mutation and also a query. So let's go back to our command line, I guess. And once everything is done being deployed, you should see something like this where you're given a success message as well as a graphql endpoint and a graphql api key. Now, I know everyone's computer isn't the same speed, so I'm going to wait maybe one minute or 30 seconds. I'm going to actually go make a cup of coffee. And hopefully when I come back, everyone's caught up. So I'll be back in one second. Okay. Okay. All right. I updated my picture as well while I was waiting. All right, cool. What we're going to do is go ahead and open up the graphql api in the aws console. So when we ran that, when we ran Amplify push, it created this AppSync api and we can go ahead and play around with it and test it out. So when we run Amplify console api, it will prompt us for graphql. We choose that. And then the CLI should go ahead and open up that that Amplify AppSync api in the aws dashboard. And it should look just like this. Now I'm going to go ahead and close this on the side. And here we are. And we have our own graphical editor interface. If you've ever worked with Postman in the rest world, you've probably been able to kind of like have a test environment for sending updates to an endpoint. That's kind of how graphical is. Graphical editor is kind of like a community project that a lot of companies kind of just use and a lot of projects use. Everyone kind of has kind of built this standardized way of interacting with their graphql APIs and it's done via this graphical editor. Now there's two ways to populate the actual queries and mutations itself. You can actually like go down here and click through and it'll automatically populate the stuff. You can choose mutation, subscription, whatever. Or you could kind of write it out yourself. So you could say query, list, posts, like write all that yourself. If you look at the workshop, though, I have a couple of mutation and a query already defined here. So I'm going to go ahead and copy the query and the mutation and just paste it here and we're going to try it out. Someone asked, are graphql subscriptions fully supported? I thought there were issues with those around serverless. Yeah, that is actually true. That is a good point. If you build subscriptions in a serverless environment, a traditional service environment with api Gateway, then I wouldn't say there's issues. It just takes a lot of work to kind of get them going. But with AppSync, since this is a graphql service that is built using the graphql spec, we actually have full-blown support for subscriptions. And I would say very early on we had Ticketmaster, one of our early customers, that had very, very high scaling up and down because they were putting tickets on sale and they would have tens of thousands or even hundreds of thousands of people that would be in and out of an event immediately. And we've been able to kind of really battle test the subscription implementation for AppSync, where we've scaled a single endpoint to tens of millions of connected devices for a single endpoint. I think it was in the range of like 50 or 60 million is the highest that we've tested it out at. So subscriptions are just hardcore battle tested at this point with AppSync. I would say, though, if you're building your own implementation, it is something that is often like hard to get right. OK, so create post is going to go ahead and create a post. So if we go ahead and if we go ahead and execute that, we should see that the post has been created. And if we now do list posts, we should see that the data comes back. We go ahead and create another one. When you list posts, then we see that we have two posts. So our mutation is working. Our query is working. Our api is just working. So that's like good. So now that we have like played around with it, we know that there's actual data in our database. We can now bring it down to our client app and start rendering some data and kind of making our front end. Another question that someone had is, is there a performance difference between graphql and using REST with Amplify? Yeah, I would say there kind of is actually with REST. The REST implementation is going to be using a combination of api Gateway and lambda. And when you're working with lambda, you have to take into consideration cold starts. You can bump the memory size up to maybe 10x is what most people do from the 128 up to like one gigabyte for lambda, which speeds up your lambda execution a lot. But there's still probably going to be like 50 to 100 millisecond cold start, which is not like a lot. But it's there. With AppSync, the way that we're building, we actually have a direct mapping between the actual graphql operation like query or mutation directly into the database. So you could you can actually do this if you if you bypass lambda and went from api Gateway directly into the database. But you're also missing out in an important part of the api layer around authorization, authentication. So it's kind of hard to get that right without using something like AppSync or lambda. So with AppSync, though, you actually have the resolver has its own execution environment where you can do all the stuff that you need to around authorization. And it's actually, I think, a lot faster. AppSync is then traditional REST api, as long as you're not going. If you're mapping your graphql operation into a lambda function, you are going to be adding a little bit of latency. So you can do that as well, which would then therefore make AppSync and api Gateway exactly the same. So they're both extremely fast. So, I mean, we're talking about we're talking about tens of seconds of latency differences. So it's like for most use cases, it's not a big deal either way. All right. So anyway, we went to AppSync by running this command. We ran this mutation. We ran this query. We wanted to make sure everything's working so it is. The next thing we want to do is go ahead and configure our client project and test it out. So to do that, the client project needs to know about the resources that the Amplify CLI has created. So going back to our project, I kind of went over how we have this aws exports file that was created by the CLI. All we all we really need to do to kind of kick things off is we want to import this somewhere in our react or our next.js or our vue project. And in our case, of course, our next.js project so we can kind of let the client know about these resources. So the way that we're going to do that is we're going to create a file called Configure Amplify. And any time we need to configure Amplify, we can just import this and have those resources available. So I'm going to go to my project and I'm going to create a project file called Configure Amplify.js. And we're just going to go ahead and paste that there. I see a few questions like racking up. I'm going to come back and get to those in a couple of minutes. So we add Configure Amplify.js here and we can now just use this anywhere we want. So we're good to go. So we can go ahead and just save that and close it up. And what we're going to do now is we're going to open pages slash underscore app.js. We're just going to import this. And you typically only need to do this once, right, like at the root of the project. And you don't need to do this again for the most part. So in a react app, you do this once. And even in our next app, we're only going to kind of do it once. But if you're building out api routes, you're going to need to actually import these into those api routes. We're not doing that. But let's say you did. To get the actual resource location information, you need to do this. And the reason is we talked about lambda at Edge. These api endpoints or these api routes are actually deployed as individual functions at lambda at Edge. So if you're building that Edge and if they don't have all the necessary information, then they're going to be missing that. So that's just something to keep in mind if you're continuing to build. So we're going to go to pages slash underscore app.js. We're just going to go ahead and import that file. So we created Configure Amplify and then we imported it. And now we're good to go. The only thing we need to do now is go ahead and create some functionality that queries our graphql api, renders that data to the screen. So that's what we're going to do next. Now, when I kind of gave the intro to this workshop, I talked about we're going to be mixing dynamic data fetching along with static site generation and server side rendering. So we're going to be kind of implementing all that stuff. Now, when you think about like a blog or any type of dynamic list of like individual items, you have to kind of think about how you might want to render those. Do you want to kind of rebuild the entire app every time someone creates a blog post or a tweet? Probably not, right? Like for Twitter, for example, that would not make any sense. It's extremely dynamic. And for a blog where a lot of people are going to be writing, you might say that doesn't make any sense either. If you go to Dev.2 or Medium, they're not rebuilding their entire site every time someone creates a new post. What they are doing is they're doing a combination of dynamic data fetching and then they're also doing server side rendering to get that seo stuff. So we're kind of going to be taking a similar approach. You might be wondering like, why are we just fetching data on the client? That's because we're going to have this one list of posts. And then when someone clicks on a post and views that individual post, that's where we're going to be doing the static site generation and server side rendering. It just kind of makes sense, I think, for this type of app. So what we're going to do now is just go ahead and update our main index.js to go ahead and fetch the posts. And we're going to do that by just copying this code and going to pages.index.js and replacing everything. And I'm going to walk through what's going on in this code there. So I'm going to go to pages.index.js and delete everything. I'm going to paste this new code here. We're going to save that. Now let's go ahead and walk through what's going on here. This is a fairly basic react component when we kind of really look at it. If you take out the state and the hook and the function, when we take out this mapping of posts to kind of map over an array, all we're really rendering is this H1 of posts. So we kind of can fundamentally think about it. Let's say we just started with this H1. We just have this header. This is going to be our list of posts. How are we going to kind of make that happen? We're going to be doing a couple of things. When the component loads, we want to go ahead and fetch the posts from our graphql api. We want to go ahead and save that in the local state. And then once that state has been updated, we want to re-render and kind of render those posts into our screen. So the way that we do that is we import, first of all, a couple of hooks from react. We import useState and useEffect from react. Is this size okay with everyone, by the way, or do I need to zoom in? Because this is really, I think, some of the more intense code. Okay, cool. So we're importing useState and useEffect. We're also importing the link component from NextLink. The cool thing about Next is that you don't need a router. You just create a page and then you can navigate to that page without having to create any routing logic by just using the link from their library. We import next the api class from aws Amplify. The api class could be thought of as like the graphql client of Amplify. If you've ever used apollo or Oracle or any of those, it's kind of like our version of that. And it specifically works especially well with Amplify. We also import the list post query from our graphql queries. When we ran Amplify push and we did that graphql code gen, our CLI created a folder called graphql. And here we have our mutations, our queries, and our subscriptions. So now we can just import those whenever we need them. So that's kind of what we're doing here. We're just importing from the queries, graphql folder, the queries that was created for us by the CLI. When the component loads, we call this useEffect hook that calls fetchPost. fetchPost calls setPost and updates the empty post array with data that comes back from our graphql api. So the way that we're calling the api is right here. So these three lines of code, we call it api.graphql. Fairly simple api. All we need to do is pass in the query. This is an async call, so we just kind of say await. And then after the data comes back, we call setPost. Now, what is the array that we're looking for? Well, if we go back to the AppSync console, you'll see that we have the data that comes back, data.listPosts.items. So items is kind of like nested. That's kind of what we're doing here where we're saying we have the data.listPosts.items. And this is the array that we're kind of setting. And then once we have that array, then we just like map over the array. And for every item, we're going to be kind of returning a link. And then when the person clicks on that link later on, we're going to navigate the user to view that individual post. That's fairly straightforward. This is kind of more react stuff. If you don't know how this works, then just copy and paste it and dive into some react stuff another time. We're not going to go too deep into the react stuff. One thing that's interesting to keep in mind is how are we going to be linking to the page? So if we run this and try to click on this, it's not going to work now, but later on it will. We at some point need to have a folder called posts where we generate the posts by ID in this post folder. And then when someone clicks on a link, we're going to say like our app, post, post ID, and this just needs to work. And that's going to be something we do later. But for now, we're going to go ahead and set that up, set us up for future success by going ahead and setting that. One thing I haven't gone over a whole lot is the tailwind stuff. Tailwind is its own completely separate thing that we could spend a lot of time going over. But so let's just only talk about it in this component and then kind of like not talk about it again because there's a lot to talk about. But in general, you have these classes that you can use and they all do like the same thing wherever you use them. So instead of you having to create like a class name is equal to text header large or something like that. And then like, you know, using that again somewhere, we have something called text 3XL and this we can use anywhere in our app. So we can kind of like not have to ever create our own class again. We can just use this. And I think the beautiful part is not only that we can use it in our app, but we can actually build like 100 apps and we can always understand these classes that we're kind of working with. So you could kind of just think of it as like, you know, this set of classes that we can use and we understand what they do. And there's a pretty good documentation around them. All right, cool. So that's pretty much it. Let's go ahead and test this out by running npm run dev and see what this looks like. And then what we're going to do next is we're going to add our user profile with authentication. So we should be able to go ahead and open our app on localhost 3000. All right, so when the app loads, we see some really ugly stuff going on, but at least we see something. We have our two posts. And if I click on a post, we see that we have an error or 404 or something, which is kind of exactly what we're looking for. But at least we see that the URL says slash post slash post ID. So we're getting somewhere. And you'll notice that it's really slow and all that. If you ever want to kind of run a build and see how fast next.js is, you can run npm run build and npm start and it'll be like lightning fast. But for now, we're kind of in dev mode. npm run dev, you know, we're running in dev mode. So it's going to be kind of slow. All right, so we're fetching data. The next thing we want to do is we want to allow authentication so we can start creating and update our own data. Because when we create something, I think the general idea is we want to be able to associate a user with that and be able to kind of, you know, give administer, I'm sorry, give authorization privileges and stuff for the people that created that. But for that to happen, we need to have the idea of like a user and things like that anyway. So to get that going, we want to add authentication and we can do that by running amplify add off. So let's go ahead and do that. So we're going to go back to our CLI, we're going to run amplify add off. And we're going to be given just a few prompts. We're just going to take all the defaults. So amplify add all default configuration username to sign in, and then we're done. And then we're going to again run amplify push. So let's go ahead and try this out. Default username to sign in. No advanced settings. Deploy run amplify push. And we choose yes. All right, so our authentication service is being deployed. Let's now build out the client, a little bit, a little bit more make it look a little better at navigation and also add a user profile. So to add the user profile, we're going to create a new file, and our entire user profile is going to look pretty nice and we're going to do with like around 20 lines of code. So, in your main directory create a new file called profile.js in the pages directory. So pages slash profile.js. And then we're going to go ahead and just paste in that code. All right, so if we want to kind of break this component apart a little bit, let's look at the UI that's returned first. We're returning an h1 that has a profile is like the header. Then we have an h3 with the users username and a paragraph with the users email address. Now how do we actually get that user data, that's kind of where the UI component that we're going to be using comes into play. So, if we just wanted to like export this, you know component like we normally would we would just say export default with the name of the component. But here we've actually wrapped it with this with authenticator helper, or you could call it an HFC higher order component. What this basically does is anytime that you want to put an authentication flow in front of any component in a react app with amplify you can use this with authenticator component. And we get that in into our app by just importing it from the UI react library. When we created our project we installed amplify UI react. And we also installed aws amplify. And this is our first time using UI react. So we're getting like these UI components so the two that we're getting is a sign out button called amplify sign out which we just drop in, just like that pretty pretty simple. And then the other is the with authenticator. Now if the user is signed in, then it will render this this component. Okay, if the user is not signed in, it will not render this component and instead it will kind of show a full authentication flow sign up, confirm sign up with MFA sign in forgot password all that stuff. So that means that we don't really have to write any of that code all we need to do is worry about okay let's say let's just assume that they're signed in because if they're not that other part is already taken care of for us. If they are signed in, let's go ahead and find a way to find out who that user is by reading the session from the local storage or from from the cookie storage. And in our case it's going to be local storage. And we want to go ahead and get that user metadata and kind of render that to the screen. So the way that we do that is we have this use effect hook that gets invoked when the component loads. We have a function called check user. Check user is pretty simple. It calls off dot current authenticated user, which reads the currently signed in user off of the local storage. And then this gives us a user object that we can then call and save it to the local state by calling set user. Of course user and set user just created using the use state hook. And we by default set the user to be null. So when the component loads at first there is no user. And then once this is completed, then we update the user and we are able to return the UI. If there is no user we just return null. So very compact component, a fair amount going on, but very powerful as far as like what we're trying to get done. So this is going to be our user profile. This is all we need. So when the user is set here that we now have the user's username and we have an attributes object on the user that has their email address or phone number, all that other stuff. So you can imagine like how easy it might be to create a user profile with all of the other metadata you might ask for that user. So that's it. We can go ahead and save the profile. We're done. Now, by default, the with authenticator component that we just used has a yellow color. But for for this app we're kind of styling everything to be this like blue color. So this is kind of optional if you want to go around if you want to go along with the styling, then I would I would follow along if you don't care then you can skip this part. But the current implementation of the amplify UI component library is that they're both using web components and therefore we can just set some like basic css styling and it'll it'll apply to those elements whenever we want we would like to kind of set that styling. So the way that we're going to do that is we're just going to open style slash global css, and we're going to set a couple of properties, the amplify primary color, the amplify primary tent, the amplify primary shade and this is kind of just a blue color. So I'm going to go ahead and copy that and open style slash global, we're just going to add this right below the tailwind. I'm going to do this last section here and then we're going to go ahead and I'll answer a couple of questions. So we've added the profile, but if we look at our app, there's really no way to actually get to that profile so like let's say if the profile did exist, how are we going to get there. We need to add some navigation and also maybe add some styling to our main app to make it look a little better. So the way that we do that is in next.js, the app is essentially kind of the entry point and we're kind of returning the app here. That is the component that kind of comes in as an argument. So if we wanted to do any styling or something that was global around our entire app, we would do it here. And this is typically where a lot of people like to navigation and stuff. And that's kind of where we're doing our navigation. So we can go ahead and just copy this and pages slash underscore app.js. And or if you wanted to kind of type this out, this is kind of what we're going to be working with. So we still want to import our styles. We still want to import our configure amplify, but we now want to go ahead and import the link component because we're now going to be adding some navigation. So we import link. And now instead of just returning like the component before, we were just kind of returning, you know, the component would look something like that. I remember now we're actually bringing that component and we're returning it within the div. And we also added this new nap. So we have the nav at the top. And the rest is kind of like kind of how it was before. One of the main differences that if you remember earlier that everything extended all the way out to the screen, there was no padding. It looked kind of ugly. So we're adding just a little bit of padding to make that look a little nicer. So we're adding a padding y of eight and a padding x of 16. So padding on the top, bottom left and right. And then for the navigation, we're going to now have three main links. One is the route, kind of like where we have been operating already. We're creating a new route that we've yet to use called slash create posts. This is going to be where we have the UI for the form that allows users to create posts in just a moment. And then the other is the UI, or the link for the profile that we just created. So when we run this now, the user should be able to click on the profile and see this whole authentication for. Alright, so with that being said, we've kind of written a decent amount of code without testing it out. So let's go ahead and test this out. So to test that out, we can run npm run dev. We'll go back to localhost 3000. And we should see a significant improvement over our last time we checked this out in general. Alright, so this is what our app looks like now. We have our two posts still but we have a little bit of padding around it looks a little better. Most importantly, we have our profile. And if I click on profile, we should see that we have a way to sign in and sign up as well. I'm kind of zoomed in so it should look, you know, something closer to like that, something but I'm going to go ahead and sign it I mean zoom in so everyone can see pretty good. So now on the profile, since we're not signed in, we're seeing this this component and if we are signed in, we'll see our profile. In order to sign in, we first need to create an account. So let's go ahead and click Create an account. I'm just going to put in whatever for the phone number because it doesn't matter for me. And I should receive an email verification code. Alright, so if we're signed in, we should now see our profile. So we have the profile, the username of David three email. We're kind of getting somewhere right. We refresh we stay signed in. Again, it's kind of slow because we're in dev mode but if you run npm build npm start it should be a lot faster. And then if we sign out, you can now sign back in with those new credentials. So I'm going to answer a couple questions that we're going to take a quick break. One person asked like where's all this data, like being stored, because we haven't really looked at that. That's a good question. So app sync is using DynamoDB under the hood. So if we go back to app sync and we click on data sources, we can see that our database is right here. DynamoDB been getting a lot of attention I think in the last year. It's known as like the infinitely scalable database, meaning that the more data that you put in it, the better that it performs. And it's extremely, extremely powerful and used in a lot of big companies. That being said, it is sometimes a little bit more complex to kind of work with than some other databases out there. There's a whole lot of stuff around working with DynamoDB that you kind of have to understand when you start diving into the more complex stuff. But I think Amplify does its best to abstract most of that away. If you notice, we haven't even mentioned really anything having to do with databases or DynamoDB or any of that stuff. The resolvers that the CLI creates are automatically built for DynamoDB. And you don't have to kind of write any of that to get started. The other thing that you might wonder is like, what about the authentication? Where are those users stored? If we go ahead and we go to Amplify Console. If we go to authentication, we can see that we have our users right here. And this is kind of where you can view the users. So if I click View in Cognito. For some reason, it didn't open up in the right region. So it should automatically open up in the right region. And I should be able to do something like it should open this up right here. So I don't know what's going on with the CLI or maybe it's my environment. But anyway, like it should open up here and you should be able to click on users and groups and see that you have this user, which in my case is just DAB3. You can disable or delete a user. See all of their metadata, email address, phone number, stuff like that. I'm going to kind of try to run through a few of these questions. Does Amplify support types for graphql? Yeah, when you run Amplify, you can actually, so when you run Amplify push, it asks us, do you want javascript, typescript or Flow? You know, of course, no one's really use a Flow these days. So you can choose typescript and automatically will generate the typescript for you. How might we create our own queries and mutations alongside of what AppScene gives you? That's a great question. I mean, most of the time, like what I will end up doing is like, you know, we have this graphql folder that's automatically generated for you. Like I might just create my own file called like my queries or something. And then you could just like, let's say we wanted to kind of create a compound query or something. You could just add a couple of queries into a single one and then. So you could just create your own, you know, and then just import those. Can typescript types be generated? Yes, just choose typescript. And you can also regenerate anytime by running Amplify code gen. And I believe if you kind of like, let's see here. OK, so this .graphqlconfig.yaml I think is what we're going to take a look at. I think here you can actually you can configure what you want. So like by default, we create this .graphqlconfig.yaml. And when I first set this up, I kind of set the path that I wanted. And I also set the code gen.target as javascript. If I change this to typescript or whatever you wanted to. If you mess up something when adding a service, is it easy to revert using Amplify CLI? I mean, you can make updates using Amplify CLI, but I don't know how easy it would be to revert if you made a big mistake or something. The typical workflow is like you have three environments or something, at least, let's say three. You have your production, your staging, and then like your dev. So you could say Amplify ENV add like my ENV. And then that would create a new environment, which basically takes all of that infrastructure code and copies it into a brand new project. And you could deploy that, test it out, add stuff. And when you've added the things that are like different than your main environment, you can actually merge those into your other environment after you've tested them out. And then maybe merge those into your production environment after you've tested those out. So we're not going to be looking at Amplify ENV. But if you want to kind of work on that type of workflow, check it out. Does Amplify have hooks? We don't really have any hooks that are built and maintained by us, but a few people in the community have done that. Using local storage has security issues, isn't it? That's a good question that a lot of people always have. It doesn't have any more issues than using cookie storage or any other mechanism. I think you're kind of trading, I guess, one perceived issue for other issues. And in reality, there's no, I would say, perfect way of going about dealing with any type of security mechanism on the client. They all are having their own, I would say, trade-offs. But if you look at the implementation that we have, someone did a decent kind of overview of it on Twitter, where they're an information security person, and they went into all the different mechanisms that go back and forth when you just make a simple authentication request with Cognito. I think there was over a dozen different things that go back and forth. But I would say whenever we deploy something in aws, security is always the number one concern. And for Amplify, whenever we make any update or anything at all, for any of the stuff that we do, it goes through just probably the most robust security scrutiny that you could possibly think of. We've never had, with Amplify, any customers that have ever had any security concerns or anything like that or problems that we're aware of. So does local storage have security issues? I think everything can be exploited if the right circumstances are in place. I would say that, but we've never seen it happen. Custom resolvers? Yeah, that's a great question. That's kind of one of my favorite things. There's a couple of ways to write custom resolvers. So if you go into the backend folder of Amplify for the api, you'll see that you have a build and you have your resolvers. So all these resolvers are created for you. There is one problem in mapping it about the current implementation or one, I would say, challenge. If you want to write your own resolvers, you have to write them in a language that we have created called BTL or it's kind of that we've used called BTL. Instead, I like to write javascript. So there's a couple of ways to get around this. First is the main one that I use. Well, there's two ways to do this. You can either write your own resolver using BTL, which for me took a few hours to kind of understand how to do, and I don't enjoy doing it, but you can do that. Or you can write javascript and create a lambda resolver, which is basically going to be a mapping of a graphql operation into lambda. And from there, you can kind of have the whole execution environment of lambda. And what I typically do is I create a function. I bump the memory up to like 1.5 megabytes. And you have a very, very fast execution time, even at a cold start, kind of like the tens of milliseconds latency. But you have the full execution environment of lambda. So I'll use the automatically generated resolvers for all of my base functionality. And I might even write my own custom resolver and BTL for some fairly basic to intermediate stuff. For anything advanced, I write a javascript resolver. And then I have like that whole execution environment. I have node modules. I can do all kinds of stuff. I can even call multiple microservices within that. So you can create some custom resolvers a few different ways. One interesting thing to keep in mind, though, is that we're actually building out and we're already testing a replacement for BTL that is going to be native javascript resolvers. So instead of BTL, in about three to six months, whenever it rolls into production, you're going to be able to write javascript resolvers. And that way you don't have to write BTL. And that's going to be something I'm really looking forward to, because if you can map a graphql operation directly into a database and write the business logic in javascript, to me, that's like the perfect scenario. I'm looking forward to that. Can we customize the automated email template? Yes, you can. And the way that you can do that is either by running Amplify update off. Of course, spelled like this. But yeah, you can do it that way. Or when you're running Amplify add off, instead of setting the default, you can actually go ahead and walk through that process on the initial setup. If you want to, you can go into your user pool and update it here. I forgot exactly where it is, but I think it's under message customizations. You can say hello from matter. And then, of course, you can do html and other stuff and dynamic stuff. So you can do that all right here. Is there a reference implementation for the javascript resolvers? Yeah, I think there is. There's like a GitHub where you can kind of see the RFC. I'll paste that link here into the Discord. So javascript resolvers, you can see the RFC here and you can see the discussion. Does REST api work the same with api keys? So it doesn't because api Gateway doesn't require an api key at all. It's kind of the same thing, though, when you think about it. You can't really even consider an api key a secure way because if you've deployed your app, anyone can inspect your requests to kind of see that the api key is there and copy it and use it. So it's essentially a public api. But a lot of times people deploy REST APIs that don't require anything. So yeah, they're both public. It works the same way, but with REST APIs, you don't need an api key at all. It's just a completely public endpoint. We're back and we will go ahead and wrap this up. And we have 35 minutes, so we're going to kind of start going a little bit faster because we still have a lot to cover and want to make sure we cover as much as possible. So what I would like to accomplish next would be the ability to create posts, update, delete posts, and add images to the posts. So let's see how far we can go. So the next thing I want to do is in order to associate a user with the posts, we need to update the authorization. We need to be able to kind of associate a user with the posts. And typically that's done by adding some type of field on a top-level item to kind of identify the owner. A lot of times this is done using something like a UUID or some type of unique identifier associating the user to a piece of content. And in our case, we're going to be using something that's built in to amplify. That's going to be able to allow us to take the user name and associate that with a post in our case. To kind of get started doing this, and we'll explain more, let's go ahead and run Amplify Update api. Keeping my server running. I'm going to go ahead and choose graphql. And what we want to do is we want to update the auth settings. Right now we only have api key, but we now want to add api key as well as Cognito. This is going to allow us to have both public and private access. So to do that, we're going to choose api key for the default authorization. And then we're going to choose Amazon Cognito user pool for the additional type. So we're going to kind of walk through these similar steps. Update auth settings, api key for the base type. We'll keep the name of public. We're going to set the expiration for 365 days. We do want to configure additional auth types. And we're just going to highlight Amazon Cognito user pools by hitting the space bar in my case. All right, so we've updated our authorization for our api, meaning that we can now send both public and authenticated requests to AppSync using the endpoint that was given to us after we deploy this. But that's not really enough. We need to actually update our graphql schema. So I'm going to go ahead and go to back in slash our name of our api. And we're going to open schema.graphql. We're going to do a little bit more work here. So if I go to the workshop, I can now see that I have an updated schema. So I'm going to go ahead and copy the schema. And I'm going to go ahead and update this here. So if we remember our old schema, we had an ID, a title, and a content field. We're adding one additional field here. This is going to be the username, meaning that this is the username of the user that created this post. That's kind of like the owner. And this is the way that we're going to add one piece of authorization around this item. A couple of other things that we're adding. And I'll kind of break the schema apart a little more so you can kind of see the different pieces. So here we have our fields. We've gone over that. We now have two additional pieces as well using these directives. So we have the at model. At model gives us the database and all the resolvers. You know, we used that earlier. We're adding now, let's first look at at auth. At auth allows you to add authorization rules to a top level type or a field. So I might want to say I want to have some type of authorization for this field only. I could use it here. Or if you use it at the top level, you're kind of saying, I want these rules to be applied to this entire type of post. This takes an array of rules. And each array of rules has a few different properties. And what we're doing here is we're going to say we want to allow owner access. And owner access means the person that created this or that owns this item that's created. In our case, whenever someone creates a new post, that means they have full access over the post. That means they can create, read, update, delete. They can do everything. And then we also want to say, let's set the owner field to a specific property. And in our case, we're going to be setting it as a username. OK, so that means like if I go into my database, I should actually see Davit3 as a username for the post that I create. The next thing we want to do is we want to add public access, meaning that anyone that wants to access this can do so. But we're going to specify which operations that they can do. And what makes a lot of sense is for something like a blog or something like that, we just want to let those people read it. We don't want to let them make updates or deletes or anything like that. So we can just pass in this array of operations. And this is only going to give them read access. So we have private access for the owner, public access for everyone else, just for reading. Another popular form of access is this isn't something I would I would add here. I'm just kind of going over it is something like group access. So here you can, you know, I think it's like group and you could say groups. And you could pass in an array of groups, something like admin. And this would this would allow you to kind of give administrative privileges as well or something like that. OK, the other thing that we want to do is we want to add an additional data access pattern, meaning that like when I told you about like the api that's being created, we have a way to create, read, update, delete and list posts. But what we need is an additional way to query for posts, because by default, the list post query is just going to return all the posts. It doesn't matter like, you know, how many are there. It's just going to return all of them. We want to now have one additional graphql query where we can say we want to query posts by username. Meaning I want to query for like posts that I created or that someone else created only. And we want to have a very efficient way to query our database based on this query. So to do that, we can use the add key directive. And here we can set a few properties. The add key is going to create a new index on our database, meaning it's going to kind of give us a new way to query our data using one of the different fields that we have here. So let's say I wanted to query by title or content or username. You could do that using this add key directive. Now, in our case, we're going to be querying by username. So for the fields we're passing in, the only field that we're passing is username. And then now we can say we want to hit this username index with a query that we're going to be calling posts by username. And now I can say I want to get all posts where username is equal to three. And now I have like a selection set of like, you know, my posts. So this is just going to give us a new query called post by username. We're going to be able to hit and query just this this field here, and it's going to return a selection set for that. So now we have two like main queries for an array of posts. We get all the posts, or we can query for posts just by the username. And this is important for our app because we want to have like a profile view where we can only view our own posts. And this can be done in a couple of different ways. Of course, you could hit the database, bring back everything and filter on the client. That's not very a good a good approach, though, and not very performant. Doesn't make a lot of sense. So this is kind of the most performant way to do that. So let's go ahead and save that. So, you know, essentially, I just kind of walk through this. You could you could just copy and paste this, you know, and hit save and you're good to go. What we're going to now do is go ahead and deploy the updates. So to do that, I'm going to run amplify push dash dash Y, and we're going to be good. Dash dash Y just kind of automatically will say yes to whatever questions that come after. You could do that anytime, you know, in your development of amplify. All right. So while that's deploying, let's go ahead and start creating the user interface for creating posts. I'm not going to walk through this right now. We're going to look at that later. But the next page that we're going to create is a create post page. This is going to be like a big form that has the input that is going to allow the user to create a post. And it's going to also have a button for sending the post to the back end and all that stuff. So this is a lot of code. So I'm just going to go ahead and copy and paste it. Into a new page. I'm going to call. All right. All right. So a couple of things that we've already done before, you know, we're using the with authenticator again, because if someone is creating a post, they have to be signed in. So we're just going to wrap this page in that just to kind of put authentication flow in front of it, just in case they somehow got there without it. We're going to be using the use state hook as usual. We're using the api class as we've been doing. We're going to be importing the UUID library to generate a unique identifier on the on the client. And then that way, we're going to be kind of setting an ID for the post when we create one. We're going to be using the use router hook to programmatically route the user. So when the user creates a new post after the post has been created in the database, we want to then route them to view that post. That's kind of a general idea there. We're using the simple markdown editor, which renders a markdown editor with just really a single line of code. So right here, we have that simple markdown editor. It's super, super, super easy to use this simple markdown editor. So let me actually break this maybe into a couple lines. Kind of go over the different properties. So this will render a markdown editor. The only two props that we have to pass to it are the values. This is going to be just a stringified value that is going to be the markdown that we're writing. And then we have an on change handler. So like whenever we type into this form field, which is essentially all it is, we're going to be updating the local state to make that update. So that's about it. Like this is kind of self-explanatory. We're importing the css for the markdown editor. We're importing our graphql operation. In this case, it's a mutation. We set some initial state. The only state that we really need to keep up with for someone creating a new post is the post title and the post content. The ID is going to be generated using the UUID library, and the actual username is going to be automatically read by the AppSync service off of the access token. So we don't even need to kind of pass that in. It's automatically going to be read on the server securely. When you're creating a form in react, you typically are going to be doing two main things when you're creating a form in react. First of all, you need to have a place to store the form state as the user is typing. So a lot of times you'll have an object that has all the different fields. If you think of an authentication form, you might have something like the username, password, email address. You're storing all that stuff. So you're creating a form. You just store the user's input. The other thing that you need to have is some type of on-change handler that is attached to the input that is going to be updating that state. So that's kind of what we have here. We have an on-change handler that's going to be updating the local state. And we also have the state itself. So pretty basic stuff there. Then the only other thing that we're going to be working with that's a little different than before is when we queried for posts, the only thing that we did was we called api.graphql. We pass in a query of list posts. This is the only thing we needed to do to fetch the posts. And this brought us back an array. The main difference here is that instead of just querying, we're actually sending a mutation and we have to pass along some data along with that mutation. And the data in our case is going to be the post. So we're kind of constructing a post object where we have the post that's coming off of the state here. And then we now are appending an ID to that post. So we have a post title, content, and ID. And now we're ready to kind of send that to our back end. And then since we're using multiple authorization modes, we also need to define an auth mode if it's not the default. The default in our case is api key. So if we were querying, we wouldn't need to pass this. But since we're using the other authorization mode, we need to specify this. So in our case, we're just specifying that we want to use cognitive. So we basically are going to make this api call, wait for that to happen, and then we're going to say router dot push, and we're going to go to slash post slash post ID. And then the rest of this is fairly simple. We just have like an input for the post title, the market editor for the post content, and then a button that's going to be invoking the create post function. All right. The next thing that we're going to work with is, we're going to be working with the next JS, a couple of next JS APIs that we haven't worked with. So, the idea here is that we want to be able to create a number of posts, regardless of how many are like in our back end, we want to be able to generate those pages. So, this is kind of like in the realm of static site generation. So if you ever work with gatsby or something, you have this build process that goes and fetches like 20 posts, maybe from your api, maybe that's like some type of CMS or something. And then you have this array, and then you have this function that that maps over those posts and creates a new page for every post in that array. And then when your build is done, you have your gatsby site with your 20 pages built out into html. Very similar thing is happening, but the but the api is a lot different I think in next JS. The page generation that gatsby does in that build is actually done within the component itself, and it's using a combination of get static paths and get static props. Get static paths is going to get that array of IDs that we want to generate. And it's going to basically construct this paths array. And then we're going to return the paths array from get static paths. And let's say there's 20 items in this array with 20 IDs. We're basically going to invoke this get static props function 20 times, and it's going to generate 20 pages based on that ID. So let's say like you've created. Hello world this is my first blog post, and then hello world is my second blog post. You have that data stored in AppSync. We have, you know, the title of the content, and you know the ID. What we basically want to do is we want to generate those two blog posts at build time, or, and what we're going to talk about how we might do that actually a runtime later but let's say we want to build those at build time. It's going to go ahead and fetch those two posts, we're going to construct this paths array, that's going to have an object that has the post ID in it. So we're going to have, let's say two posts. And this array of two posts is going to be then going to be calling get static props, get static props twice. Inside the params we're going to have the ID for that post. We then call the graphql api again, passing in that ID. And now we're getting the entire post metadata like the post title post content, all the other metadata, and then we're able to pass that data down into the actual page itself as props. And in the page we're getting that that that post coming in as a prop. And what we can basically do is now render the post title, the post content and markdown form, and then the username of the person that created it. So like a ton of stuff happening in this component, but it's also very concise like not a lot of code. I think that speaks to how powerful gatsby is. I'm sorry, next.js is. So what I want to do is I want to create, what we're going to do to make this happen is we need to create a folder called posts. So I'm going to create a folder called posts. And then in the folder here I'm going to create a file called ID.js So pages slash posts slash ID.js And what I'm going to do is save that. And I'm not ready to really try this out yet but if you did click on create post in your app was still running. I believe you should see the form but we're not quite done yet, but it is there. So you should see something like this. So you should be able to kind of like start doing some stuff like that and then you might be able to even preview it. So we're still working on it. So let's go back to our workshop. So what we want to do is we want to update our main list here to show the owner or the person that actually wrote the post, because right now the only thing we're rendering is like the title. So instead we want to render the title as well as like David three, the username of the person that created it. So the main thing we're really doing is kind of adding this this line of code here post that username. So really you could probably just add that. Let's try that. Unless there's something else I'm missing here which I'm pretty sure I'm not. You can either copy and paste this whole component back into pages slash index digest or you can just add I think this line here. All right, so we have that showing up. So we're good, even though there's no author showing up and that makes sense. Because when we created a post earlier, we did not have authorization enabled. So, with that being said, what we want to do now is we have that old it's kind of like stale. You can think of it like stale data at this point, because the data is no longer consistent with our schema that has the owner field so we need to delete that So to do that, you can run amplify console api. Choose graph QL, you know, essentially we're going to try to get to this back to this DynamoDB console view. But let's say that you're not here already let's let's let's go ahead and get there again. You're going to run amplify console api, choose graph QL, click on data sources, click on the link to the database, and then click on items and delete those. So it looks like this. data sources, database. Someone asked about generating the ID on the server. Yeah, you can definitely do that. In fact, if you don't pass an ID in, it'll automatically generate on the server. The reason I generate on the client was that I wanted to, and I did this for not really any apparent After you create a post, we go ahead and navigate to like view that post. And to do that we needed to like, I guess we didn't really have to we could have waited for that post to create gotten the return value since we're using graph QL. Yeah, so you don't have to do that you can generate the ID on the server, for sure. And AppSync already automatically will do that for you. Yeah, exactly. Yeah, that's a good point. We could have done that. So, I'll go ahead and delete these two items for database. In fact, I might update the workshop to do that next time. So if I refresh, then you'll probably see that we have no posts, which is good. But, so we're ready to kind of go ahead and test this out. So I'm going to go ahead and go to create posts. We'll paste the code. And Yeah, I'll get a picture. All right, so we go ahead and create a basic post, we should be able to go ahead and click Create Posts. After the post is created, it should go ahead and navigate to the actual post itself. And we can now see that we have a pretty basic post going on. We have the title, we have the author, we have the content and it's formatted in a fairly decent way. We even have some code formatting and stuff and we're able to render images. The one thing we're not quite doing yet is that we will do later and I don't think we're going to get to it of course like with the time that we have left is that we're going to be able to add a way to upload images to S3 and render those as like a header image. And also we want to be able to give users the ability to edit and delete their posts. So that's kind of like what we have to look forward to next. If we want to make this run faster, like to kind of see how this actually runs in production, instead of running npm run dev, we might say npm run build. Build. It's taking a while. It seems to be taking an extremely long time. I'm going to try running npm run build one more time. Looks like the build happened but This is actually like a better computer than I used to have at Amazon, believe it or not. I mean it's not like an M1 or nothing but let's see here, 16 gig memory, i7 processor, like a ton of storage, one terabyte, jeez. Victor does not code yet. See, I don't know what's going on with this build anyway. It does seem to be a problem with my machine. There we go. I think unless I just cancel it. Nah, the build didn't finish. Anyway, npm run build should work. I'm wondering if this is just because I just set this computer up like today or yesterday. Yeah, anyway, so we're kind of like there on time. Honestly, like we only have five minutes left and I want to specify or I want to get to like these questions and stuff that I can get to for the next five minutes. But I think we've covered like the core functionality of like what we're building. We've done the authentication, we've done the api, we've added authorization. If we go to DynamoDB and we refresh, we should see that like the posts now also have a username associated with them. So like we're getting there on the authentication authorization part. So we're kind of like covered the most important stuff. What you're going to be covering next is going to be adding a new view. That's going to be like a new link that's going to show only our own posts. And we also want to be able to kind of like dynamically hide and show navigation based on whether the user is signed in. Again, a core piece of almost any application. We want to be able to update our UI based on the user's authentication state. So we're doing that. And then the last thing we're doing is we're allowing users to update and upload cover images to S3. So if you continue with the workshop, you'll get to that. I see there's a lot of questions and stuff, so I'm hoping that I can answer some of these. I see Ali's in here. Hey, Ali. I miss y'all already. Hope y'all are doing good. Are there any plans to improve CloudWatch and overall insight into running services? It can be very hard to trace what's going on in the logs. Are there any teams working on something like Century or Rollbar? There are some additional, there is actually some work being done as far as logging and metrics are concerned for Amplify. As far as like something like Century or Rollbar, I can't like speak exactly to like what it's going to look like, but it's going to be an improvement around what we have. It might not be as like solid as far as like error reporting or crash reporting is something like Century or anything like that. Can AppSync generate an ID for us? Yeah, I think I actually saw that one in the answer earlier. AppSync will automatically generate the ID on the server if you don't pass one in. Do you add key directives mapped to DynamoDB global secondary indexes on DynamoDB or do we need to use something else for those? Yes. The add key is essentially just doing that under the hood. So if we look at the schema that we created earlier, that's exactly right. In fact, the name that we're passing in here is the actual global secondary index name. So I created a GSI called post by username. And if I go to DynamoDB and I go to indexes, I see that it's post by username. And the way I think about indexes and if you're a back end developer, if you've dealt with databases, you're probably already like familiar with this. But if you're not, and the index is basically saying, OK, like I have all these different fields in my database. I want to be able to start querying directly on these fields. So I might want to say instead of getting everything and not being able to like specify what I want, I want to say I want to like say I only want to get certain things that have a certain value within the content or the title or the username or so on and so forth. And then I can basically have a very performant query on this index and I can say it equals DAB at three or it's less than one hundred or it equals thirty five or whatever. And you're getting these very performant queries and these very like really good data access patterns that are starting to become enabled when you start working with indexes. And if you want to learn more about that, actually. I have a. I have a I would call this like an intermediate to advanced level like video that kind of goes into modeling like really hardcore data access patterns against DynamoDB with Amplify using the stuff we just whenever, but maybe in a little bit more depth. So I think I have to go ahead and drop off now because we're kind of finished on time and also have another call that I have to like get into in just a few minutes. So I just want to like say thank you for everybody. And I know that there are a few people that are running into some some issues and bugs and stuff. I would say I don't really have time to jump into all these questions, but I would say if you do have any any questions or things that you think are issues or whatever, I would go ahead and open up a new a new issue. I need to go ahead and clean up a couple of these older issues, but I will definitely get into the to the newer issues. Yeah, thank you for checking this out. Thank you for coming. And I hope you learned a lot. And if you have any questions, hit me up on Twitter and I will see you all around. Thank you. Bye bye.