Erik Hanchett 0:09
Erik Hanchett 7:46
Alright, so let’s assume in our back end, we have a database. And in this database, we have this type customer, we have ID number, we have this full name, string, and we have email. And this is the, what we can assume maybe customer is that is a table and Id full name and email are our fields in it. Alright, so this little graphic is describing how we might like something like this might happen. At the bottom, we have this a weight fetch, where we’re fetching some data from the front end, and then the back end is going to send this this, this customer data back in this format that we will meet will know about this ID full name and email. But what problem does this kind of end end type safety solve? So let’s look back at the same example. Again, I had to add it in twice, because I just liked the animation. But we’re sending this over. And let’s assume that the front end knows what types the back end is going to send, and that we create our own type or interface and that we can then use that. But I think what happens typically, and I’ve been in a lot of software teams is that the backend contract for the API’s that they’re creating, are never finalized. And they’re continuously changing, especially during the process before it gets into production. And so the front end often doesn’t know exactly what the back end has done. And I’ve been on teams, where the backend engineer change this fields, and I have no idea about it. And the next time I try to test my app, it breaks. And there’s ways of getting around that there’s things like swagger files, there’s code Gen tools that can automatically take your back end endpoints and generate TypeScript from them that you can use in the front end. But I think there’s a better way. So let’s say our back end engineer, he’s like, Okay, I have this customer table. But really, we need to break it down, not just for full name, we need a first name, a last name and a middle name. All three of these here. So we’re going to remove that full name. And we’re going to add this first name, last name, middle name. And we’ll we’ll make that change. All right. So the backend engineers like okay, I made these changes the front ends like, okay, next time I’m making the making a call to the backend, I’m doing my normal fetch, I have this type that I already created. But oh, I’m receiving this new customer object that I don’t recognize. And this is a problem. As you can see from here, now, if I’m in the front end, and I’m running like my customer dot full name from this JSON payload that came back, I’m getting there. Like his full name doesn’t exist anymore. Obviously, things have changed. And so we need to kind of think of like, how is one way to fix this? So what can you do? And I’ve had that expression on my face before, like, Ah, what’s happening? Alright, so here are some in our heroes, our tooling that can help us with this problem. And so there is a whole bunch of them out there. Some are better than others, but ones that I like our AWS amplify, I really like trpc. I’ve used frameworks like nest J S, as well, which has this really tight integration from the back end, especially of using like Angular to the front end, where you can easily share types between them. There’s also like Knucks, J. S, which is has this other library built in called on J S, that can do type safety. So that way, it’ll automatically detect if you create an API route. The front end, if you do a use Fetch back over to the back end to that API route, it’ll automatically detect the types for you. So there’s a lot of different ways of handling this. But I think the one we’re going to talk about today, we’ll we’ll talk about two of them is AWS amplify and the trpc. And I think those are the ones. I’ll show you some code examples and how that’s done. All right. So I’m a little biased is why AWS amplify because I work as a developer advocate for them. And when a common question that I get is, what is even this AWS amplify thing people hear AWS and they always think, Oh, we’re talking about DevOps, we might be talking about, like serverless functions, Dynamo DB. And, and, frankly, hard to read documentation at times. But really, AWS has a lot of services. And the one that I’m really excited about, and we’ve had for a little while is this AWS amplify and what our goal is, is to help front end developers create full stack web sites using AWS. And this also includes mobile developers as well. So we have tools to help you build and host your front end, we have managed services that do that we have managed back end services, we help you connect to authen. Storage, we’ll have real time updates, everything like that. And that’s a little bit about what we what we do. So you don’t have to be a DevOps expert or a infrastructures code expert, we want to make the tools, very straightforward to use for anyone to create apps with. And one thing we were really excited about that goes to the heart of this problem in this presentation is that we found that developers really like TypeScript. And they really want a type script or type first experience when creating their infrastructure, but also when they’re dealing with their back end. And when they’re trying to add information from the backend to the front end. And that is where the genesis of AWS amplify gen two came out of. And right now it’s in developer preview. We just released it in December, and in November. So there’s three tenants of this. First is we have this code first developer experience, which really is making sure that everything we do is in code, we’re not using like graphical GUI interfaces, or CLI, we really want to focus on the code first experience. And I’ll explain more. And what that looks like in a moment. We thought we’d seen that developers really love git workflows, they like being able to have their main and their development environment and our QA environments, and those are automatically connected to different back ends. And having that connection has been really important. And then really, we love faster local development. So when you’re using AWS tooling, if you’ve ever done it before, and you have all these things in the back end, it’s kind of hard to test against it. And we wanted to make sure that was much easier for any developer to test. So let me talk about that code first dx. So right, so we our ideas were write TypeScript across the front end and back end, get schema validation dot completion and end to end Types while you code. Some, we’ll talk a little bit more about what all those things are. But you can imagine that TypeScript is kind of our main focus with this update to make it easier for developers to do some things that we just showed you guys about but and then type safety. All right, so I’m gonna imagine a back end here. Now, you don’t have to use every one of these services. But since this example, kind of works itself better with these with these, we’re gonna use AWS app sync, which is our managed GraphQL service, we’re gonna use DynamoDB, which is kind of like a no SQL type database. And then we’re gonna use Cognito, which is an identity provider, that allows you to store user information. And by the way, all these are on demand services, you only get charged when you use them. And they have hefty free tiers, as well, if anybody’s looking at this presentation later on and want to try some of these things that we’re doing here on your own, there is a very, very healthy, free tier and also like Cognito, I think it’s up to 10,000 monthly active users, for free. Alright, real quick on a definition AWS app sync, I kind of glossed over that quickly. But AWS, app sync connects apps to data, and events with secure serverless and performant, Graph QL and Pub Sub API’s. So we saw the ecosystem of how people use Graph QL, which by the way, is one particular way you can solve this problem with end to end type safety. But if you look out there, usually the way Graph QL solves it doesn’t integrate in TypeScript and the types as tightly as that is what we’ve developed here. So it was app Sync has been used by lots of different customers, enterprise customers, and it’s pretty popular service that we have. All right, I have some code here. And so I’m going to highlight. So this is we’ll imagine this is us, creating the code that we need for our infrastructure and for our data modeling. And I’ll explain what that means. So first, this customer here, a dot model, you can with this new gen two, this will create a new customer, basically a customer table using App sync. And it will create this model with this full name and email. And what’s really nice about this dot model is it’ll create all if you’re familiar with GraphQL, there’s something called resolvers and resolvers. help connect your queries to your back end data sources. So this dot model will create all the queries for you to create, read, update, and delete all the CRUD operations. And it’ll create basically a table in DynamoDB, which has the full name and email.
Erik Hanchett 17:40
Erik Hanchett 27:21
So thank you very much. I think that was a lot of information to cover. A one question one thing before I get back to Brian here in a second. Is that one, one question, I have people saying, when should you use AWS amplify kind of this new gen two that I just showed versus when you would use trpc? I think gen two is completely bigger product where it’s creating the infrastructure for you. It’s also allowing you to have that end to end type safety. It has a few different paradigms, where the tRPC is a little bit more lower level for specific situations where you might want to share information between the back and the front end. Alright, so I think that’s that’s all I have. I think I’m done a few minutes early. But I’m looking forward to some questions.
Brian Rinaldi 28:09
More or less on time. So awesome. wery good presentation. Erik. I really, you know, I haven’t checked out trpc And Slee is clearly been a while since I’ve messed with amplify. So I do. I you know, if anybody’s in the audience that has questions, please post them in the chat or use the Ask him question module. And I’ll get to them with Eric, because we have some time here for some questions. But I do I am curious about this Gentoo of amplify because I think it’s been a while since I checked out amplify and I it’s interesting that you say like the code first kind of workflow and I because I kind of remember amplify having lots of like little drag and drop type type things. Am I Am I wrong? Am I misremembering? And can you tell us a little bit about what some of the changes between gen two and Gen. And the prior gen
Erik Hanchett 28:57
Brian Rinaldi 31:30
Cool. Yeah, um, I definitely want to check it out. Because, you know, I do a lot of various things with AWS. And I mean, they, I think, I don’t know what you’re up to, like 1 billion different services. Up through the list, it’s pretty long. But you know, and, and a lot of them are like, incredibly powerful, but can be tough to like, kind of get, especially if you’re more of like a front end developer, like wrap your head around how you orchestrate all those different pieces together. And it’s really interesting to see like, just how you just defining them in code here. And then getting that back end piece, like, you know, I’ve set up Dynamo DB and stuff like that. But like, you know, this, obviously, it’s just that we look like pretty much just a few lines of code. And you’re getting the Graph QL API plus the Dynamo DB back end for it and everything. In my understanding, saying that correct?
Erik Hanchett 32:26
Exactly, yeah, just with a few lines of code. And we really took inspiration to from like, amazing other tools like SST, and other CloudFormation and, and CDK. So you can also for those who know, cloud development kit is a tooling to create infrastructures code, so we can drop down to the CDK level, if you are really into that. So if if you have a unique use case where you need to jump into other other things that we don’t support yet, you can go down to the CDK layer. And so that’s that that works as well.
Brian Rinaldi 33:02
Okay. Yeah, I’ve done some CDK stuff myself, as well. So that that’s good to know. So. So it gets kind of back to even a little bit of what Matt talked in the first talk simple by default, but you can get in and configure the things you need to if you need to. Yeah. Yeah. So you said you support static site generators? nuxt. And next, are those like, are there is there plans for any additional support for other frameworks or anything like that? Yeah.
Erik Hanchett 33:34
So with we have amplify hosting, which is kind of a hosting, it’s, it’s a hosting provider. It’s a managed hosting provider. And kind of our main use cases are like next apps next 13, and 14 with the app router, or pages router, if you’re familiar with that. But we’ve always supported like static site generated apps. So any static site generated tool that generates static sites will support Astra or whatever. If you want to do something like server side rendering, you have adapters right now for next. And we have adapter for nuxt. And we have we’re looking at some other adapters for Astro that the community have created and some other tooling. So we we were definitely we have basically a diagram or a set of rules that anyone can create adapters for our hosting service. So anybody if you have a specific framework, and you want it to be server side rendered on our service, you can either you you can create your own or the community has been really stepping up creating adapters all the time for it, so we’re supporting more and more frameworks on on there. And then it’s also you can even drop down to like I’ve seen people create Express apps on our hosting service. There it’s pretty powerful.
Brian Rinaldi 34:57
Nice, yeah, I that’s that’s really cool. I mean, You know, ultimately, a lot of these things end up using AWS. Anyway, regardless of which platform you’re using, like I know, you know, like a lot of the serverless. The SSR is done via, like, lambdas and stuff running somewhere. So, you know, it’s kind of makes sense that you can obviously be able to do that within the database infrastructure yourself. So. Okay, so, so tell me, tell me a little bit more. I’m trying to like, the trpc thing. It’s you the examples you showed were like, regular, you know, like, straight trpc. You said, you can integrate it with with the next router, so you don’t have to spin up your HTTP server. Exactly. Yep. Yeah. Is this like something built in like the there’s like an adapter for that to work with next? Or how does that work? So
Erik Hanchett 35:52
if you go directly to the trpc website, and by the way, those guys are awesome, they’ve made some incredible. That’s pretty fun, open source tooling framework. I do actually have an example right on the front page, you can load up a stack Blitz, and it’ll show you how you set it up with next 13. Or actually, next 14 in this case. So it’s similar to that, I believe, yeah, it’s it. You pass in, like the app router, as like, you export it out. And then you can import it in directly in and then you can use it. So yeah, you it really lends itself best to, I want to say like next, I think that the creators really like it. That’s where the idea of the T three stack came from, where you have T RPC, you have next using tailwind. And there’s another T I’m forgetting someone in the chat may probably know, but so they’ve created like a whole stack where you can just download all the boilerplate code and get started with trpc. And tailwind, and next and create a full stack app. So that’s really interesting, too. Yeah. So yeah, they it’s pretty powerful.
Brian Rinaldi 37:03
So so then I basically use trpc. In my, like API routes, like, is essentially what? Okay, and then okay, that’s really cool. You know, I saw somebody comment earlier that they, they’ve been hesitant, and I kind of said the same thing about TypeScript and type safety. But, you know, I think it’s definitely something especially as you build a team, and you’re trying to, like, ensure that different different teams who are doing different pieces of work are able to work together. You know, it’s, it’s super important.
Erik Hanchett 37:39
Yeah, I mean, there’s definitely, I still see some hesitancy in some teams and moving to TypeScript in general. And it just depends, like where your code bases, how much of effort is to move it over to TypeScript, you could always do it incrementally in that way, and that also depends on what your front end and back end stack is, obviously, if you’re using dotnet, or Java back end, I mean, that’s not gonna work. But they already have their type type safety, and then maybe use some other paradigm when you’re sharing types and and API contracts between the front end back end. And there’s other tooling to do that. But I think, like when I, when I worked on a team here at AWS, we were creating an open source project. And we were creating some more extra tooling for AWS amplify, and the first thing we did was, we said, we added es Lint rules in there. We added in TypeScript, we had some very, we had debates on what TypeScript rules, we want it on and off. And it made the development that much quicker throughout the whole process. Yeah, I would
Brian Rinaldi 38:44
agree. I remember, you know, I oftentimes in my role, like being a developer advocate, you know, like it a lot of it’s very solo work, you know, so, so even adding TypeScript in sometimes it’s like, well, that’s overkill for what I’m doing. But But, but I remember, like, even when I was working at a different company, we had like, shared es Lint rules that made my life much easier, much easier, because I could write code the way I wanted, and then like, okay, I’d save and it just it, change it to how they expected the code to be to be done. And just, I think those kinds of things for a team are extremely important. So yeah, good, good practices to follow. Okay, so and you, you only got a few minutes left, you said that the Gentoo of amplify is in developer preview. So like I can get that like just by going to the amplify site or is there some special way I have to access the preview?
Erik Hanchett 39:39
No, you can find all the documentations in Docs dot amplify dot AWS, there’s a big banner at the top to try out or Gentoo it like you said it’s in developer preview. So we’re looking for feedback from it. It’s gonna go for what we call general availability later this year. So we really looking for people to test it out. Give us feedback on GitHub issues, all these things are open source, like almost everything we have. There’s some closed source course. But then a lot of our library stuff are open source, you can create tic issues against it, you can message me directly at Eric ch. And I will get it to the product teams. Yeah, so we’re definitely looking for feedback. And we’re adding more features. So that way, we have a complete solution. So if you are coming from studio, or that CLI tool I was talking to you guys about earlier that you don’t feel like you’re missing anything. So we right now, we don’t have migration guides for that. So it would be difficult. But when we go into general availability, we’ll have the migration guides will have more features. So it’s completely feature complete between kind of the old way and the new way. And the old, the studio and the CLI arcs are still going to be there, they’re not going away. But this will be kind of a newer way of handling it in the future. Okay,
Brian Rinaldi 40:53
so but you can combine like the studio and, and the new way or studio, you’re just doing gen one.
Erik Hanchett 41:00
Yeah. So if you’re doing Yeah, you don’t want to mix them right now, you would only you’d want to do one or the other. So this is this is really, when I when we talked about preview, these are people like wanting to kind of test it out, try it out, give us feedback. You probably don’t want to use it in production because it doesn’t have all the features but this is that’s why it’s a preview.
Brian Rinaldi 41:22
Okay, sounds great. Well, hopefully folks will check it out. I definitely want to check it out. I you know, I’ve always I’ve like watched amplifier for a while and toyed with it but I’ve really been curious, especially because as I’ve gotten to do a lot more of my own AWS pieces myself, like having something like that to make it a little bit easier for somebody like me that orchestrate those pieces because, like I’ve done Cognito for instance, but like manually doing Cognito Exactly. No, it was not fun. So, so yeah, this this sounds great.