Erik Hanchett 0:09
Yeah, so Thanks, Brian. I’m really excited today to talk to you guys about end to end type safety a guide for front end devs. And we’re gonna deep dive into this topic. Like Brian said, my name is Erik, I’m not gonna put my my ex handle or Twitter handle. But if you need to get a hold me, I’m at Erik ch. So what is type safety, I don’t have my channel for any. But if you guys know what type safety is, you know, in your chat, if you’re listening along or just at home, raise your hand. Let me know if you know what it is, I think I think many of you do. But let’s let’s take a look at it. So type safety, there’s a lot of different definitions out there. But I kind of like this one. It’s the ability of a programming language to vent type errors, errors during compilation. So there are different types of programming languages out there. For example, C sharp and Java are like strongly typed languages. While we have more dynamic type languages like JavaScript, where you don’t necessarily have types, where in Java, you might have an int, or you might have a string. And in constants, and in JavaScript, you just might have constant var, which deals more with the how, what the scope of that variable is. But there is ways of to add type safety to JavaScript, and we’ll talk about that in a second. And you often will see terms like a statically typed language, and that’s one that usually has type safety in it. So let’s take a very straightforward, simple example here. So let’s say we have JavaScript, and we have this const A, and we have the string two, and then we have a constant b, which is the number two, and then you do the sum on it, and you get 22 back. And if this doesn’t really make a whole lot of sense, but what’s happening in the background is JavaScript is doing this type coercion, and it’s basically taking two and it’s turning it into a string. And it’s concatenating it together with the other two, and you get 22. And that’s obviously not what we want. So the string 22 Verse doesn’t equal 22. So this is not the same, it’s also two plus two we know is four. So this is not right. So this is kind of what I look like, I use AI to generate all these images in this presentation today. But this is, this is definitely what I feel like when I miss a simple mistake like this. And I don’t know, I’ve done things like this where I’ve thought it was a string and or I thought it was a number and it’s actually a string. And things just don’t behave the correct way. It’s kind of a common mistake, especially with beginners in JavaScript, where they, they make they don’t have the correct types and or they don’t have any types, of course. But let’s assume that we could set the sum as a type number. So if we look kind of down here, we have this some colon number, and we’re going to use something called TypeScript. I’ll talk about that in a second. And now if we try this a plus b, in our, in our typesafe, TypeScript console app here, we’ll get this nice, big error. That type string is not assignable to type number. And this is golden. And since TypeScript is a superset of JavaScript, you can use it inside your applications. And it’s usually built into your editor too. So if I’m using something like VS code, I can know right away that what I’m doing is wrong. And of course, this this is very probably review for a lot of you guys, but I just want to make make this point that type safety is very important. So I’m a huge TypeScript fan. I use it in every single one of my apps. I think it’s the standard nowadays. I think if you look back about four or five years ago, people were still on the fence, like Angular two was the only major framework that really adopted TypeScript at the beginning all the way back and like 2017. But pretty much nowadays, in the last three, four years, all the other ecosystems, especially react, have really enjoyed and have used TypeScript. And most applications use it, and I would highly recommend it. And just a quick refresher on what this TypeScript is. It’s an free and open source, high level programming language developed by Microsoft to add static typing with options like type annotations to JavaScript. And so normally what happens is you write your application in TypeScript, and then it kind of compiles down to JavaScript. or something that the browser can understand. Alright, so I’ve been talking for a few minutes here, but I want to tell you a little bit about who I am. So I already had the great introduction by Brian, but I’ll explain again, I’m a developer advocate for AWS amplify, I’m gonna tell you what AWS amplify is, in a moment, I think a lot of people have not heard of it. You can always reach me on Twitter at Eric, ch, Twitter or X, whatever you want to call it, I’m always going to call it Twitter. And my YouTube channel is programmed with Eric, where I do a lot of videos like this, I do presentations, but I also deep dive into Vue js next, Jas, AWS tools, all sorts of things. And you can just go, you can either search for program with Eric on on Google or inside YouTube, or just go to Eric dot video, I own that domain, that’ll just redirect you directly to my YouTube page. And also, if you look back there, I’ve been doing, that’s a silver play button in the background. I’ve been doing YouTube for a long time, it’s real. It’s a real fun hobby of mine. Alright, so we got three goals today. So I’m going to want everyone who is watching this right now either live or on the recording later to take away a few things from this talk. And first, we’re going to talk about what is end to end type safety and why you may want to use it on your next app. The next is what problems does it solve? And then we’re going to look at some examples using amplify and trpc. And we’ll explain what those two are. And then of course, at the end, we’ll have some questions. All right. So what is end to end type safety. If you’re listening again, and you’re in the chat or at home, maybe you’ve heard this, I think less people have heard this kind of term and type safety. Most people heard type safety. So if you have heard of it, let me know. So we’re gonna have a, we’re gonna keep this really high level, and then we’re going to deep dive into some code in a second. So for the most part, you have your front end. And this is represented by this little sketch of a cloud here. And we’ll assume that in your front end, you’re using TypeScript, because we’re good developers, and we like types. And now we’re going to have a back end. And we’re also going to have our back end use TypeScript. I think this is a really powerful feature of JavaScript in general, that we can use JavaScript on the front end and the back end, and the back end, we’re going to use TypeScript as well. And then we’re going to assume that anytime we make calls to the front end to the back end, that we’re going to have types and these types are going to be kind of transferred and be known from the front end and in the back end.

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
And then we can add in authorization rules. So let’s say this customer table, we only want customers to allow them to update, create, update, and delete. But we want public people so anybody that’s not a logged in user to only be able to read it. So that might be a setting that we want for this. We don’t want someone to be able, from the public to update the full name or email, but they might not might be able to read it. And one of the most important things with this is we create this file, we put that that schema information and then we export a type from it. And this is going to help us do the magic of the end to end type safety. So let’s take a look at Ah, so here real quick. We also I mentioned a little bit but those authorization rules, but we’re going to have in this off as well. And this auth here will define a Cognito back end, and users will be able to log in just through email. And one thing, I just want to say with both of these examples, just with like five lines of code, this creates all the infrastructure you need. There’s no additional JSON files or sending files this, literally you take this, you run a command on the command line, and it deploys it all. And it creates everything for you. And same thing with this with this office will create a Cognito user pool, set it up with all the the security defaults that you need it also create a profile picture. So if you want an additional attribute when users log in, you can capture that. Alright, so to go back, I think we’ve kind of seen a little bit about how Amphi Gentoo works where it can create our infrastructure for us. But it also can create these schemas and models for our back end database or app sync database. Real quick, you can actually this faster local development. You can have every individual user in your organization, have their own ephemeral environment and be able to test against it. So I just wanted to make sure this was clear. User Nikhil at the top will have his own local ID. He can then spin up an environment that has his own Cognito user pool his own app sync and he’s been run queries against it and then he can you can stop the the sandbox and Anytime. And so it makes a really quick to, to, to do any kind of testing. So this is that’s what this graphic is. Alright, let’s move to the front end. Let’s look at next. I’m a big fan of next, but I’m doing this example next. But you can do with Knucks, you can do it with Astro, you can do it with your current, your framework of choice, we have a JavaScript library that works with pretty much everything. And we have an adapter system that you can use to create additional adapters. But I’m a big fan of next Jas and Knucks J S. So in our front end app, we have maybe a component that wants to list customer data, it lists a list of customer data, or just lists the first name and email. So we’ll have this generate client. Now the schema here is actually the schema that we exported out from that other file. So right away, we have that type safety built in. So anytime we do lists, creates updates or deletes we know exactly what’s on the back end that we created, because they were exporting that schema. And that case, we can actually use a use state and grab the customer data, actually set customers and set customers and it has the right types because I’m using the schema here. And then I can do this list customers. So I can do client dot models dot customer dot list. But I can also do create, read, update and delete. And that will work as well and I can set it. And something that I sometimes get questions on is with Graph QL. If you’re familiar with it, GraphQL is a way that it has like a single endpoint and then you can exact act ask exactly what you want back from it. And it really helps that problem where maybe you wanted just one field of a record. And instead you get everything every field that you don’t need. So GraphQL really solves the problem of over fetching. And the way we solve that in our API is we use something called a selection set. So in this case, maybe we wanted to just select the full name, or just the first name or last name, we can do that by using a selection set here. Here’s a simple example. Running. So on the left hand side is the client. So I have a new to do. And I’m going to create a new to do but let’s say I need to change something. So I’m making some changes here on the left hand side, let’s add a location with a customer type, float, latitude and longitude. And now right away, as I’m typing in the right hand side, which is our back end server, the left hand side already knows that this is a field that needs to be in there. And on the right hand side, I’m adding a priority enum. And now the left hand side knows that I have an enum and it’s high, low or medium. So you could see how quickly you can create your back end and have the front end automatically know everything about all the types and you’re never going to be out of sync between the two. You also see this dot notation, it’s dot schema dot model, you can have simple examples I’m showing have done string, but you can do integers, you can do custom and custom types. You can do all sorts of interesting things. If you’ve used Zod in the past, that’s a kind of a popular validation framework. This looks very similar to that. All right, so that is all I’m going to talk about AWS amplify, but if you guys have questions on at the end, I will be here. So but let’s move on to tRPC. And this has been gaining a lot of momentum, people have been talking about this thing called the T three stack. That’s next. And I think it’s worth mentioning to is kind of another alternative. trpc allows you to easily build and consume fully typesafe API’s without schemas or cogeneration. And the way I take that is that you aren’t going to have to use that cogeneration or or use any CLI tools to create the Typescript and the front end the back end. And it allows you to create these typesafe API’s that you can then share between the front end and back end, it’s quite a bit different than when I showed him the AWS amplify side, where the AWS amplify side is actually creating infrastructure for you, as well as allowing the types to be easily shared between the front end and the back end for that quick iteration. So this one is a little bit different. It doesn’t create any infrastructure or anything. It’s just a tool to kind of create these typesafe API’s. So there’s really three steps when you’re using trpc that you should know about. And this, this is important. So first, here is a big chunk of code that creates this router and these procedures. So let’s break this down into a couple of steps. So first, one of the most important ones is you have to create a router. And this router is essentially that type of query that’s going to be available from this is essentially the back end code that will be available in the front end. So in this case, we’re saying we’re going to accept an input, it’s going to be of type object, and it’s going to have a name and the name is going to be a type string. And then it’s going to, it’s going to be a query, essentially. And if we look at the next piece, it’s going to take the value that that name, and it’s going to return a string that says hello and put dot name. So this is a little bit of a contrived example. But you can see here you can create all these complex queries are any way you like it, using this, this kind of dot notation, almost Zod like, like interface here. So in this case, all it does is it takes the name in the object that comes over and just returns it as Hello, the name. Another step that you have to do on the trpc procedure here, the second step is create your an HTTP server. So the way that you do that, is you just use create HTTP server, you pass in that app router that you have, and you can listen to whatever port now if you’re using something like next Jas, there’s a way you can use the let’s assume using the app router, you can use the route handler and pass this into this. So you don’t necessarily have to create an additional HTTP server. But this is an important second step. And then finally, you connect your client and you start queering. So above, I have my create tRPC client, where I pass in that app router, I have the URL where the link is, once again, if using next probably a little bit different looking than this, because you’ll be using the app route handler. And then at the bottom, we have this trpc dot greeting dot query. And then you this will be tight for you. So you’ll be trpc dot and then you’ll see any queries that you created in the back end, this case, this greeting, and then you just pass in that object object with the name John, and it returns the response to Hello string. In this case, it’s fairly straightforward. And what this allows you to do now is you have that full and end type safety.

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
one? Yeah, that’s a good question. Yeah. So AWS amplify has a long history. And we’ve been iterating and making changes. And we’re almost like five different services. So we have a hosting service, which is really popular, we can host for like next 14 And next 13 apps. And also next apps and stacks like generated apps, we have a lot of different use cases. We have a UI, which is a UI components library that you can use that we have something called connected components. So if you want to just add in a login page to your app, you can just with a few lines of code boilerplate, you can add it on there, we have a JavaScript side, what I think you’re talking about is you have a studio is called amplify studio, which is a drag and drop interface to create your back end and it also connects up with figma. So you can create sketches or figma sketches like let’s say you have a very specific back end and you will have our front end that is and you have certain end You have like a figma expert, they can create the whole design of figma and then import it into AMPLIFi studio. And then we’ll generate all those into components with you using the amplify UI components system. So what we did is those are still there, they’re there were, they’re still here. And we’re not, they’re not going away or anything like that. We also have a command line utility, that you can use it to kind of add quick add, add auth, add back end, if people who love the command line, but we really found is that we got a lot of feedback that people really liked the drag and drop, but they really liked that developer experience that infrastructure as code. So we took all the kind of learnings from there. And we’re going and now we have this new gen two, it’s in developer preview. And we’re like, everything you can do in that studio, we have available, we have a plugin now that if you really liked the figma interface, they’ve made a code now you can use this plugin, and it’ll download the code into your app for you. If you really liked our form, our form manager, which create a forms for you, there’s a plug in for that now. So we’ve kind of taken everything we learned from Studio. And now you can do it on the command line. And so now we’ve you can not not in the command line, but inside this code, first developer experience where you’re in TypeScript. So now it’s kind of all available for it. So it’s a little bit of a shift if you use AWS amplify in the past, but I think it’s, it’s, it’s, it’s, it’s awesome. So I really like it.

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.