Go from frontend to full-stack development faster with AWS Amplify

Hello. Awesome. This is working. Good afternoon everyone. Thank you for joining us. Uh my name is Nikil. I'm a product manager at AWS Amplify. Uh I'm Renee and I'm also a product manager at AWS Amplify and we are super excited today to talk to you about uh our new next generation of backend building capabilities at Amplify, which is a new "code first developer experience."

Just quick show of hands how many people in this room have used Amplify in some capacity? Ok. So about I'd say 25 to 30%. So, so uh that's great. So for the folks who are, who've used Amplify, thank you for using Amplify. We're super excited to talk about Gen 2 and for the folks who are new to Amplify, we'll kind of start with. Uh before we kind of dive into the demo, we'll actually kind of start with a little bit of why we built this new generation uh of Amplify.

So, Amplify serves front end developers and, and what we've observed over the past decade is that front end developers have become full stack developers. Uh and there are a couple of technological advancements that have made this happen. So if you look at, look at the architecture of a full stack application on the front end, we have, you know, you're building your front end with uh HTML, CSS and JavaScript. And then there are frameworks like React and Tailwind that help you accelerate building your front end. And in the back end, historically, we've always had uh where we store our data, we've got our databases, servers, server side languages, where we write our custom business logic and APIs to access data.

Now, this historically would always be servers and required teams to manage and scale infrastructure. But over the past five years, this has changed um well, actually longer with because Node.js has become ubiquitous over the past decade. You know, now developers can write JavaScript in the front end and write JavaScript in the back end. We've had a serverless movement. So what that allows developers to do is to actually just focus on their code without, without worrying about infrastructure at all. And that's really been a game changer for full stack development cause now to build an app, you don't need to be an infrastructure expert.

And now on the API side, we've seen uh the evolution of uh APIs to include GraphQL. It really gives front end developers control over how they access their data. So what we've observed is that front end developers are now driving cloud decisions and that's kind of why we built Amplify, we built Amplify to make it easy for front end developers to build these full stack apps.

We so we built these tools to cover the life cycle of application development, you know, but there's three core kind of pillars. We have the first ones around building a back end, second is round hosting and the third is around UI building and we'll walk through like the tools a little bit. In terms of all these are all the Gen 1 tools that we offer and we'll walk through the history of how we got here to Gen 2.

So we started in 2017, we launched the Amplify JavaScript client library. It was a way for you to connect to your AWS services and it gave you a simple uh intuitive API interface that lived, lived on top of the AWS SDK. So you could, you could run uh you basically had an API you have and they were all use case specific. So you could start with a GraphQL uh REST and, and your API uh surface was simple. We expanded support over the course of time to include mobile and cross platform as well.

And in 2018, this was a big launch for us. We launched the Amplify CLI this was a uh a tool that developers could install locally and run simple commands like amplify add and we deploy CloudFormation stacks, generate infrastructure as code templates and uh and actually give developers features like environments and uh and, and, and functions and the whole whole bunch of other features that developers could use locally alongside that we also launched Amplify Hosting in 2018.

So this uh uh gave developers a way to host their front ends, but also set up full stack CI/CD, which made it easy to set up production, staging uh pro uh test environments just simply by connecting your Git repository. And in 2020 we launched part one of Amplify Studio as the artist, formerly known as Admin UI for the folks who've used Amplify for some time. Uh, it, it was a visual companion uh to the CLI. So you could configure it gave you a visual way to configure your data model. And then it also gave you the ability to manage and administrate your back end. So we had file data and user management.

So this is an example where you know, users can just generate automatically generate seed data for their back end. So if I have a data model that's got like for home listings, you can generate that just at the click of a button. And in 2022 we focused on um UI building. So we made, we gave developers the ability to go from Figma designs to actual React components. And we also had a UI component library um that gave connected components. So what you see on the right here is the Authenticator component that developers can just write a single line of code and get entire sign in sign up workflows configured in a matter of minutes.

And we've seen hundreds of thousands of customers use Amplify to accelerate time to market and our customers of all sizes. Buzby is a startup, they built an app, a mobile app that automatically detects crashes. So if you're on a bike ride and you fall, it will automatically send a notification to your friends and families. They used Amplify to accelerate time to market in three months and they saved tons of money in development costs.

And then the other other end of the spectrum, we have customers like Amazon Music. Amazon Music uses Amplify for a cloud playlist feature. So if you're queuing songs in a playlist with friends um that also syncs offline and, and syncs back to the cloud. And we've had individual developers also adopt Amplify and we we, we continue to interact with developers online uh through Twitter Discord. And we, we see a lot of engagement online as well with the developer community.

Over the course of the past 5 to 6 years, we've synthesized feedback and I think it really like there's 3 key things we kind of uh taken away. The first piece of feedback is customers have loved the, have loved how Amplify CLI and Studio's abstraction works when it, when, when they're taking the beaten path, it almost feels like cheating. There's a customer quote, not mine to get going really fast, but it's also usually coupled with a strong interest to understand what's going on under the hood.

Um, what we've heard from customers is especially when they're trying to modify the back end to do something that is outside the beaten path, it became challenging. Uh, and part of a big reason for this was because our tooling generated CloudFormation files, configuration files that, that required customers to really understand how the whole system worked.

The second piece of feedback we heard was uh customers wanting a faster local development experience. So while working in their IDE, customers wanted to be able to deploy changes fast without waiting, waiting on long CloudFormation deployments. And they also wanted to work in a way where they were not going to clobber their teammate. So for example, if Renee and I are working on a feature, we can both work in our little isolated in our isolation.

And the third real area was around getting to production. Um we had the, the workflow to deploy multiple environments. Developers really appreciated the fact that they could set up these multiple environments but often from moving from a lower to production uh upper environment from, you know, like dev to staging to prod required uh configuration that spanned the CLI and the console.

Um so customers wanted like a cleaner workflow uh to get to production. Additionally, they also wanted flexible deployment options. Hey, we, we, we, we work with the monorepo. We have a separate front end team and a separate backend team. We have custom pipelines. How do we set up this? How do we, we would like to set up the same kind of workflow that's in Amplify Hosting, but with our own uh with our own teams uh that mirror our own team's operations.

And those three points of feedback were really what we synthesized into Amplify Gen 2, which is a code first developer experience that we're now going to be demoing and I'm going to hand it over to Renee to take it forward.

Yeah, awesome. So let's really focus on what a code first developer experience is and there's a lot to cover here today. But the first thing really that's fundamentally changing is TypeScript will be the definition language for your entire back end. Um that gives you code completions as you go. So that's really helpful.

The second part of it is we're gonna keep on the Git-based full stack CI/CD workflow that we have from Gen 1 that means you connect your repo and we'll deploy it on every commit for certain branches that you want it. for.

The third part is we've looked at all the files that Amplify has been generating into the developer machine and really taking a hard look at what is how to make them easier to reason about.

The fourth thing is around the per developer sandbox environment. We want to create an isolated environment where every developer can iterate on their features without having to tamper with other people's code.

And no presentation is complete with our generative AI. So we've also made sure that all of this is trained with Amazon CodeWhisperer. So if you use Amazon CodeWhisperer, the suggestions are gonna be awesome.

And uh Nikki alluded earlier, we've got had a few different console experiences. We're now bringing them all together into one. It's gonna be easier to use for end users. You can deploy additional AWS services as you need and you can also gain all the flexibility that you care about, which is uh which you can extend via CDK or other infrastructure as code solutions.

So let's first talk about how do we set up this new code first developer experience. What does it mean when you have a application UI and really want to start layering cloud functionality in this new world. We're simplifying the setup experience to a simple command as npm create amplify at latest. And unlike the current generation, we're installing the Amplify dependencies directly to your project and not globally on your local machine. That means between different projects, you can version these independently.

So you can just add that we create a few files only five. And you can incrementally extend it with additional functionality and later take a look at these different files. These files are structured in the same way as we do in Gen 1 people love that we are use, we offer use case based developer experience and we're taking that forward.

So you can define your auth and federated identity configurations in the auth/resources.ts file and same with your data resources, which includes your database tables and lambda functions. And so your front end then ultimately gets connected up with that.

Um and just to kind of put it into perspective of how much we have changed. So this is Gen 1 on the left side with the same functionality as Gen 2 on the right hand side, there's no, there's no reduction in functionality we have reduced from 104 files down to 5 and it's easier to reason about and we're going to see that in a bit. Ok?

And so yeah, let's, let's do a demo. Ok? You gotta do that. Oh one thing. Do you see the screen? Ok. So this is the app that we're gonna be building today. So this is a Hacker News clone. You know, my, my favorite website for thoughtful discourse. And so in here we're gonna be able to, yeah, one guy laughed. I love it. So in here you're gonna be able to see different articles that people can post. You can see comments that people have, you can create new posts and also just sign in, sign out to the regular cloud workflows.

Now, this entire app is an XJS application and right now it's just UI code, there's no cloud logic yet. So everything that I've just shown you is hard coded. And so now let's layer in some cloud functionality to to the workflow. As I mentioned earlier, all I have to do is run a simple command to um to uh scaffold out the Amplify functionality. And um and when I, when I run this, oh ok. And when I run this, it is uh simply just creating a few files in my dependency folder.

So I've got the, I've got the, I've got the Amplify folder here with a auth resource, the data resource and then like a backend file that just brings the back end uh the different categories together, take a look at these individually. So in auth we're trying to really create a use case oriented approach

So that for example, if you want to configure email authorization authentication, you can just say yeah, email is true and you can kind of expand that as well with additional settings as well. So you want to say phone number is true. Now you have phone authentication backups. You can also expand this with additional functionality that you might need. Like for example, email body verification or using external providers like social providers like log in with Amazon Google sign in like your usual suspects.

When you have social uh uh social login, we've obviously also got other features like multi factor authentication, but it's gonna be a little bit outside of today's session.

The next thing I want to show you is around the data definition. We really wanna make sure you can, you can model your application data model as if it is um as if it is just objects from your client side code. So for example, in this case, this is a data model for to do apps. So I can say to do is a model that contains content and has a um which is a string and with an authorization rule where if I'm assigned it to do, I get to do everything with a create read update, delete. But if I'm only a publicly unauthenticated user, I should only be able to read from it right now.

We're not building a two new application. We are building a, we're building a um a hacker news clone. So let's take a look at our application code and try to model now our back end to meet the application requirements of my front end.

If I go to my application code, now, you can see that I've got my, I've got my posts here and posts have an id title link and some sort of comments. So I'm just gonna go into my, I'm just gonna have my application icon on the left side and my back and code on the right side and try to model it the same way.

So I'm not doing a to do app. So I'm having a post app and I need a title and uh I need a link which is a url and I will have a comments, which is a, has many relationship with a comment model. So now I realize I need to also add a comment model and I'm really just using the benefits of typescript here to use type completion to kind of let me type in the next thing that I need to worry about.

And I'm also going to copy the same authorization rules over. So that just works. Ok? So this is as simple as defining a database uh database with an api that exposes create read update and delete operations like it is, we literally just look at what our fronted needed and created a back and forth.

Um now I'm gonna just start now. Uh I'm now just gonna start a thing called our sandbox, which is the mechanism in which will allow developers to iterate on their back end continuously over time. Uh before we jump into that, let's oh sorry, you want me to profile. Ok. There you go. Always make sure you deploy to the right region.

So let's come back to the slides for a second and uh talk about this full stack iteration experience that we're gonna show you in a second. So when developers are telling us that they want to iterate on their back end, they, it is really important that when they develop in a team environment that everybody gets their isolated cloud sandboxes.

So when I ran that command mp xm five sandbox, it creates an isolated cloud sandbox with real aws resources that, that i should use for development purposes. And it gives you a few benefits by really having a development uh focused cloud sandbox.

For example, we can, we can do uh resource hot swaps. That means when you make a change on the back end code locally within 1020 seconds, we'll make the change in the cloud. So you can feel like this really fast situation experience.

The next thing that we want to really solve is the the time the waiting time that developers have to do and just how much like active time they need to do to iterate on their back end.

So for example, I'm going to take gen one here. If i add a database table, i needed to create a graph pl file which is now replaced with typescript. I need to run the command called m i push this command would take a few minutes to run. And then only after the command has completed, i can look at my front end code and update that and then validate in my browser.

So every iteration cycle is measured in minutes in this environment and this is keeping that you have to keep going, doing this. So you have to edit a file again. If you want to update a field, push wait, update a front end code and then validate in your browser. And then the next change happens.

So this workflow, we wanted to completely rethink and just build a better experience with generation two. So with m five generation two, we're really introducing this concept of a cloud sandbox that you run once.

So you run this mp xm five x sandbox at one time at the start of your development. And it's gonna watch for changes, studio or back end definitions. And as those changes come in, you can just immediately update the front end code. There's actually no waiting period for deployments that you need to take care of.

So updating a database table, updating field, adding authorization rules have now compressed from five minute or multi minute iteration cycles down to a few seconds. And the best way to show this experience and the slickness of it is in a demo.

So um the best let, let's start looking at our application use case. Let's try to get this sign up and uh sign out um sign, sign in and sign out experience up and running.

So in here there is a um login component with email password and know i need to um and also in an environment where i need to create an account. So the way i can um the way i i edit that file is by looking at our uh by looking at our applications login page in our login page.

We've introduced this authenticator component which is a react, which is a react component that, that actually understands what my backend definition is. It knows that i have set up that i want to do email authentication and dynamically scaffolds out the log in ui for me, this authenticated component can be fully styled to match your brand.

You can see i have used just like a common style here. That is the default that we offer. But if i comment that out, you'll see that uh it will look a little bit more scrappy and you can style this to however you want as well.

And the other thing that this authenticator component gives me is the ability to understand some of the life cycle hooks that my application provides. So for example, i want to know that if i'm authenticated, they should redirect me to a particular page. And if i'm unauthenticated, it should handle, handle the experience differently.

Now, in here, the other component that we should look at is the indicator of the profile. You can see i currently hardcoded renee up there. And that's just because uh that's, that's pure u i but we can actually make that also work with real co logic.

So in this application component in here, you can see we've got the login user information. I'm just going to remove the default there and talk through the capabilities and with our m five libraries to become aware of your back end.

So it knows that my backend exists, i can actually get the current user information and i'm running this inside this hook uh inside this run with server and fly context function. This particular function is specifically designed for njs and allows us to have a first class support for njs.

And it allows basically the every single repress within it to run in isolation of each other. It's a security feature we actually work really hard on because it's a big problem in service site rendered applications where you get uh cross token contamination.

So basically, this allows me to have this isolated environment where i then get the user information and then uh can, can sign in. Ok.

So now let's uh let's try to sign up in a, in a real world environment. This is all real code real time. So we gotta thank the demo gods today. Ok. So that went through and you can see this authenticated component handles, multi factor authentication and also email configure uh email verification.

And um and, and it, it would also work with like s ms and so on and so forth. Ok. Wow, this is uh this is always the trippi part of the demo because i'm never quite sure if we will get the email through. Maybe i'll try to do you want me to give it? give it, give it a few seconds. Ok. This is the, the part of the life demo where i, where i get nervous we talked about earlier.

If uh if there's any concern, this is ok. We got it nice. Ok, son. There you go. Perfect. Now i'm authenticated and if i um if i look at just uh this experience, uh i'm now fully signed in as a user and i can kind of continue uh continue the workflow.

Uh actually, yeah, just making sure that i really am. Oh no. So i think i didn't do the auto redirect. Ok. Now i'm signed it. Great.

So now let's look at our data experiences for a second. So for example, how do we actually show the uh the application data that allows me to create a new post or sign in as an end user?

If we look at, if we look at our application um data model, we have designed it fully in typescript. That means on the client side, we can actually stream in the types from our data back end, these types from our data backend allows us to get code completion on the client side.

So we don't have to do any like guessing work around how to make api calls or how to fetch data. We'll we'll be able to basically generate these data clients that allows me to fetch data.

Uh with let me go to my, let's let's go to this page first where we create a new, where we have a form where we need to create a new post form. So as i mentioned, we need to import that particular data client. In this case, i need to be an authenticated client. I import it. And i just let type completion do the work for me.

You can see, i don't need to learn any special api routes that i've hard coded as strings anywhere that, that it is strictly enforced in the programming language itself. And then in here, i can see what i can pass in here. I should pass in the link and uh link i get from the form data, i call it url here. So let me enter that to string.

And the other thing i need is the title and with that, i'm just gonna call that title too straight. Ok?

Uh next, i'm just gonna log the information here so that we can see the data that we created. And if we also have any errors, ok.

So let's go to our application and uh let's hope this works. So um aye all neck and i'm going to use this url hit submit. And if we go back to our application now, you can see we successfully submitted this uh this particular record to a database.

So i think there's probably no other way that i could possibly imagine aws where it can create so quickly a database set up the authorization logic for it, get an api endpoint and call the api woven one application next.

Uh we, we should probably fix up this page. You can see it's, it's a little bit uh iffy there with some hard coded content. And let's uh let's just fetch data from there. Cool. So this is my hard coded content right now. I'm just gonna replace all of this

"Um and I'm gonna make sure I can fetch the posts. And in this case, I'm gonna use the public client that I talked about earlier for like read only access, I can get the post and then get the list of those posts. And if you look into here, oh, there's like some errors here. Something is not quite right. So it looks like if we hover over here, oh, on the backend definition, it actually told me that the value could be null, but my frontend didn't expect that. So the TypeScript programming language actually enforces correctness across these two different boundaries. And so there's a few ways to fix that. Um I'm gonna actually go and uh find my, find my uh data dot resource file and just make sure all the errors get addressed. So in here, the title should be required and the link should be required. Ok? And if I hit save now, great, I like on left side errors are resolved. But if I look at uh the other page. Oh no, the new page I didn't handle that case there. So this is really the fast paced iteration that we're talking about. You, you define your backend the IDE immediately instantaneously tells you where there could be potential errors and you can address it without ever having to go through a slow cycle of like deploy wait update and then validate.

So in this case, I'm just gonna um pass in this link as a default and uh good old trusty empty string has the required value. Ok? So now I fixed my application um backend. And if you'll see as I was making these changes, it was updating the backend for me. So within 18 seconds in the background, it was updating the cloud backend. So if you go to the icon, these resources are updated already. Um I don't, I don't feel that because I'm, I'm already in the flow of editing just the front and back and together in my IDE.

So uh in this case, now you can see the application data is getting loaded. Um there's some, some little error here somehow. It says one comment, even though I didn't really create a comment just yet. And this is uh just due to a small uh small functionality that I want to show you today. So one thing we talked about is that our posts can have many comments. So traditionally speaking, you would want to be able to load them together. So there's two ways to load things and amplify. You can either lazily load things by calling the comments as a function. But one thing that happens here is we create a waterfall of a network request. So for every single post, I fetch every single function. And if I have a lot of posts, that's gonna be very slow. We want to make sure that you have the option to do both eager and lazy loading.

So in fact, we support a functionality called selection set which allows you to use full on GraphQL like string values here to say exactly the data that you want to receive back from the system. So for example, I already said I wanted all the comments. My application needs the links. Let's see where are the additional errors id and title is also required. And now my application is making a single request but fetches all the necessary comments that are needed for me in order to calculate, for example, how many different comments there are in this this particular application. If I now refresh the page, you'll see it says zero up there and I can continue going, going forward in here and and see how, how to update the subsequent pages real quick. Just so we we can see the the the application running live.

As I mentioned, you get the use cases of uh CRUD operations. So um that means you can do list and get operations and get the public client again. Just let the code completion do the work for me. And uh I'm gonna pass in the id that I have from my url route. So this particular url route is getting passed here and I'm just gonna get the post. And now if I go in here, you can see the little heart that I used earlier is now changed to liked. And so this this application is now using um using the the real backend data.

There's another functionality here around adding comments to it. Um the the thing with like comments and you know, because this is my favorite website is it's, it's, it's a lot of like passion in, in, in, you know, hacker news comments, right? So we want to make sure that these comments stream in in real time as well and everything i've just shown you right now is requests that are happening on a server side rendered application. But we also have a great clientside real time experience to, to consistently fetch your data and set up the uh set up the real time subscription. Let's go there real quick and find our trusty component to fetch your live comments.

So this um so first, I'm just gonna generate a new API client that I'll need for um for my uh for my backend. So in here i'm gonna import to generate find from, you know, it was amplified data and then import the type for the schema from our pet data. Amplify. Oh, sorry. No amplify data slash resource. Oh, I love type completion fixes so many errors for me. And then I'm gonna put my comments into a state. This just let React know what you render in a given time. And then the last part I want to show you is uh is probably my favorite feature.

I can actually go in here and create a um from the, from the client again, find the comments and i could list them. But then that would not be real time. I can actually do a thing called an observe query. And this observe query allows me to get a real time feed of the data as it gets updated the lead and modified. So in here, if i um subscribe to this change, i'm just gonna get all the items back from that change and uh set the comments to the items that are returned. And because i'm uh doing a subscription, i also want to make sure i tear down the subscription after it's not needed. So i subscribe there. Ok? Cool.

So let's see what's going on here. It's a little TypeScript arrow. I didn't pass an empty array a classic mistake and that's all resolved. Great. So now let's try to add a few comments in here. Hello world, right? And um and see that application uh that refresh live and as the event comes back in round trips. It's um uh i, i love front end. I mean, i, i really do. Uh and if i add it, it's just gonna be real time and as it's added, confirmed in a database, it's gonna be coming back here on my UI. Cool.

So this is, this is just like a very quick way that uh we have shown you how to create your application uh backend uh and connect it up with your front end and iterate together. The demo itself was just a few minutes. So it is really awesome to see how quickly you can create uh all these cloud resources and really hydrate you your UI with cloud logic.

Well, and for the for the last oh there's also a few other features i didn't get to show that was available in gen one that i, you know, just couldn't fit into the demo. We still support our capabilities to generate UI from your data model. So if you have a form that needs to uh that can update or create a data, data model, you can just instantly generate that as like a React component and use it in your code. Our UI building capabilities were from Figma to code. We've actually worked with Figma to publish a um official Figma plugin. So you can use this completely within Figma and you don't have to go to a different console or a different tool to just get the generate UI like live functioning UI code for your uh for your React applications.

And so the, the the other part that we will also support is the ability to go beyond what we just shown you today, like AWS has a lot of services and they all are really, really powerful and we want to make sure that there are no limits to your amplified project. Amplify gen two is completely built on top of CDK and CDK supports all the AWS services that you're probably falling in love with already. So you can actually extend, for example, the amplify stack using CDK and add location services to it or any other AWS resource you could think of.

And the last part of our demo today will be around how we go to production with our application. Everything i just shown you was in development mode, we really optimized in a fast paced iteration, but there's a few additional requirements for production. And so Nikil take it away.

Alright, good job, Renee. I'm glad the demo worked out. So i hope the final demo works out too. So, uh so what we just saw was uh completely local, right? So we're working locally working on your frontend, think about the cloud sandbox, like your backend dev server. So everything working locally, but now you wanna deploy like a new feature that you wanna share across your team.

So with gen two, we've introduced this concept of full stack environments. So every that map 1 to 1 to git branches in your repository. So let's say this is your dev team and you have two branches, you have a main and dev, you can literally connect your main branch and your dev branch and you get a, you get two full stack environments deployed zero config as as we'll, as we'll walk through in the demo.

So what what happens is you connect your main branch and we deploy a backend and, and then we deploy an host to your front end. And similarly with dev, you can set up your dev branch and you get a dev full stack environment. This for the folks coming for the uh folks familiar with am in gen one, you're required to make, have a lot, lot more configuration where you have to configure a git branch, you to configure a backend environment, link the two together, set up service roles.

So and and then also make, make specific changes in you in the cli when you're pushing changes from staging to production in this workflow, this is how git operates. So if you're gonna move from staging to production, create apr to pro create or if it's your main branch, create apr to your main branch me, merge it, it will trigger a build. So any updates that you made in your dev branch will, will deploy to fraud. There's no extra configuration required.

And one a piece of feedback that i didn't cover in the initial uh segment was that a lot of customers, especially, ones were new to amplify. I feel there's a lot of overhead for them to learn the different tools we have, you know, as you, as you walk through, we had studio, we have cli we have a console. We've got um we've got hosting.

So what we've done is really centralized the experience in a unified console. So this is really like the next version of the five console. So uh it, it gives you a central place to not just manage your git branches and your hosting setup, but also all the backend resources that you deploy. We'll see that shortly and we've also launched, this is one of my favorite features. Uh we basically centralized environment variables and secrets.

So now the way for you to manage your any, any sort of custom environments, let's say you got specific database url s or secrets that you wanna manage. You can you enter them in the console and you can access them locally. So in this example, right here, uh we're actually setting a secret and we, and we can access them via like a uh like a secret function that we've made available.

Cool. So let's let's go ahead and demo getting renee's application to production. No"

All right. Can I switch this? All right. So uh I'm gonna kill the sandbox and as you can see, it asked me whether I would like to delete the resources. Now, generally, when I'm, if I'm done developing, I can just go ahead and delete resources. I don't need to keep them lying around. And if I restart development, we'll just spin up resources again. But this is optional if you prefer. If you're like, I'm taking a pause, I'm coming back. You can just say, you know, keep your, keep these resources up and running.

But what I'm going to do, so we've already pushed the code to get. So this is already the code for that rene demo is already in my git account. So I just go visit the AWS console and then from the database to console. I go to amplify, I want to make sure I'm the right region, the right region. And a as you can see, this is the existing console for the customers. Familiar with m as the existing console we've launched, we basically built a new console that's only right now available through the, for the gen two experience where the u i is completely, we built the u i from ground up.

So this place i i over here, i get the option to either start from a starter. So if you're starting in the console and you don't have anything, you can just deploy our next starter. We're gonna populate this with more templates by g by our g a date. But since renee already built an app, what i'm gonna do is go ahead and connect that git repository in this workflow. Everybody look away right now and then the two factor off is gonna kick in. This is the hard, but this is always the hardest part of the demo.

Oh i have, i think i gotta hit the send s ms button. Now you gotta make sure your phone is not on, do not disturb. Ok? You successfully entered your code. Awesome. Um great. So now it's listing my repository. So as you can see the first one, this is the rein and demos is where we pushed the code to and now we're connecting the main branch because we pushed the code to the main branch.

Now, as you can see, this is this whole experience is zero config as a developer, i don't really need to do anything like i'm just clicking buttons. We auto detect that this is the next js up front end and this is using amplify on the back end. And we've also got a new service role that automatically hand like that automatically deploys the resources for you. And it's, it's, it's also scoped down to have cloud formation access.

All right, i'll hit save and hello. Yeah. All right. And that's deploying my app and as you can see a build is ongoing. So um what i also did, i i kind of cheated ahead of time. I i deployed an app that's already been deployed. So why don't i just kind of pivot to that? So this is same version of the application that's complete. Let's finish deploying.

And as you can see in the central console, i can access all my hosting settings. So if you've used amplify hosting before, you know, you have your, you have your access control, your environment variables. And like this is secrets is the new feature we just introduced. And as you can see, there are some features that are still in development, custom domains, you're gonna be add, you're going to be able to add your custom domains here as well.

And when i click into my main branch, that's when i see my build. And as you can see, my build has successfully deployed and it's deployed its own set of backend resources as part of the build. And one piece of feedback, you know, customers gave us from, you know, it's like, hey, amplify does a lot of awesome things, but there's a lot of resources that get deployed to my account. I'd love to be able to see them. So we've made it easy to be able to actually to see the list of resources.

So renee's application actually deployed a whole bunch of things, right? So if i wanna find like the the im the im rolls that we set up, you can very easily, easily find, find them. As you can see, this is, this is a lot of the heavy lifting that we do that you would otherwise have to kind of build yourself. And then for the, for the use cases that we um we kind of have first party support for, we, we actually offer management experience as well uh as well.

So if i go to user management, i can actually, you know, create, create a new user, you know, um manage the user here. So i can, i can see if the group, if the user has members or any groups, i can add groups, let's create an admin group and then i can actually add the user to the group, right? So similarly for data, um we have, if, if you, if you're coming from studio, we're bringing a our data manager capability.

So you'll be able to browse your data directly in the console. This is not ready yet. But like we give you give you access to the api playground. So this links out to the absent console where you can, you can query everything. Uh you can basically uh query or mutate your schema uh if you want to test, test your uh back end. But having said that what we're gonna be doing is we're actually gonna build all these experiences in line into the coo so you kind of have a central place where you can actually administrator your full admin your full stack app, but also get to the underlying services if you need to, right. That's kind of the general philosophy we take we're trying to give, give you a a really great um like first party experience, but give you access to everything underneath and make it visible to you.

And another cool feature i just wanted to show here was the ability for you us to deploy multiple to show how easy it is to set up multiple environments, right? So in this case, i let, let me actually go to this repository. All right. And what i'm gonna do really quickly ii i oh before i do that, sorry, one second, i'm gonna set uh we have this feature called pattern matching. So i'm gonna set a pattern. So any, any branch that's, that matches star in my repository will automatically get deployed.

So now what i'm going to do is set that pattern and now when i go to my repository, let's just quickly create a dev branch. And if i come back to this application, there you go. We have a dev branch deploying. Uh so the dev, now this is gonna deploy an entirely new set of resources, right? And you know, once you this will s drastically simplify the the promotion work flow because moving from dev to prod is basically what you do and get.

And once we have pr pre pre pr previews is one of the items that you see coming soon. This will work with uh preview. So you can spin up ephemeral envi environments. So you create a pull request, you'll have an ephemeral environment that that that stood up. Merge the pull request pr is closed, resources are deleted. So that's, that's that's coming in the pipeline as well.

So uh i haven't demoed the secrets experience, but the secrets experience is actually my favorite one because you can define everything centrally. And there's no no issue with like git conflicts git mergers, it's all managed via code.

So just to kind of take, do a, do a recap of what we just went through, right? We went through uh starting uh like let's let's actually link it to the feedback. So the first area of feedback was too much magic. So what we've done is we've made typescript available uh for the full stack with a file-based convention. So now as a developer, what you're doing is you're very, being very intentional about what you want to add to your project. You're not starting with an abstraction that then leads to a whole bunch of files that you don't understand. So, you know, you know, everything that's getting added to your project, it's predictable and maintainable.

Second, uh we've, we've got the sandbox, the cloud sandbox for faster iteration. So in this uh video here, this change will take between 15 to 20 seconds and we've been working with the cd k team on this. So if you're, if you're familiar with cd k and coming from cd k, this will uh this is basically built off the hot swap feature. And we've made this workflow a workflow here that used to take about 1 22nd, 120 seconds. Now takes between, in this case, 13 seconds, but usually between 10 to 20 seconds. So it really improves your local developer experience and we're gonna continue to expand the use cases that we we support hot swab for.

And finally, i think that uh the 3rd, 3rd area was around feedback for production, like making production simpler deployment simpler. We've reimagined the full stack. Uh the full stack deployment experience, you start with your git branch, you deploy your git branch, you get full stack in right, you get full stack apps and we built workflows for you to share resources across different branches too. If you don't want to deploy a new set of resources. Uh this works with custom pipelines. That's something i actually didn't cover. Uh so you can, if you, if you're, if you're working with codecatalyst or you're working with code pipeline and you want, you want that control, you can use that we have np, we have n pm packages that you can just insert in your bill spec and you get this, you basically get the same experience uh with a little more configuration. The benefit you get with our uh unified console is that it's all kind of zero config and uh and, and, and centralizing secrets is also a way we've kind of really simplified our production, roll out and made it, made it flexible enough that it can fit any of your workflows.

And, and that's it. We're super excited for you all to try out uh amplify gen two. And, you know, we've got a little bit of time left and we, we kind of were very intentional about that. So we could get some uh you know, you could field questions from folks in the audience and i see, see a couple of hands up already. Um maybe i should go. Is there a mic that we can take around or no? I think we can just repeat the question. Ok, mike. Sure. Uh why, why don't you start there? That suggests the consequence? Like those things could be today. Yes. Correct. Yeah, that's correct. Just the console like the pull request preview was one example like that is already supported in gen one. It's just not in the new reimagined console yet.

Ok. What's up shark? Yes. Yes. Exactly. Yeah. And we have a format with which we create those secrets. So we know what uh what those secrets are for the m five project while back there. Chest of breath that their boss. Yeah. Good question. I, i don't know if you saw it today. The database console launched this feature around called, i think it's like my application application

"So our, our plan is to basically give you uh to, to tag these resources in a way that they say, hey, this is your amplify application and, and then you can link to like cost explorer and things like that in general though, when you're developing with amplify, it's like i, i think unless you're using something like searchable, almost all features are free.

Yeah, exactly. Like you can get started for free.

Yeah. Um sure. Right there now we can leave one. Yeah. Um so in, in my demo earlier, i i have a little authorization rule um modifier as well on my data model, there's one authorization rule that's called owner off. And when, when you add that every time you create a record as assigned in user, we actually attach that owner information to the record. So then you can base apply filter space on that and say um and say a group of people that owns this record can you know, update and delete them or or any additional rules and this all supports also in a real time environment.

Hm by by. So, so, oh, so that is uh i i can show you real quick. Yeah, i might need your fingerprint. Oh yeah. Ok. Did this? Uh oh looks like we we couldn't, let's see if we can get the slides up again. I need to change keyboard layout. Ok. So you can see this owner authorization rule. In fact, um i'll let our in line documentation do the work. So it basically allows you to set access on a per user basis. And when you then end up creating a record, we attach that information to this data record, right? So, so now you have to link the end user information like the sign incognito user to the data that you're owning. Exactly. Exactly. Yeah. So that's where you can set that up and this supports a variety of combinations as well. Like it supports a list of owners. So you can say you and i we are allowed to edit this word one particular data model or it supports um cognito user groups. And that happens uh in both uh static where you say all admin group members can do it or dynamically defined. So if i'm part of um group of part of like an editor group, i can say specifically this data record at run time should have editor access. And after i'm done with it, only the readers should have access like, so there's these kind of capabilities can be built in.

Hey, are you here? The i try. Yeah. Yeah. So, so the the question was how does authentication integrate with other providers effectively? Right. So uh we, we support connections to r i dc compliant providers. So we actually have a integration with off zero that you can look up in our documentation and um we support that in both configurations. Either you want that to be linked up on the cognito side or you can actually use a custom token and credentials provider on the client side so you can reuse a native sc case that you might be using from another off provider.

My question is related. Uh, so i've used case where the, who spoke his brother that just at the m five here and elsewhere too. And so that's sort of, yeah, you go and do that, that this case.

Mhm is the yeah to kind of reference things. Yeah. Um oh, you might want to fix the slides real quick. So um on the question was if i have already a user pool defined, can i bring it into a project? The the the answer is yes at g a time we are, we are actively working on that functionality. So in gen one, you can already run m five import off and there you can bring in your existing user pools and you, you have a little bit more burden of like configuration, but it is often times the right choice when you already have existing resources.

All right then. So the information will also, hm that's the question. So, so the question, the question was that we use typescript here through and through like how do you adopt a usage for other platforms that might be in completely different languages? I think maybe i can talk about javascript real quick because that's probably the elephant in the room. What if i just use javascript but don't use typescript. Uh everything you see today is compatible with javascript. That's kind of like, you know, tldr. Uh and you also get all the type completions with javascript as well. So we use aj s do string that you just have to insert one time, uh which it looks like a comment and now your javascript is fully, it gives you type completion as you, as you use it. Uh you want to talk about maybe like mobile support or?

Um yeah. So for mobile sup uh so is there a question for a specific language or? Ok. Uh yeah, i mean, i, i think uh so what we're doing this is that we're making all these available as cd k constructs. Now, this is not available just yet across the board. But uh because they're cd k constructs, they might, they're also gonna be able to uh be generated in different languages. So that could be a, that could be a path to, you know, if there's a specific language preference that you have, you can use the cd k construct. Um but what we're also gonna build tooling like as you know, it's with studio, we have a visual experience, right? Uh where that, that allows you to basically configure things visually. So we will build like helper tooling that helps you generate like he helps you generate some of the typescript code. If you're not familiar with typescript. So i oh the court.

Ok. So yeah. So the question is what happens if i then offer, for instance, the cd using the cd a construct in a different language than what my front end is, right? Um so the the underlying protocol that we're using is graph g nonetheless. So in this case, in your particular case, you can use any code generation tool that is compatible with graph code. And there's a range of these we offer built in code generation for android i os flutter, uh which is sorry, java clan swift and uh and dart and, and javascript and typescript. So you can use that or you can use any off the shelf graphical code generation tools and there is a range of them, it's compatible for them all.

Yeah, like that. My question is about the question visa if i understand correctly, if your sources are already that there's no, we the is the question that um the custom domain that says coming soon. So the custom domains are for your right will be applied to your front end. So there's two parts of it. There's a front end and the back end, right? So the front end is also hosted. I should have actually clicked on it to show you that the application is hosted. Uh but uh you can add a custom domain to your front end and we, we're as of now, we're not doing anything to the back end, but you can also set up rewrite rules. So your front end can point to your backend api s but it, it's all kind of linked. The custom domain feature is linked to, to the front end. Does that answer your question?

89 be i'm sorry of all. Yeah. Oh the, the, when they're gonna, so everything in the console that's coming soon will come, will come in will land in by q one. Our, our goal is to basically g a this functionality uh you know uh there in the first half of the year is when we're planning on g a in this functionality. But everything you saw on the console is a actively being worked on right now and it'll be, we're gonna start shifting them less incrementally as they get available.

Yeah, cool uh here in the middle, ok? In gen two. So we had the slide where you could just use, you could write cd k in line in your project. So if i let me see if i can find that slide um real quick, it's gonna be a fun click through. Yeah, right here. So you can write. So this example uses like location like map services but like we are our, our docs actually have i think have an sns example, but you, you can, you can write this in line in your projects. Unlike gen one where you had to run like an, a custom command and then it almost created like a separate project inside your larger project cd k versions and stuff like that as you to manage, you can run, you can run this inside your application inside your uh amplify back in code. And and i think the other benefit here is you can actually reference all the all the existing resources from amplify that we generate because we end up creating um cd k resources can see in like that resource dot ts file. Actually, what's being returned at the end is a cd k construct. So you can reuse that constructs information like the api url and stuff like that within your, within your additional resources.

So there was some, some more, there was one more question i think so. Not right now. Uh we, we've launched this as a preview but at g a, we will offer a migration path to assist you to get from, from um gen one to gen two.

Ok. Any other questions be releases between now? Yes, yes. We're gonna make features available as, as they uh they are cooked first one next week. Actually watch out go. Any other questions?

Uh ronte. So um the question was like, how does the, how does the backend functionality work in terms of the api contract? Right. Yeah. So under the hood, it is a graph g api but you really don't have to worry about the implementation details of that, right? You can see you are just like calling it as a function, right? So for you, that graphical protocol is completely abstract away um whether or not it uses rest or graphical in that case, doesn't really matter for you as an end user. There's a few benefits though for it to have been built on graph g. Remember that like where like get the posts and then the comments individually, right? Like every time i would have to do that and the rest api i would create this waterfall of network request. But in in this environment, due to the benefits of graph g, you can just make a single request and get all your data back that you need to hydrate your app. The second benefit that um graph cup provides just out of a box. So is real time and this is true real time. This is using web soccer connections to receive messages and then you know, you can display that in real time, not like uh http streaming approach to.

Yes. Yeah. So the question is like, how do you, for instance use some of this with rest api? So um a lot of these frameworks nowadays built in a api rod functionality. So this is actually fully compatible with that as well.

Yeah. So uh actually with hosting next app on aws, we offer managed like you, we basically offer you the api rods feature built in. So that would be one way for you to, you know, get a rest api if you're, especially if you're just proxy to a function.

Cool. I, i think that's it, nikki and i are gonna still probably hang around a little bit up here. So if you have any questions you wanna ask us privately? Thank you so much for showing up. I appreciate it. Thank you."