AWS Amplify: Scale your web and mobile app development and delivery

All right. Hi, everyone. Uh first off, welcome to re:Invent and thank you for making it here so bright and early on day one. Uh I've been doing re:Invent, I think six, maybe seven years. And uh this is the first time I've had a, a 30am session on uh on Monday. Um cool. So thank you again for being here.

Uh today, we'll be talking about app development. Uh hopefully that's why you're here. Uh we'll be talking about app development, especially how customers like yourself can accelerate app development in your organizations, how you can make sure those apps are actually good, so high performance, uh good user experience, et cetera.

Um and especially how you can leverage investments you might already have in your company. So APIs databases, identity systems, dev ops, processes, etcetera. And as we do that, we're gonna walk through what we've launched and Amplify, AWS, Amplify the last couple of months to really make that easy.

Um this show of hands just so i, we kind of know who we're talking about how many custom, how many folks in the audience today have used. Amplify before. Ok. The lights are bad, so I can't see that well, but I think I saw about a third, uh uh about a third. So we'll do a little bit of uh intro, intro as well. Before we, we dive deep.

Um my name is Mori Viv. I'm a senior manager of product and Amplify as well as a few other products in our front end, web and mobile space. So uh AppSync and Device Farm. Uh I'm really excited to spend the hour with you today and hopefully uh find some time with you all throughout the week as well. I'll be sharing the stage with Arun. Uh and Arun. Would you like to introduce yourself as well?

Thanks ma um welcome everyone. Super excited to kick off re:Invent today. Um and also for stealing your coffee time in the morning. Uh my name is Arun and I'm a solutions architect manager with AWS, uh specifically focused on the developer experience for AWS Amplify. I'm not a veteran like Moes for re:Invent, but I'd like to think myself as a veteran being here for two times. This is my second re:Invent. So super excited to share information with everyone.

All right, thanks Arun.

All right. So with that, let's dive in. Uh we'll start off with what we hear from customers about app development and delivery today, what's working, what's not working. Uh and then we'll use that to segue and to Amplify and we'll talk in particular about what's new to address those challenges. And then we'll spend a good chunk of the talk. I think over half actually walking through the experience of building a modern app using resources you have in your organization. And we'll walk through both the development phase of the project as well as the post development phases as well. So how you can get the thing to get the thing to production? So when we, you know, whether you are doing, you know, you're an app developer building an individual app or whether you're looking at unlocking app development in your organization more broadly, you know, very quickly, it becomes evident that app development is full stack uh is full stack development and it's kind of obvious if you think about it.

Uh you know, most features in a modern app require capabilities of the browser or capabilities of the device. And at the same time, they require capabilities on the back end. Uh that could be AWS resources, it could be on prem resources, typically a mix of both. So app development is full stack development.

Now, if you're this front end team or the app developer, you know, very early on in your app development process, you realize you have to connect to all these existing, existing things in the organization, identity systems, APIs databases, other APIs. And what happens, you know what typically happens is a lot of bespoke APIs get created specific to meet the needs of a, you know, a particular application and that can work for a while. But then what also can happen is that can slow agility because whenever there's a change that has to happen, front end team and backend team have to coordinate. And it can also be just really daunting for the front end developer because they have to learn a bunch of different protocols, a bunch of ways of doing access control which can vary from system to system.

So what we hear from customers is they implement or if they don't implement, they at least aspire to implement some kind of back end for front end layer, a back end for front end API layer, something like you see in the middle. And the goal with something like this is to really unlock that app development. So the front end team only has to work with one set of interfaces uh instead of having to work with all of the different things on the on the back end.

And you'll notice that the back end for front end layer is not just an API when we talk to customers, it's an API but it also sometimes has to include its own own stuff as well. So in this particular case, it does include a database and the database is there to sort of supplement whatever existing systems of record you have in your organization today that have to all come together to build to build an app. Ok?

Yeah, all that said building that back end for front end can be quite daunting and sometimes you you might have seen in the industry back end for front end is called bff. Uh but I didn't put that acronym acronym here because it might get confusing with the other meanings of bff. But uh building that back end for front end is daunting and a few reasons why, you know, first it has to implement some mechanism of discovery. Like how can that front end developer figure out all the different data sources that are available to them? Uh what operations are available on those uh o on, on those uh um on that, on that data.

Second, there's a bunch of functionality that has to be implemented by that bff. Uh there i go, i use the acronym that bff uh for example, real time data. So if you think about a modern app, generally speaking, there's some kind of news feed capability, some kind of notification mechanism, you might want to implement that on top of a database like a mysql or postgres database that wasn't built with that in mind. It doesn't natively have a way of funneling updates all the way back to the client. So these are the kind of things that you have to think about when you build this back end for front end layer.

And then finally, if you're rolling this thing out in an existing organization of course, you don't want to introduce a completely new dev ops process. You want it to somehow plug into existing dev ops processes and mechanisms. And then on top of all of this, the backend for front and layer has to both introduce some net new resources as we saw in the previous slide, you know, and work with existing existing resources.

And when it comes to working with existing resources, there's even more challenges. So, you know, for example, what we just talked about, a lot of legacy systems weren't built to be consumed directly by an app. They may not meet the latency requirements, like they may not have caching and whatnot to meet the latency requirements. There may not be real time like we talked about or they might not have the granularity of access control needed to make sure that only the right users are accessing the right data.

We've already talked about the fragmentation piece. And then, you know, as you implement this kind of intermediate layer, it's important that the end objective actually gets met. Like does it actually make uh the app development in the organization faster? And as it gets rolled out, is it compliant with processes? You might have like one thing i hear a lot is back in engineers, you know, owners of systems of record are really concerned about giving direct taxes to app developers. They're concerned they're gonna do something to break, you know, to, to kind of overload the system. So that has to be another consideration as you build a layer like this.

Ok. So with that in mind, we've built Amplify and Amplify is meant to address the particular challenges we've just talked about. But more broadly, everything you might need to build web and mobile applications, what you see on the right side, you know, covers everything around app development. So starting from UI uh to building that back end uh to hosting your application to scaling it.

Uh today, we're not gonna be able to go into depth on all of it. We're gonna focus disproportionately on the build in app backend uh app app backend piece. But we'll talk about how that integrates with the, the, the UI piece and the hosting piece just so you can see the full picture. But the, the big focus is gonna be on building that, that app app backend.

And if you used Amplify today, you know, admittedly we've done a better job on building that app back end with a net new set of AWS services. So like if I'm starting from scratch, I don't have anything. That's really what the sweet spot of Amplify has been as of the last month, including a launch that Irun's gonna speak about. That's happening right now. Might not have happened just yet, but it's in, in progress.

Uh we've done a lot to make it easier to incorporate existing resources into that app back end. So that's gonna be a major focus of our talk today as well. How that app app backend can pull together net new things you need as well as existing stuff. Uh, you, you already have in your organization.

Ok. And you'll see here a quote of a customer who used Amplify, you know, prior to this set of launches. And they were very happy, uh, with the ability to really get up and running with an app back and quickly it pulled together all the different AWS services need needed. And uh the CEO and founder of this company was able to get their, this uh a bit agritech, agritech company was able to get their business up and running really fast as a result.

Ok. So with that very excited now to announce what's new. Uh and, and a lot of what's new is really focused again on enabling you to integrate some of the benefits that Amplify provides into existing organization into your existing organization.

Uh so the first thing we've done is if you've used Amplify in the past, the interface was a command line tool. Uh and we got feedback from customers that that's very good, but sometimes it's at odds with other, you know, other tooling that um folks might already have in the organization.

So we've kind of reimagined the experience where now you can author your back end, declare, you know, in very succinct code. Um and the code is, you know, can be TypeScript, it can be JavaScript, for example, it's very succinct and it lives in your source control repository along with all of the other code that you might have.

Um and we'll double click on, on this in just a minute and how it relates to things like CDK and CloudFormation that you might also be using as well. Uh the second thing we've done is this kind of abstraction for defining your app backend allows you to pull in existing identity systems and existing data resources.

And then finally, because you know, i'm i'm go, i'm jumping ahead a little bit but because all of this stuff is layered on CDK, you can add, you can basically pull in anything from AWS, all the 202 100 plus services. Sure, by the end of the week, it will be 300 plus. You can pull together all the services that AWS offers into this back end by using CDK. So it's meant to compose really nicely with the rest of AWS.

And then once you've done all of this because everything is in source control, everything is infrastructure as code, ultimately under the hood, it's really flexible in terms of how you roll out the production. You can do everything from developer sandboxes, uh all kinds of continuous integration trunk based, git flow, et cetera, you know, and you can uh deliver in all the ways you might want to deliver full st uh multi-account cross region. And we, we, we'll see some examples of that later.

So just double clicking a little bit more on what's new for app development. So first this kind of code first DX uh how many folks have used CDK or at least know what CDK is. Ok? A little bit more hands. Yeah

so cd k is, is, is a way of defining your infrastructure and it's layered on top of cloud formation, which is the kind of underlying underpinning for how you define infrastructure on aws and cd k has this concept of layers.

so what we've done in amplify is we've kind of rewritten a lot of our backend capabilities using cd kl three constructs, which are really succinct. so a lot of our own deep demo is gonna be like how you can build out this back end in very few lines of code because it uses these layer three layer three constructs.

um he's gonna do all of his demos using typescript. you don't have to use typescript. he's gonna do, he's gonna do typescript. and we've also done the work to integrate really tightly with code whisper. so from your id vs code or whatnot, you can actually just, you know, you can in comments for example, say what you want and it will spit out, it will actually spit out the code for you and, and help you get, get up and running even faster uh when it comes to integration, uh you can now bring in existing identity providers, things like octa if you're using that in your organization, uh as of right now or if not right now, a few minutes from now, you can also bring in existing databases, my sql and postgres sql databases.

and what's really neat is once you do that, that's not it. you can augment that. you can add business logic, you can add real time access, uh you can add access control, uh et cetera. and then finally, as i mentioned, because this is all cd k. at the end of the day, you can combine it really neatly with other cd k constructs that are produced, you know, from the community provided by aws to really integrate this, this app back end with everything that aws has to offer.

and then when it comes to post development to delivery, uh because again, everything is code first. uh you can uh you can use any, any kind of c i cd approach you like, i'm gonna walk you at the end of the talk through one that i recommend, but you don't have to follow that per se and you can come if you already have cd k or cloud formation investments, you can combine it with that as well.

and just as a brief aside, also when it comes to app delivery, we offer amplify, also offers a web hosting solution called amplify hosting uh we've launched a number of stuff and a number of things the last couple, couple of months or so to address the top feedback we've heard from enterprise customers. um you know, in particular wildcard subdomains can enable multi-tenant kind of architectures. and custom ssl is really important when it comes to integrating, hosting into existing organizations. you want to use certificates, you already have uh instead of being forced to use a new one and this one didn't quite make re invent, but it's, it's a matter, it's just a matter of weeks before that one launches. all right.

so with that, i'm gonna hand off to r and deep, who's gonna actually walk through a bunch of these features in action as he builds, builds an app. i'll be coming back on stage periodically to role play with him, but most of the, most of the next half an hour is gonna be r and d. thank you from the thicker. all right, thanks.

so, as more is talking about the develop and the delivery phases of an app building life cycle, we are specifically going to focus on the developed section of the app in the next upcoming slides, right?

i'm going to throw in a fun challenge as well. you all can count in how many times i say under 10 lines of code. ok. all right.

so imagine you're a part of a full stack development team at a fictitious health care company patent pending, of course, america. um and it's a health care provider company where you've got like the health care providers or doctors as well as patients. the patients will go ahead and request for an appointment through the apps life cycle.

now more and i are going to play the role of a front end developer. he's going to be focused on the front end client code and i'm going to be the back end for friend team that he just spoke about, right? like the bff pattern, we are responsible for modernizing the application that was built at medica.

um imagine that, you know, they had a legacy php application built on a lamp stack. how many of you have still dealing with those frameworks, right?

um funny story we're still living in the nineties.

um but i thought of including a screenshot of a legacy application, but i didn't want to compromise the slide deck look and feel you don't want to see that. uh anyways moving along, we received the designs from the ux team, but the app in itself has a dashboard where the patient or the employee can log in and they can book an appointment, right? it's going to capture the details of the user and it's gonna let you book an appointment based on the available times that a doctor is available, right?

and then in the end, if you want to extend the capabilities of your application, imagine adding the capability to have a virtual a i assistant that is going to front end your appointment booking process. so on the bottom portion of your screen, you have a section called virtual assistant. now, this is something we put together in the last minute over this weekend. so you can actually see that lam epsom, the default font that comes in with the designs are still there.

so um once we figure out the us designs from the us team, so we'll start with the app building process.

now, since we are a part of the front end team, the same back end can be used by both the web team who's, you know, mohit is one of the devs on the front and client code there and any mobile developer can also use the same back end, right?

so the same logic applies for both web and mobile applications in order to keep the stock simple and just focus on the simplicity of the architecture. we'll be using web as an example. ok? so none of what i'm saying is isn't true for a mobile application as well, it's true.

um so we'll take a look at the 30,000 ft overview about what are the tech players involved in the stack right now as mode mentioned, right? like we have l three based cd k constructs that are available. how many of you have heard about the layers and constructs for cd k? ok? that's just a few of them right?

so in a nutshell, i'll, i'll, i'll try to go ahead and explain this as to how i understood it in the start when i was, you know, reading from a solutions architect associate exam,

um cdk provides l one constructs which are the underlying cfn resources themselves, right? like you can use the cfn constructs and define any, any resources l two. on the other hand, is encapsulation of the cf and resources and associated services that are required to define this particular service.

like for example, if you're defining an intent based a p, then you're going to go ahead and define an l two construct which has the underlying cf and resources plus the required i am roles or required security groups that is needed in order to define them.

and l three construct focus specifically on a use case or a pattern. like if you want to define art in this particular case, amplify, provides an l three construct, right? if you want to define data, these are like use cases in your application, they are not like just generic resources that you deploy. ok.

so the odd layer enables users to create new accounts and sign in the data layer can have two phases. one is the existing health care employees and the ability for patients to book appointments with them. and the second phase is also pulling existing patient data and associate billing information to them, right?

and the last portion which we focus in today's app is extending conversational a i capabilities into your app. gen is the bus term in the industry right now. so we're going to see how we can incorporate that as well.

so let's dive into the 10,000 ft overview of the architecture. now, this light can look pretty complicated, but this is one of the patterns that our customers have been using today, right? thousands of our customers are deploying amplify using this architecture, but they've always been coming back with like, you know, i don't what's the easier way of like deploying this? and today, we make it simpler as we move towards this app of how we can deploy these different text tech layers of the stack using cdk. ok.

so i'll still go ahead and explain how the back end architecture would look like. so you would have like end users and employees within, within medic who would log into the web or mobile application.

the art functionality is powered by amazon cognito right now, cognito has the concept of user pools that is going to store the information of the end users directly. and it also has a native integration with an existing o ic or sample provider, right?

um so as more mentioned, you could have an existing integration with octa if a company uses octa for single sign on. but if you have any sam provider as well microsoft azure, then that integration is possible natively with amplify as well and the data layer are front ended through aws, appsync.

how many of you have heard a sync? quite a few of you? all right. so a sync is a managed serverless graphical service. it allows you to scale graphical workloads and aws right now in order to explain ab sync right, i'm going to split this down to three components.

now absent has graph k schema which defines how your data model looks like, right? like it's just like the blueprint of your data model. and then you've got the concept of resolver, which is the business logic of how to fetch the data. and then in the end, you've got the actual databases of data sources in itself where the where the data actually asides, right?

so all of these are the components of a sync. now what we do is we abstract all of that and i'm going to provide a single ab sync a p and point to mohit. so that on the client side, all he has to do is interact and query the data directly from the absent a p point. right?

now, you could also think that do i have to deploy the schema independently? do i have to deploy the dissolvers independently or do i have to deploy the data sources independently? and that's where the l three construct comes into picture, right? it makes it easy to deploy it in under 10 lines of code. ok.

now let's split this based on the ux designs for art. so in a typical art flow, you would have user name and password sign in and also forgot your password. no brainer, right. i've intentionally omitted a specific flow. any guesses as to what, what could be residing on the outflow reset password. i think we have the forgot your password, right. sign up. yes, thank you. right.

so then the sign up flow would typically have like a button on your website, right? creating your new account and the workflow for that would look something like this. you would enter your email address and you would have fields for your password and confirm password.

now again, this is the most simplest basic authentication set up that we did over the weekend. um but in a typical real world, modern application, it would have multiple other user attributes that you would collect. right? imagine you signing up for the re invent website, right?

and then for the employee login flow, there would be a button for the employees to be able to log in. and that would be a single sign on flow enabled through an o ic provider and the employees are going to enter their user name and password for once. and then based on the token management abilities, they'd be able to continue signing into the application. ok.

so in this particular flow, what happens is the application code grant is exchanged for a jwt token or a json web. token from the oid provider. and that jwt token is managed by amazon cognito, which then sends it back to the application. so that's how your o ic flow is going to function. ok.

so let's see how we can build this with cdk l three construct for art. um so all the flows that you saw earlier can be pushed through, amplify art l three cdk construct for end user as well as for employees. and you can easily build registration sign in and authorizing authorization tools for the end user.

and from an employee standpoint, you can build the o ic and sam flows and you can also use the ability of cognitive user groups to create a group called admin as well, right? like in a health care company, you've got the health care employees of the providers, but you also have admins who can manage the billing information and the patient information.

all right. so in order to accomplish that, we'll define the backend resources using the l three construct. in this particular code example, i've used typescript um in in going ahead and importing the amplify art construct. and i'm going to instantiate this amplify art construct name the user pool as medica art.

all that i have to do is set the email option to be true. so i mean, i'm providing an object called log in with and email is true and that is going to set up the user pool for the end users, right?

and in order to set up the back end for the o ic flow, i just have to pass in the parameters for the client id, client secret and issue your l and that enables both the flows for the back end. right?

again, all of this in under 10 lines of code in the cdk stack file. once i hit cdk, deploy, it's going to deploy the necessary resources for cognito and then that's it. all right.

i'm gonna invite mohit up here to talk about how easy it has been for him to integrate that on the client side. thanks. thanks arun.

ok, thanks. thanks arun. uh so before i do that, just a quick aside, you know, uh another aspect of amplifier besides these l three constructs for contributing, the back end is a rich set of client libraries and the client libraries uh reduce the amount of code that me as a front end developer have to, to write, to implement off flows which you'll see here as well as data flows like that real time, that real time news feed scenario we talked about earlier, which you might want for real time updates to data or even in, in um generative a i kind of flows if you want to chat experience on top of generative a i

So with that said, when it came to doing the employee log in, first I, I kind of had two choices and I'll kind of explain the pros and cons of the two choices.

Uh, the first choice is the one that Arun Deep spoke about is, is arguably the simpler approach. So I just configure, if you, as you see here, some redirect URLs and the Cognito service, the Cognito user pool service handles all of the token, the token management. And let's say I'm using Okta, it handles all of the handshake with Okta. So me as a client developer, I'm based, I'm aside from, aside from just configuring the redirect, I'm basically hands off when it comes to the interaction with Okta. All of that is handled between Okta uh and, and the uh the service.

So this has the nice benefit of being really easy. Token management is handled for me and user experience is, you know, is, is it, they don't even know that Cognito is necessarily there under the hood. It's really, really smooth, you know, alternatively I could take a different approach, you know, let's say I've been using Okta again as my identity provider and I'm using the Okta SDK. I'm using the Okta SDK because I want to take advantage of uh you know, uh of something on the client using the JWT token. I get back from Okta. I can certainly do that as well. And that's what this flow is doing again. In, in, um, you know, tenish can, I don't know if it's exactly 10 but tenish 10, tenish lines of code I can use Okta SDK as I otherwise wouldn't, all I have to do is kind of bootstrap Amplify if you will by passing the token that I get from Okta. And I can use that to now have my app access AWS resources on behalf of that Okta Okta user and I can continue using the Okta SDK, both approaches completely valid. You know, it just depends on your use case. Um and the needs of your app developer uh for the patient login, right, the patient login in theory is more complicated because I don't have something like Okta to fall back on. I need to actually implement sign up and sign and flows and manage that myself in my application.

So that in theory could be thousands of lines of code. Like if you start thinking about all the user interface to do an offload properly, the crazy state machine, you might have to deal with the different multi factor off flows. So the ones that you first do when you sign up and then subsequently when you sign in that can be thousands of lines of code. And we've really tried to abstract that on the client and Amplify. So you can build the entire authentication flow in minutes and it it is layered.

Uh, I've showed you the right. What I'm showing you here is the highest layer of the stack. It's called the Amplify Authenticator. And that actually gives you a full out of box built in UI. Uh, so you can see here in just a few lines of code, I've configured, configured, my client login, login flow and it automatically works with whatever settings are configured on that CDK construct and it's completely them and fallible. So you can use it to match. In this case, Medic's design guidelines that said if you want more controlled, you can always go one level under the hood, which I haven't shown here and implement your own own UI as well. All right, back to you.

So let's take a look at um the data layer of the app. Now, um at a minimum, we are going to have an appointment booking form where users can come in and book their appointments with name description and as well as the provider information, an optional date picker component to choose a date, right? And the information of the doctors can be stored in a new DynamoDB database that we are going to create and we are also going to associate bills of the patient.

Um and this existing billing data can reside on a MySQL database, right? Um so let's simplify the architecture, right? What we spoke about was appointment and healthcare data residing on Dynamo and the patient and billing data um residing in an existing MySQL database. And both of this is going to be deployed um and integrated with um through AWS um AppSync, GraphQL three construct. Now, this is going to be released today. We just approved the PRs in the morning so you can do an impress your friend kind of a thing at the hallway that you were the first ones to receive this information.

Ok. Um so the first step for that is to define your appointment, schema and API right now with GraphQL, you have to define your schema. And the scheme for the service provider has a unique ID and it's got the name specialty, whether they are a cardiologist, whether they are a dentist, what not. And then it's got a relationship with the appointment right now. Typically, one service provider can have multiple appointments. And in order to define that relationship, we use the has many directive as you can see on the screen and on the appointment side, right? It's got again, a unique ID field. It's got a description field, um a time field and the relationship back to the service provider.

Now, the same appointment can also have relationship with like patient ID and bills as well. Right now, we have not spoken about the patient ID and bills in this particular schema just yet because we have minimized this to show the relationships. But those are existing on an, on a MySQL database in your organization, right. So we're going to show in the next step as to how we can integrate that. Ok. All right. And on the main CDK stack file, you're going to go ahead and use this construct again, starting 11am you'll be able to use this live in action and you can instantiate the construct using the name of the API, right? And then you can go ahead and specify different authorization modes. For simplicity, we have used the API key, but the construct supports all authorization modes that is supported by AWS AppSync. You can do IAM, you can do Cognito user pools or you can even have your own custom authorization using Lambda. Ok?

So this is again the deployment of the appointment schema API in under 10 lines right now. Because the patient and billing schema already existed on an existing MySQL database. You can use any SQL explorer, right? How many of you use MySQL in the past? What, what tools would you use to connect to MySQL? Wordbench? Cool Wordbench is the screenshot there. That's the same thing that I used. Um you can output the schema into a CSV file and Amplify provides easy succinct command to be able to take in the CSV file and generate a schema.graphql file, right? Because you have a relational database and you would want the schema to go ahead and interpret that as GraphQL schema, right?

So the output of that is going to look something like this. This is automatically being generated by the command I did not have to write the schema myself, right? No, the type billing refers to the billing table in your database and you have different authorization rules here. I'm using Cognito user groups to say that only the admins can have CRUD operations because you don't want the patient themselves to be able to add or delete bills on their behalf. Right? You want the admin to be able to control that. But as the owner of the record, like, you know, if I'm a patient or if I have a bill associated to me, I should be able to see the record, right?

So allow the owner of billing data to be able to read and only the admins can perform CRUD operations and the same thing for patient as well. Now you've seen that like the patient has fields for first name, last name and address. And again, in a typical real world healthcare company, there will be much more attributes that define the patient, much more attributes that define the appointment as well. Ok?

And we are going to use the same construct that we spoke about earlier. And though the construct was released back in October today, we are adding the SQL support. So this should work. Um and you can take the SQL GraphQL file and you can specify the DB connection parameters. So where your database resides. So for example, if you have your MySQL database in RDS behind the VPC as well. You can specify the connection parameters and you can use the authorization modes of modes of user pool, right?

Ok. So now that we have defined like both the APIs um initially what I said was Mohit will be able to query the client or query from the client using a single API, right? And because we have two different GraphQL APIs that defeats the purpose, so you have appointment and healthcare employee data being managed by Team A and the patient and billing data managed by Team B. You have GraphQL APIs for both of them and AppSync. Now offers merged APIs, right. Would that enable like federated cross team API development? This means that APIs owned and managed by independent teams can be merged and combined into a single API and the schema of the individual source APIs is also going to be merged. So are the types and the resolver in the backend as well. Right now, what this enables the frontend devs to be able to do is they can query that data from a single endpoint. And on the backend, both Team A and Team B can release changes independently without blocking on changes on the merged API, right.

Right. And here's the customer code from ADP, ADP is Automatic Data Processing and that provides human capital management as well as enterprise payroll services. Um they've used AppSync to bring data from various backends and sources into a single endpoint, right?

So now that we have initialized our data in our application, let's focus on extending the capabilities of app, right? Like, so now how many of us are comfortable with using chat based assistance to book an application? Just a few? All right, cool. So imagine, you know, you don't want to pick up your phone each time or like go to the website because you may be driving or you may be, you know, um in different setups. So if you, if your appointment booking app, want a mechanism to identify the service provider automatically based on their preferences and needs and go ahead and provide a recommendation. How cool would that be? Right? And, and these are the things that Amplify allows you to provision using CDK where you can connect to any AWS service, right? In order to get the functionality.

So let's again, take a look at the UI designs. So, you know, every industry is actually experiencing this monumental shift in technology. They're trying to make it more simpler to use AI and NLP. And now more commonly generative AI here imagine that there is a chat bot called Me AI chatbot that automatically figures out the preferences of the patients and makes a recommendation of an appointment, right? And the user, on the other hand, all that they have to do is to accept or deny the recommendation ok. So this enables personalization capabilities, right?

So the service that can be leveraged in order to do that is Amazon Bedrock. How many of you have heard of Bedrock? Right. So Amazon Bedrock was launched earlier this year. It provides the easiest way to build generative AI applications on AWS. Uh it front ends a lot, a lot of the large language models or which we call as foundational models offered by Meta Anthropic Stability AI and Amazon itself, right?

So we are going to grab the user preferences from the employee. We are also going to associate that with service providers metadata and then we'll provide the recommendations back to the users, right?

So a quick look at the architecture again. Um the integration between Bedrock can again be abstracted and set up behind AppSync. So you don't have to worry about setting each one of them up individually. AppSync can use a HTTP based resolver because Bedrock can be defined using HTTP endpoint, you can just call the invoke the HTTP endpoint and the model behind them. And you should be able to communicate with Bedrock from the client side, right?

And here's the code, right? This is the only code that is not under 10 lines at least, but you can add Amazon Bedrock as an HTTP source and provide the permissions to invoke the underlying model. In this example, we have, we have used Anthropic Cloud model and then we're going to add a resolver and we're going to use a file called generateRecommendations.js. And in that file, we'll say that you know, the prompt for the model is going to look something like this, right? Imagine that you are a healthcare AI assistant responsible for booking appointments and you need to respond back to the user with the available time slots, right? And that could be the prompt that is in the recommendations.js file and that will be taken as a code asset and it will be attached to Bedrock as an AppSync query.

Now, there is a QR code as well on the slide, one of our developer advocates, Michael created a spicy chicken taco recipe app using the same pattern, right? It's not Tuesday. I know that we can all wait for Taco Tuesday tomorrow. But um you can scan the QR code to check out the GitHub repo for the code as well and that's, that's fully functional.

Now, there's a second pattern to have AppSync as a connector to generative AI. We talked about the HTTP based um resolver, but you could also have a Lambda resolver that connects to Bedrock and there is a blog post that we wrote recently in order to show you how we can use this particular pattern. So if you scan the QR code, it will, it will link you directly to the blog post right?

Here's a demo just to prove that whatever I've been talking about. Medica is not untrue. You know, there is a demo here. You can scan the QR code, it's a live website. There is a username and password that's defined on the website which expires after 24 hours just to protect the website from multiple requests, so you can try it out over coffee. But um Dan, one of my colleagues, um and I, we built this over the weekend and uh funny story, right? I have a um demo coming up for it. Uh initially we were told no demo but you know yolo, right? Um we just went and created this. Um and um it is actually funny that we took a lot of time to edit this video than the time it took to spin up the code and use Amplify CDK construct, right? I let, let it up to the user's imagination to figure out what's true in that

Hello, today, I'll be demonstrating an application that can be created with CDK, AWS Amplify, and using AppSync's merged API feature while maintaining relationships across the API sources.

The experience that I'll be showing today is one of two experiences:

1. Users who can go in, request appointments, and view a history of the appointments

2. Providers who can go in and manage and view appointments that have been created by other users

So here's a sample app that we currently have right now. With the patient login, I can go to that page and as a patient, I can enter my credentials and click log in. When I'm logged in, it will show me the list of appointments that I currently have historically and in the future, as you can see, I have two appointments coming up, one with Dr. Pepper and one with Doctor Strange, coming up next year while also showing the billing amount for each of these appointments.

The key thing to note here is there are four separate data sources that are all being used by the merged API feature to put this data together:

• A providers data source
• A users data source
• A billing data source
• An appointments data source

So the merged API feature maintains relationships across all of these different four data sources, exposing them through one endpoint.

In addition to viewing my appointments, I can also come in and set up an appointment here. As you can see, I can select the list of providers that are being exposed by the data source. So I'll say I want to see Doctor Strange and let me set this for March 13th of next year. Once I do that, I'll hit book and once that's successful, it will add it to the list of appointments that I currently have. You can see this is the one from Mars that I just created. It's also up to some backend magic. It's also kind of given me my billing amount.

Next, I'll be showing the provider view. So here using Octa, for example, as your OIDC provider, I can click on the provider login link and with the use of AWS Amplify, it already knows that I have an Octa session on this browser. So it automatically signs me in and beyond seeing the previous user's appointments, I can see an extra one here. So in total, we currently only have four appointments. Doctor Strange seems pretty popular.

And as a provider or as an admin, I can view all of the different appointments.

Alright. So it's as easy as that. Doctor Strange seems pretty popular. But you know, essentially we have built this app out and you can use the QR code to actually test the website out live as well.

I'm gonna hand off to Mohit to talk about the deploy portion.

Alright, thank you Aaron.

Coming back now to the underlying tenet behind everything we've been showing you today is this kind of code first approach and that the benefits of that extend beyond development to delivery as well. And here's a couple of patterns that are possible because of the code first approach:

1. It's possible for each developer to have their own developer sandbox and we'll see exactly how that works with a short demo actually in a minute. But basically each developer can take the code that defines this backend for frontend layer, they can work on it, they can round trip it to the cloud, interact with it even before you start CI/CD.

2. Once you enter CI/CD, again code first allows you to use mix and match your preferred CI. I think the two common ones are GitHub Flow or Trunk Based. Folks would argue they're actually not that different if you kind of dive into it. But the point is code first allows you flexibility on CI.

3. And then finally, for especially more sophisticated deployments, you can do truly full stack deployments, front end and back end together. And you can do multi-stage and cross region as well and we'll see a pattern around that.

So let's start with what exactly do we mean by per developer sandboxes?

Here you see an example where I have three folks on my team. My eyes are not good enough to see who I had picked, but these are actually people on my team, three folks on my team. And right, I have a setup here where the developers working on the front end are also the developers working on this backend for frontend layer.

And the key thing here is whenever they hit save in their IDE a couple things happen:

• Their local browser will refresh
• In addition, if they made any changes to the backend, the CDK constructs will automatically get deployed in the backend, bypassing CloudFormation and just automatically getting deployed really quickly in 10 seconds or less.

What this allows is for all of these folks to work on the backend for frontend layer together independently prior to their code changes entering CI/CD at all in the first place.

So to see this in action, here's a short video. Let me hit play.

Okay, so I've taken that schema that Arundip created and I don't like "name" - instead of name, I want first name and last name. So I'm gonna go ahead and make the change.

You'll see here, I'm going from name to first name and last name and I hit save. Right when I hit save, we're using a capability of CDK called CDK Hotswap which you invoke with "cdk watch".

And in about 10-ish seconds, you'll see that these changes actually round trip to the cloud. So in this case, they round trip to AppSync, they're gonna round trip to DynamoDB.

And now if I flip to AppSync and look at the query explorer in AppSync, indeed I can see that instead of name, I now have first name and last name available.

So what this allows developers to do is kind of get the best of both worlds. In the past we've had things like simulators and mocks which can be fast, but developers say that's not really high fidelity, it's nice but not high fidelity.

So this gives developers a truly high fidelity cloud environment, but with nearly the speed of local development. In 10 seconds you saw we're able to round trip and see the impact.

Once you get past sandboxes, you can implement the CI of your choice. The kind of traditional CI where everybody has access to the main branch is certainly possible. And that, the most recent check-in to the main branch represents the code that's deployed to production.

You can also for sure implement branches like you would have in GitFlow. So if you take one of those developers on the previous slide, now they're happy with their first name, last name change. They can check that into source control into their feature branch, in this case I've called it "developer-a".

They can submit a PR, when they submit that PR to the main branch, that first name last name change is now applied to the main branch and can get rolled out to production.

Alternatively you could have a deployment that aligns with the developer-a branch as well, like a test deployment.

Now going past CI to CD, a pattern we often see with customers is full stack CI/CD.

So what you have on this slide, the first part is exactly what I showed - it's basically a flow, a workflow, where the backend gets deployed. But to make sure that the backend and frontend stay in sync, after the backend is deployed on the lower half of the slide, you'll see that the frontend build gets kicked off.

So the frontend build gets kicked off, a frontend test phase happens, and only if the frontend test succeeds does the entire thing, does the entire thing then get deployed. If there's any failure you can have a rollback.

And this is a really nice pattern where for scenarios where you might have a frontend and backend for frontend team that are the same team, this can really streamline the continuous deployment of both aspects together while ensuring that there's no drift between the two.

Getting a little bit more sophisticated from that, the code first approach allows you to grow up to something like this.

So what you see on the left hand side now is not just a single stage but multiple stages. And what you have here with these multi-stages is an initial build, an initial build, but then after you have that initial build, a rollout to different phases.

So here I've, I think I've chosen three phases, but they're all the phases except the last phase are basically prep prod integration sort of phases. And then the last phase is, is the last phase or stage is prod.

So on the left, basically by using that same app code you can run it over and over again in different stages to a different effect. You know you can either support your prep prod or your prod deployment.

On the right hand side, you see that the flexibility itself allows is multi-fold.

First you can have different stages output to different accounts because you may not want your frontend developer or your BFF developer to have access to prod. So here you can allow, you can implement different accounts again using the same exact CDK stack Arundip built just by changing configuration parameters.

You can roll out to different accounts. And likewise by changing configuration parameters you can roll out to multiple regions as well. So if you see the last phase here, not only is the last phase doing multiple deployments, it's doing deployments to different regions to enable a multi-regional architecture.

Now, being fully transparent, this gets you like 80-90% there. Obviously a multi-regional architecture is more than just deploying the same stack in a lot of different regions. There is some work you have to do to make sure the regions can work together as needed.

For example, you might want DynamoDB global tables so the underlying data is replicated across regions. So this gets you 80-90% there. For the last 20% we have a QR code here, we've written a blog post which shows how you can take the stuff we've talked about today, make the incremental changes like turning on DynamoDB global tables to end up with a truly multi-regional architecture.

Alright, so with that we're coming to an end. I just want to recap what we've talked about today:

• We talked about Amplify and in particular some of the new stuff we've done in Amplify over the last few months to really make it easy to fit Amplify into your organizations
• We've really leaned in on this code first approach available via CDK constructs
• We've made it easy to integrate with existing identity and databases, made it easy to extend and use any AWS service via CDK
• And then by kind of doubling down on code first, which under the hood is infrastructure as code, you have complete flexibility when it comes to CI/CD as well as creating developer sandboxes prior to your CI/CD

So with that, I want to extend a big thank you to the audience. Again I know it's not easy to come out at 8:30am on Monday, first day of re:Invent. So big thank you for being here, hanging around.

Our contact information is here, we're active on all of these channels, so absolutely feel free to reach out if you have any questions.

We have a frontend web and mobile blog as well, which has all of our latest announcements. You can go there for tips on how to get started.

But with that, yeah I want to extend a big thank you!