Erik Hanchett
===

Josh: [00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket provides AI first session replay and analytics, which surface the UX and technical issues impacting user experiences. Start understanding where users are struggling by trying it for free at logrocket. com. I'm Josh.

And today we have Eric Hanchette, senior developer advocate at AWS Amplify here to talk about Fullstack TypeScript, Eric. How's it going?

Erik: Hey Josh. ~Good. Good. ~Good to be on here. Thanks for having me. ~Uh, ~appreciate it.

Josh: Oh, we're excited to have you. Can you start us off by saying what is Fullstack TypeScript? Can you give us a brief overview of what it is and why it's important?

Erik: Yeah, it's a good question. So ~I, uh, ~this topic came about because I was,~ uh, ~looking for something interesting to give a talk to at a conference,~ uh, ~it was kind of conference driven development as you've probably done in the past. So I was really ~deep, uh, ~deeply researching this. It also ~kind of ~tied into a little bit of AWS Amplify and the stuff we were doing there.

~Uh, ~so I, I had been looking into it for a while and, ~uh, Uh,~ one [00:01:00] thing I love is TypeScript. I know you,~ uh, ~are a very, very big fan of it as well, needless to say. And I really wanted to see ~what, ~how companies and how I've seen it in the past and places I've worked at and how other people are handling this idea of having TypeScript in our backend,~ uh, ~TypeScript in our frontend and really.

~Uh, ~across the whole stack and then also including ~our, and then, uh, ~our testing as well, you can throw that in there and then ~how, how, and ~how people are handling taking types or taking data and payloads from our backend and having available in our frontend. I really wanted to see how that Fullstack typescript works.

~Uh, ~works, ~kind of ~this end to end,~ uh, way, ~way of looking at it. So, when I think of Fullstack TypeScript, I think of having types on the backend and types in the frontend. And I'll put a caveat to this, too, by saying, ~you don't nec I, ~I think most of the time, you would have,~ like,~ some sort of JavaScript on the backend and JavaScript on the frontend to make this happen, but that's not necessarily true, and we can get [00:02:00] into this more in the future.

There are ways of having a completely separate backend, That's written in go or rust or Ruby or something else and still be able to get types and still ~kind of ~have this end to end type script experience

Josh: let's dive in a little bit. ~Uh, ~there's a common term in industry. Folks like to band about end to end type safety. So in the context of what you're talking about, what is end to end type safety?

Erik: Yeah, I think,~ um,~ it's a good question. I mean, I think we all ~kind of ~seen what type safety is when we're dealing with types ~in our, ~in our editor. We'll be typing something out,~ uh,~ and we'll, of course, using our favorite. JavaScript,~ uh,~ and of course using TypeScript on top of that. And then we'll do something silly, like ~we might, um,~ we might create an object with a certain type and then we'll,~ uh,~ assign it a string when we said it was a number or vice versa, or we'll try to take a string and add it to a number.

So I've definitely made these silly mistakes. ~And, ~and as we have much more advanced types,~ uh, ~and interfaces as we code, ~that can be much, that, ~that can be very [00:03:00] easy. To do,~ uh,~ to have this kind of mismatch. And as we kind of look at this end to end type safety, the way I feel like it is that we have this contract with the backend and we assume that the data that it's going to be returning to the frontend is in a certain format.

~Uh, ~so let's assume I did this in my talk recently, where I was giving a customer model. ~Uh, ~we had a customer type that was based on that model that had ~like ~an ID and a name and a last name. And we assume those were strings. But maybe if ~that, ~that model changes,~ then, ~then in that case,~ uh, ~it wouldn't be what we expect.

So the idea, kind of what I think of is that we can assume in the frontend, when we're doing calls to our backend, that the data that is being returned is in a certain format. It's in a, it's compacted a certain way. ~Uh, ~and that we're assuming that when we receive it, it'll be in that format, it'll be ~in that, ~in that type safe way.

And there are other things to consider,~ uh, uh, ~[00:04:00] serialization being one of them,~ uh,~ a poor distinction, that when we are trying to grab data from a backend endpoint, you have to probably convert it from an object or a JSON object to a string before it gets translated over, but then you assume that once you put that back into an object and when it gets back to the frontend, That it's in a certain format.

So I believe when we have end to end type safety, the frontend is in sync with the backend ~and, ~and the data and types that are coming from it. That's ~kind of ~a long way to explain it.

Josh: I really like how you went there. And that last bit on frontend being in sync with backend is really key. ~Right? ~Because you can have type safety within an area, within an application, but what's external to it is potentially completely different from its understanding. ~Yeah.~

Erik: ~Yes. ~Yeah. ~Uh, ~yep, exactly. ~So. ~To having type safety within the program, I think is like the first steps, like just,~ uh,~ not using any everywhere and just having our types as we imagine them to be everywhere. And anytime we're moving information from one component to the other, or just with inside a [00:05:00] component that we have the best practices and types and that were covered there.

But when we start dealing with outside factors and we're dealing with a backend or even a data source that we don't control, then that's ~kind of ~where the end to end type safety. ~It is where I,~ it is where it's at.

Josh: Before we dive into some of the specific tools like TRPC and Amplify that help with the E2E type safety, do you have any favorite bugs or issues you've seen caused by not having end to end type safety?

Erik: ~Oh, well,~ I know personally I've made that. I used to work ~on a, ~in a startup that was, ~you know, ~really fast moving. And we were continuously working,~ uh, ~with a backend that was in flux. And we tried a lot of things ~in our, ~in our frontend,~ uh, ~as a frontend developer to ~kind of ~mock out that backend. We've tried setting up, like there's an NPM library where ~you can create like ~You can just feed it a JSON library and it creates this ~like ~mock ~end, ~end point and you can just hit it back and forth.

~Uh, ~we've also tried, I don't know if you've ever done this, Josh,~ uh, ~like just creating fake data inside [00:06:00] your frontend. Like, Oh, it's going to really do this fetch call, but we're just going to hard code it, returning this array ~of, ~of ~data. Um, and then having it or ~JSON data and then having it,~ uh, ~do everything.

So ~I ~I've definitely seen this in the real world where. It's easy to get,~ uh, ~the backend ~to, ~to get ~off, off one or ~off from the frontend. I'm trying to think,~ like,~ a specific scenario I've seen. I think mostly it's been, like, ~oh, I think ~one time in production this happened where ~the, ~I was expecting ~a ~data in a certain way, in a certain object.

And the backend, we had this really complicated step by step wizard that you had to walk through and every single page asked you a set of questions. And then we had the backend that would send the information for that page. And then one of the pages, the backend decided to change their contract with us.

And the data that was sent to the frontend wasn't what we expected. And the whole page would just be blank. So in production one day, customers going through this wizard to fill out this information. And then when they got to that page, it was [00:07:00] just blank. They couldn't continue forward. So obviously that was a breaking change that caused us a lot of issues.

And of course, when we looked at it, it's like, Oh, ~the,~ it changed and now we have to deal with it.

Josh: ~One wonders, oh, sorry, go ahead.~

Erik: ~I was just thinking, uh,~ in that case, we also did have a swagger file. We're using open API. ~Uh, ~but we didn't have really any great way to generate the types from that backend code gen wise.

Josh: One wonders how much money has been lost by companies, startups and big corps. From not having, ~you know, ~synchronization between the frontend and the backend in terms of types,

Erik: ~I'm probably, ~probably a lot.

Josh: but all right, ~we've ~we've decided the problem statement is real. We've experienced it ourselves. I'm sure many of our listeners have as well. Let's dive into the tooling. So could you give us just an overview of each of these? Let's start with what is T R P C?

Erik: Yeah, I really like this tool. It's a lot of, by the way, these tools we're talking about today are open source. ~Uh, ~AWS Amplify, we'll talk about a little bit later. So it's still open source. The libraries are, but it has ~some, ~some closed source stuff in there. But the H1, if you look at the TRS PC, io website says it [00:08:00] move fast and break nothing end to end type safe APIs made easy.

And so really the experience ~is, ~is that,~ uh,~ you can wrap your backend in like ~this, ~this,~ uh,~ proxy that this gets client, this TRPC client,~ uh,~ server, I should say, and you also have a client and you wrap your backend in it and ~it, ~it uses some of the, ~kind of ~the modern tooling that we all love today, like a Zod with its.

~Uh, ~validation library built into it. And then you can build queries and inputs and return statements with this TRPC,~ uh,~ to be able to,~ uh,~ create it in such a way that ~it, ~it has a type that can be then exported back to the frontend. And then you have, on the frontend, you have ~like ~a TRPC proxy client that then you can type it with the backend type.

That's passed in from the backend. This is on the frontend. And then,~ uh,~ it gives you all the nice features that you would expect, like dot completion. So that [00:09:00] IntelliSense ~that we had be, ~that we love ~in, ~in TypeScript,~ uh, it will also give you, ~it'll be in real time. So as you update the backend, the frontend will be,~ uh,~ type.

Correctly, and it will give you an error. And really nicely about it too with the validation. ~So, ~when we set up our backend endpoint, ~I, ~let's imagine we wanted it to only accept a input of an object and maybe that object has a,~ like, ~name in it and you want it to be a string and have a certain amount of characters or you want it to be required or optional.

You can set that in your definition directly inside code, ~uh,~ with inside of it. So, you don't have to. I don't know if you've created RESTful endpoints in the past where you have to do all these checks at the beginning. Okay, is it undefined? ~Uh, ~did they just send nothing over for that? ~Uh, ~is it the certain amount of length?

You have to write all this code. That's all built into the Zod Validation Library that works directly ~with ~With TRPC. So it's kind of a nice way of creating this end to end type safety [00:10:00] for your app. And it's become really popular on the Next.js side too, with server components and also with the Page router and app router.

So both ~kind of ~the newest~ and, and, ~and the older version way of doing it.

Josh: I want to really encourage people to visit that website you just mentioned, trpc. io. Their homepage has one of the best code demonstrations I've ever seen in a dev tool. A lot of folks come in going, okay, what is TRP, why do I care, frontend, prosthetic? It has this beautiful visualization where as you change things in server.

ts to change the types, client. ts starts giving a TypeScript squiggly with a red line showing, oh, the types are updated, you need up. It's fantastic. What a great demonstration.

Erik: ~Yeah, I was kind of, uh, ~as I was talking to you, I was looking at the webpage,~ uh,~ yeah, trying to,~ uh,~ distill it down into words. Why it is, I mean, it, it also is small bundle size batteries included. ~Some, although it's not needed for every, I mean, we're, ~I'm talking about a few tools today, those tools aren't necessarily needed for all instances.

And some instances you don't, for example, I'm a big fan of Nuxt. js, which for those [00:11:00] who don't know, it's like the server side rendered static site generated. Meta framework on the view side and it has some of these features already built in that ~we're gonna about talking ~We're talking about that uses unjs in the background So if you are doing some sort of end to end type safety You can define your backend in NUXT and it will be already available ~kind of ~built in batteries included so when you start doing a Fetch to the backend or use kind of some the tooling and NUXT to do fetches There's a couple of different utilities.

It'll already be typed for you, so you don't have to necessarily type it. So there are some tools that kind of do it for you. NestJS also has some nice tooling for that.~ Uh, ~but if you're not using those, then I think these tools are a great way to start off with. And it's become a very hot keyword, I think, this end to end type tool.

Type safety. People have been Googling and looking more into it.

Josh: to how universally annoying it is to get it wrong and useful it is to get it [00:12:00] right.

Erik: You bet.

Josh: Cool. ~Well, ~let's move on. ~Uh, ~two of three tools we're probably going to highlight. What is ORVAL? O R V A L.

Erik: Yeah, this one I,~ uh,~ I was working with an engineer ~at, ~at AWS ~and ~a while back and he just gushed about Orville and how much he liked to use it on his team and I had,~ uh, ~since been,~ uh, ~enjoying it as well. It's ~kind of ~the same idea as tRPC but it's implemented a lot differently so it does allow you to,~ uh,~ H1 on the page, you can go to orval.

dev, O R V A L dot dev, I'm sure it'll be in the show notes too. ~Uh, ~you can generate client with appropriate type signatures. And,~ uh,~ what's nice about this is, It's kind of have a code gen way of creating your type. So it assumes that you're using like a swagger file or,~ uh, ~mostly you have to use some open API spec, ~kind of ~like swagger being the most popular one of creating your backend.

So that's a way you can ~kind of ~define your backend,~ uh,~ endpoints. It's really great for,~ uh,~ testing ~and, ~[00:13:00] and ~kind of ~a visual way of looking at all your endpoints. It creates like a, you can create like a whole, Web page out of it. So as long as you have that set up in your backend, Orville can then code gen, meaning they could take a look at ~that, ~that OpenAPI spec or that Swagger file that is, and create the file for you with all your types in for your endpoints.

And ~it does, ~it does more than just that too. It creates, ~An HTTP, uh, ~HTTP calls. So actually ~create, ~create HTTP calls and you can set it depending on what stack you're using. So let's imagine using React and our favorite React query that everybody uses. It'll ~actually, ~actually create the React query. kind of utility functions for you to make the HTTP endpoint calls for you.

It'll all be typed for you. It also uses one thing that the other two tools don't do, although you can argue Amplify has something a little similar but implemented quite differently, is it creates the mocks for you. And if you use something like MockServiceWorker, It generates mocks with mark [00:14:00] service worker so you can then completely test locally on your side against using MSW with the mocks already created for you ~to, ~to make sure that your endpoint works great.

And typically the way you would do this, I've seen, and I've seen others do it, is you would ~like ~set this in something ~in your, ~in your package. JSON and your build settings. So every time you build. You're taking a look at that Swagger file, you're regenerating all the types and everything. So it does have that kind of extra step.

You could still get out of date if you're not keeping up with generating the types. But for the most part, it works really well. And it also, ~you can generate,~ if you're not using React, also set it to Axios for your HTTP calls. So you can use Axios as well. And I think it also uses Angular HttpClient, it said.

So it's really neat,~ um,~ what you can do with it. And I've just been, it also does spelt query and view query too.

Josh: Does everything

Erik: Yeah.

Josh: ~I ~you brought up a lot of awesome things there and I want to make sure we're diving into each of them. So [00:15:00] in order, I'm going to try to remember about asking about,~ um,~ who mocks and open API and,~ uh,~ MSW. Actually, let's start with open API and swagger. What is an open API spec?

Erik: ~Yeah, so the API,~ OpenAPI is a specification. I'm going to ~kind of ~read your definition, then we'll ~kind of ~talk a little bit. But yeah, it's basically a specification,~ uh,~ previously known as the Swagger specification. ~Um, ~to create like a machine readable interface defining languages for describing, producing, consuming, and visualizing web services.

It looks like a big YAML file when you look at it,~ uh,~ but you can then use it to,~ uh,~ show ~and, ~and look at the HTTP backend calls that you have. ~So, um, Uh, it looks every single,~ you can kind of define your backend and there's a lot of plugins for this that,~ uh,~ add swagger to it. And the way I've seen in the past is that once you have this,~ uh,~ plugin installed, it'll create this YAML file describing all your backend endpoints.

And then there's tools to like literally visualize that on your page with ~like ~a webpage. And then in the webpage, you'll be able [00:16:00] to. It'll create like a local site running. You can even host it somewhere. And then you can even do tests to each end point ~in that, ~in that page,~ uh,~ depending ~on where,~ on what you have it.

So there's a bunch of different tooling around this kind of spec to make it easier to define your backend.

Josh: That's really fascinating that we have this standard format of whatever the two names, one might use that lets you define not just what the endpoints are, but how they behave, the description around them, the ability to programmatically generate tooling or code or tests on them. That's really powerful.

Erik: Yes. And ~you can even visual, ~you can even like create, start with the,~ uh,~ like swagger file first, and ~then, ~then to have that generate your API. So there's a whole bunch of ways people can ~do that. People ~handle that

Josh: ~Yeah,~ I've seen and occasionally done myself the practice of having a strongly typed language host or be the place where you describe your endpoints. Let's say you have a TypeScript server with Node, and then from the type information in that endpoints description in whatever decorators or functions you're using, then you generate the OpenAPI spec from the code.

Erik: exactly. Yeah. That's the [00:17:00] way Nest, I believe, does it. ~Yeah. ~Uses decorators and things like that and uses a class space, which makes it nice. You just, you literally ~in, ~in a Nest one,~ uh, ~you just put the, the direct decorator, I think it's like open API or swagger or something, and then it'll just generate everything for you, which is really nice.

Josh: Yeah. People like to say developers are lazy and that's a good thing. If there's anything we can save ourselves from having to do, ~right. That's, ~that's good for us in the product.

Erik: Yes, it is.

Josh: Cool. All right. Well, let's move down that, that sub list. You mentioned mocks and MSW. So what are mocks ~in, ~in the abstract?

Erik: ~Yeah. Mocks are a way to, uh, I~ it's a way to like mock your backend. It makes like fake,~ uh,~ stubs of what your backend should be. ~Uh, ~it'll return back like fake information back to you. ~Uh, ~it's kind of way I've, I think of it. You can literally. mock something by, I mentioned earlier that I've worked in frontend code bases where we just returned back a JSON blob that we mocked every time you called it, you could just, instead of doing the fetch call, the backend, you could just comment that out [00:18:00] and return a JSON blob to do your testing.

And I guess you could call that ~a, ~a,~ uh,~ A mock of some sort, but as you get more sophisticated, there's a lot of tooling that can help you mock out your backend and all the end points. You're not actually talking to the real and the real server in the backend. You're talking to ~these, ~these mocks instead.

~Uh, ~and then mock service worker ~is, uh,~ is an API mocking library that helps you ~kind of ~do all this for you and you can write,~ um,~ client agnostic mocks that work across different frameworks on it and it's ~kind of ~a very useful tool. ~Um, I, ~when I was doing it,~ um,~ on the AWS side, we have something called an API gateway and you can set up mock endpoints through there.

And that's ~kind of ~how I've done it in the past when I was working on an AWS project,~ uh, ~and I hadn't used too much of this mock service worker, but it's pretty powerful. ~Uh, ~one thing too, I was mentioned with Orville, it creates the mock ~service Uh, ~service worker that this definition that you can use with this API library to mock it out, but to actually get the data [00:19:00] uses another lab library.

I think you are probably pretty familiar with it, Faker. So use this Faker JS to actually generate a bunch of,~ uh,~ fake data for you to use with the mock to send back to you. So you can do names,~ uh, ~addresses are like really common ones, fake email addresses, anything you want, you can use Faker to do.

Josh: That's great. A lot of people have time to unit test code, but when it comes to testing more complex flows or your application end to end, to use that term, it can be ~kind of ~a pain in the butt, a lot of time suck ~to, ~to do that. It sounds like this would be a really useful tool if you're trying to test your application or parts of it more than integration form.

Erik: Yeah, that's a good point. Yeah, it's definitely ~very, it's ~much faster than if you were doing like an end to end test and you're actually hitting ~like ~a real server somewhere and having to wait for that ~come, ~to come back. ~Uh, ~it's probably ~not as, it's ~not as fast as unit tests, but I mean it could be pretty darn fast.

These mocks will just return stuff right away and you can ~like ~quickly test ~in, in, in, ~in the thought of ~like ~the whole test suite of things that you're doing to test. It's probably [00:20:00] unit. And then,

Josh: For sure. Okay. This final ~three of ~three of the main tools to cover, guessing this one, you're probably the most excited about. Can you tell us a little bit about AWS Amplify?

Erik: ~yes, yeah, uh, that's a good question. So we, ~so ~I'm, ~I'm a developer advocate, a senior developer advocate at AWS. ~So, uh, ~I'm not trying ~to hear ~to pitch,~ uh,~ AWS Amplify to everybody, but I think in the lieu of this conversation of end to end TypeScript,~ it, ~it, Fits in well with it. ~Uh, ~although if you do wanna try it out, you can always go to,~ uh,~ our Amplify website, AWS Amplify.

~Uh,~ so the idea behind,~ uh, ~AWS Amplify, it's a set of tools to help frontend developers create Fullstack websites. And one thing we saw, there was actually a couple different generations of this Amplify product. ~Uh, ~we had ~Ampl ~AWS, amplify Gen One, and then our latest we call Gen two. ~And ~one thing we saw ~with our, ~with our Gen 1 is, was lacking some of those TypeScript things that, ~uh, you know, you, ~you know and love, with this auto completion, and having types everywhere, and having your,~ uh, ~library type.

The JavaScript library that we had created ~is, uh, it ~goes all the way back [00:21:00] to ~like ~2017, where ~types, uh, ~TypeScript had not been,~ uh, ~As an important ~emphasis, ~emphasis as it is ~in, ~in 2024, 2023. ~Uh, ~so we didn't have as many types in that. And we also didn't have this concept of doing this end to end type.

safety that we've been talking about for the last 25 minutes. ~Uh, ~so we really went back ~and ~with our gen two product and we said, okay, let's make it easier that all our libraries are TypeScript aware that we have types for everything. It's a first class citizen,~ uh, ~and that ~we, ~it works as you expect it.

And so these types, we have like basically SDKs or JavaScript. Libraries that talk to AWS services. ~So, ~for example, let's imagine you wanted to talk to our authentication authorization Cognito identity management service. Then we have our JavaScript library that can do that. Or let's say you wanted to ~do, uh, ~take a set of words,~ Like, ~like a list of things and you want to do translations on them.

We have libraries that do [00:22:00] that, or do speech to text, or text to speech. And we wanted to make sure that was all typed, and that's what we did with Gen2. ~Uh, ~and then we also,~ we, we ~found that,~ uh, ~With,~ uh, ~Amplify Gen 2, since we know that people are using AWS services and one of our most popular one is something called AppSync, that's ~kind of ~our data management layer, data management service, and we wanted to make sure if people were going to use that, that if they're using it with React, Vue, Angular, All, Svelte, Astro, that they could get this nice end to end type safety feature to it.

So we took inspiration for a lot of these tools I talked to you about today and many others, I'm sure, and we created this way of implementing it. ~Of, ~of defining your backend schema,~ uh, ~your model that would create this kind of like infrastructure as code, but in a very high level with only a few lines of code, you can then create your AppSync database layer, and then it would export out and it export out a [00:23:00] type that you can then use in the frontend to have this nice end to end type safety, kind of a similar, as you mentioned earlier, when you saw the TRPC, ~Uh ~video on their front page where they were making changes to the backend.

It was updating the frontend We have something very similar, but ~we go ~we go one step further because now we're actually not just ~uh ~wrapping an api we're actually creating your database layer for you and then giving you the option of Exporting it out and having this nice end to end ~Uh, ~data consistency between the two.

And then we used tools ~like Zod, uh,~ similar to Zod, where we have this ~dot completion. Uh, and this, excuse me, ~validation for the schema itself. So you could say, Hey, this field has to be at least ~three, ~three letters long. It has to be required. ~Uh, ~and you ~kind of ~get all that nice validation rules that you can add in directly when you define the schema. And so we really took a look at ~all, ~all of that.

Josh: So does that mean that Amplify is in part an ORM,~ uh,~ like Prisma?

Erik: Yeah, you can ~kind of ~think of it that way. Basically we have our frontend language. Our JavaScript library,~ uh, kind of, uh, ~works to the point where you can do [00:24:00] dot list, create, read, update, delete, it's all typed. And,~ uh,~ it works directly with the schema validation, the schema that you just created. So, it really makes it very quick to just really quickly create your backend,~ uh,~ data layer.

And not just, I mean, we're talking about data in this scenario, but we can do it with auth. And storage and functions are also really popular.~ Uh, ~so you can really quickly create that, but then have it available all typed in the frontend too. So if you used it for Prisma,~ uh, or that, ~or you can maybe make some parallels to Firebase and some other ones.

You ~kind of ~get that same sort of tooling with Amplify.

Josh: Let's say that I was a fledgling DevRel or DevAdvocate somewhere around your team, and I wanted to show off using Amplify Gen2 with just arbitrarily, let's say, Next.js for like a to do app, or, ~you know, ~one of those standard Hello Worlds people do. What would be the kind of general set of steps you'd suggest I take to build this application?

Erik: Yeah. Okay. Yeah. ~So, uh, ~first ~there would be a,~ you would sign up [00:25:00] for AWS if you hadn't already. We have a pretty generous free tier and most of the things I'm talking about today, too, you only get charged. They're all on demand services. So you only get charged when you use them. So you're not going to have to worry about,~ um,~ getting, ~you know, ~hundreds of dollars charged because you are using like some EC2 instance that's always on.

~Um, ~So that's not it. And then, like I said, the free tier covers pretty much everything. ~So. Uh, ~first step would be to sign up for AWS free tier. ~Uh, ~then you would, let's imagine you already had the next application up and running. Then you could install our JavaScript library,~ uh,~ our TypeScript library, that is.

~Uh, ~then you would run this command line,~ uh,~ command line, assuming that you're using NPM, or you can use any other, Package manager, but let's assume you use the npm, you do npm create Amplify at latest, and that will create some folders with some boilerplate code in there.~ And, ~and in fact, the boilerplate code you get out of the box is a to do [00:26:00] app because we know,~ uh,~ developers all everywhere love to do apps.

So you can even just start with that. ~It, ~it'll actually have one, it'll create a new folder inside your frontend code inside your next app that says Amplify. And inside there, there'll be a folder,~ uh, ~for your database. And then inside there, you'll see some TypeScript. And then you can then define your schema inside there.

Maybe you want to add in a date. Or, I don't know, author or some other things in your to do. And you can then save it. And one thing really nice is you can run this command on the command line to create an ephemeral sandbox. Which then,~ uh,~ creates going back to this mocking that we said earlier, but this actually ephemeral bot,~ uh,~ sandbox can create a whole backend for you in the cloud that you can stop or start at any time.

So you can run this one command ~in the, ~in the command line, it'll create the sandbox environment, and then you could start testing right away. And then you'll write some frontend code. To talk to that schema, you would create a [00:27:00] client, you would pass in the type from the backend from that folder that was created.

You'll then have that end to end type safety and then you can do things like, it'll know all the models. So you can do client. models. create and then it'll tell you through IntelliSense like, Oh, you need to add in ~a, ~an author. Oh, you need to add in content. And then you can start working with it right away.

And then when you're ready to do this for production.~ Uh, you, ~you can,~ uh,~ log into our Amplify console, which is just in the AWS console, and you can hook it up to your Git provider. So if you're using GitHub, GitLab,~ uh,~ any of the providers that, version control system that you have, and then you can hook it up.

So every time you push, you can create like a production environment, or you can push to a QA environment,~ uh, ~similar to,~ uh, Uh, ~Vercel or any of those other ones, it's connected to your version control system. And then you can have your local environment, your sandbox environments test locally, and then [00:28:00] you'll have a production or QA environment that you can start pushing to.

Josh: That sounds great. Speaking of pull requests and changing over time, what happens if I want to change my model? ~Like, ~let's say I want to add a new required field or,~ uh, ~remove a previous field. So you have migration support or anything like that.

Erik: Yeah, ~so we, ~so AppSync itself is based on GraphQL. So it's ~kind of ~under the hood, it's using GraphQL. And the GraphQL,~ uh,~ as you know, ~doesn't use, ~typically it doesn't have like versions and migrations the same way you might have in other databases. So you usually don't have that problem. Now we abstract away a lot of that logic away when you're using our tooling.

~So ~you don't have to literally write GQL and you don't have to write the resolvers and everything for you. ~We, ~our AppSync layer, since it's a managed service, it creates all that for you. Although if you do need to ~kind of ~jump down to the nitty gritty and deep dive down to slow details, you can, but for the most part, like a happy path and you just want to create.

A crud endpoint, you don't need to do [00:29:00] that. So if you do ~kind of ~delete values,~ uh, the model will, ~the GraphQL will just make those changes for you. ~Um, ~but it doesn't have that type of migration support in the way you're ~kind of ~thinking ~before ~because ~it just, uh, ~it just kinda has one version there.

Josh: Cool. So just for folks who haven't played with it before, could you help us out? What is GraphQL?

Erik: Yeah, sure. These are great questions. ~Uh, ~so GraphQL is like a data query manipulation language for APIs. ~The kind of, ~the way I ~kind of ~describe it is,~ uh,~ it's a different way to create ~an ~endpoints for your app. So typically you see a lot of people using REST and REST is like you have these different, and there's a whole way you can create like ~RESTful, ~RESTful interfaces.

And it's usually ~kind of ~synced up to the post. ~Uh, ~get, delete, and you have very similar naming when you have these endpoints set up. So maybe you have like a slash create that, uh, use the HTTP create, and you [00:30:00] send that type of value over to it and it'll create something or you delete something.~ Uh, ~GraphQL has ~like ~one single endpoint.

I believe it's a post endpoint. And you have this, what's called like this graph query language that you send over from the frontend to the backend. ~to, to this,~ to this endpoint, to do things. And what's nice about it is you can be very exact on what you want back. So one problem that you might have in a RESTful interface is you have this idea of overfetching.

So you might ask for too much information. ~Well, ~in the GraphQL, you can specify exactly the fields that you want back, and it'll retrieve and push them back,~ uh,~ to you. And then you ~kind of ~create all that logic. You have to create what are called resolvers. So that way, when you hit different parts of the endpoints, that it connects to your database or does authorization and things like that.

Now, one criticism I've heard of GraphQL in the past is that setting off is not always straightforward. But one nice thing with our AppSync service, you can literally [00:31:00] add off to any of the fields. We have field level authorization, or you can actually do it on each table itself and have authorization rules built in.

You can say only certain groups can talk ~to these different, ~to these different,~ uh, areas,~ different parts of your app.~ So, ~and then on top of the GraphQL layer, there's a database. And the AppSync layer, it defaults to DynamoDB, which is ~a, ~like a NoSQL type database. You can switch it up to Postgres if you're ~a more of a R or RDS, more, ~more of a relational database fan,~ uh, ~an existing RDS database. ~So it's in one, ~I can keep going with, with Craft2L, but there's like queries and mutations. ~Um, ~there's a whole way ~you can, ~you can talk to it.

Josh: Yeah, there's a whole world and I think this is going to keep coming up if you were to keep going through tech that every time you bring up a new piece of technology, it feels like there's another set of three built underneath it. But I think one of the really powerful points of something like TRPC or AWS Amplify is that you don't need to understand every single core foundational thing underneath it.

You don't need to understand GraphQL deeply to just go through ~the ~the [00:32:00] to-DO app, hello World for Amplify. You can discover that later if you end up wanting to and needing to.

Erik: Exactly. Yeah, we do have layers of abstraction on top of it. ~So. ~When you go in and you create your database schema, if you want to, you can drop down, we're built on something called cloud development kit, which is a infrastructure as code tool. So if you are needing to set up a very specialized,~ um, ~situation you're in, you can drop down to that level and then write all that code.

~Uh, ~to create any sort of service that you want to,~ uh, ~any of the 200 plus services are available ~with, ~with our cloud development kit you can actually drop down to. But we see that there's probably four main use cases a lot of people have when they create apps. They need to have some database layer.

They probably need some sort of authorization. They probably need some additional storage like through S3 ~and, ~and serverless functions for maybe additional stuff you want to do on the server. So those are the four main area points. That we support, but you can always drop down and get even more,~ uh, ~if you [00:33:00] don't like the layers of abstraction that we have.

Josh: ~Well, ~as much as I would love to dig into all of those, we're running short on time. Eric, is there anything else you wanna convey to the audience?

Erik: No, thanks for having me here. If, yeah, if anybody's,~ uh,~ interested ~in, ~in this last 10 minutes,~ uh,~ jumping into Amplify, you can go,~ uh,~ search for AWS Amplify or go to docs. amplify. aws. And you can also contact me at EricCH on Twitter, E R I K C H, or I have a YouTube channel too.~ Uh, it's, uh, ~you can just look for Program With Eric, or just in your browser go to eric.

video, and that'll just redirect you directly to Program With Eric.

Josh: Wait, you have the Eric Video domain.

Erik: Yes,~ yeah, ~yeah, with C and K, so I bought both of them.

Josh: that's incredible. Nicely done,

Erik: Yeah.

Josh: ~Cool. ~Well, for Log Rocket, this has been Eric and Josh. Thanks you all for listening. Have a great day. Cheers.