In this episode, Steve delves into a deep and insightful conversation with Erik Hanchett from Amazon AWS. They explore a wide range of topics, from discussing the possibilities and complexities of using multiple software services for back-end development to unraveling the benefits of using services like AWS Amplify for handling multiple tasks and integrated functionalities. The conversation also touches on the development and deployment processes, local testing environment setup, language choices, and the Vue component library with connected components and theming. Erik shares his vast expertise and knowledge in the field, and the engaging dialogue offers valuable insights and recommendations for both experienced and aspiring developers.

STEVE_EDWARDS: Hello everybody. Welcome to another exciting episode of JavaScript Jabber. I am Steve Edwards, the host with the face for radio, as you can see, and the voice for being the mime, but I'm still your host. Today, due to last-minute time changes, we won't mention why, I am here with Mr. Eric Hanchette of Amazon AWS, you might have heard of Amazon. How are you doing, Eric? 

ERIK_HANCHETT: Hey, hey, thanks for having me on. I appreciate it. And thanks for being amazing with the time slot too. I appreciate it.

STEVE_EDWARDS: No worries. For those of you who might've had the privilege and honor of listening to views on view, I've talked to Eric a few times. Eric is rather prolific in the view community and you can literally say that he wrote the book on view, released a book on view back in the days of view too. And now works for Amazon web services, incorporating JavaScript and into AWS. And we're going to talk about that. So and you also might know him from his program with Eric channel on YouTube and training courses and many other things he's done. So, uh, welcome Eric. 

ERIK_HANCHETT: Hey, thanks for having me, Steve. Yeah. Yeah. I have, uh, me and Steve, Steve hosted the views on view podcast for many years and I got to be a cohost for, for a little bit of that. And that was amazing, but, uh, I am not here just for view. I'm here for next react, angular Astro. No, I am today, I am a fan of every framework. 

Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? So if you go to topendevs.com slash resume, enter your name and email address, then you'll get a copy of the resume that I use, that I've used through freelancing, through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I said, topendevs.com slash resume will get you that and you can just kind of use the formatting. It comes in Word and pages formats and you can just fill it in from there. 

STEVE_EDWARDS: And before we go on, for those of you watching this or seeing the video later, we will try not to hold it against Eric that he's wearing a San Francisco 49ers jersey and just leave it at that. So anyway, okay, so let's talk. So for history purposes for a while when Eric was getting up and going, he worked for an insurance company and then doing this always cracked me up. You did all these view videos and view stuff, but you were doing angular during the day at work. And then he moved over to Amazon and started working there. So why don't you tell us what you do at Amazon and how you incorporate JavaScript into what they're doing. 

ERIK_HANCHETT: Yeah. For sure. I'll take one step back, just to add a little, little bit more to that story. I was working at an insurance company, more like an insurance, insure tag startup, and I did push a lot for them to use view, but they were dead set on using angular, they had a Java backend. So we ended up going with angular. Luckily before that, I got to work at a job where I did a lot of Java, but I kind of got to choose my front end. So I got to kind of dabble in a lot of things. So I had a little bit of time working on Ember, which was really fun. Thank them for the most part, we did just basic jQuery and HTML in the job before the insurance company, but it was fun to kind of test them all out. So when I moved over to AWS, Amazon Web Services, I was a part of a team, a front-end engineering team that used Vue. So that's one thing I kind of surprised some people when I talked to them about. AWS first is when you think of AWS, you probably think of DevOps, serverless, Lambda functions, infrastructures, code, Kubernetes. And it's fun to talk to them about, well, actually AWS is a huge org. We have lots of different teams and one of the teams deals a lot with front end. I mean, obviously there's the front-end amazon.com website, but we actually create tools for front end developers. And so I was a part of a team call. We called ourselves the amplify UI team. That created these tools for developers to connect to AWS services. And one of the most more popular ones in there was something called Cognito, and a part of AWS Amplify, which to give that a definition is that's our Amplify, our definition, our kind of motto for AWS Amplify is to help front-end developers create full stack websites using AWS services. And so when I was using Amplify or when I joined that team, we created a UI components library that made it easier to connect. We had something called connected components and those were made it easier to do common things that you would do on AWS. And one of them was to create an authenticator and that allowed users to sign in, sign out, use multifactor authentication, use federated logins. So I was responsible for creating the view version of that. And it was a really fun year, year and a half working directly in view, creating this open source library that is used by tens of thousands of developers, which is awesome. And then about a year ago, I moved into more developer advocacy, which is what I do now. And so what I do my job now is to talk to as many people as I can about AWS Amplify, its services how I can find solutions for people and just kind of get the word out that AWS Amplify and AWS in general is just not DevOps and backend only and that amazon.com website you order stuff for, but that we have amazing developer tools for everybody. 

STEVE_EDWARDS: So one thing we clarified when we first talked about this was that basically this isn't a front end for you if you want tools to use, if you want to build sort of your own back end. The idea is that you're using AWS services to build your web application or site for whatever it is. And so these tools make it a lot easier to do that. So you're not having to go in and manually configure a whole bunch of stuff. Is that a fair statement? 

ERIK_HANCHETT: Right, yeah, we have same defaults. So let me get a little bit more specific. So I've been kind of 500 miles up right now. Let's go down a little bit closer to the service. So for example, we have a service called Studio, which is like a drag-and-drop interface to create your backend. So let's say you needed to add in authentication, you just kind of click a few buttons as authentication, you want to add in a database. And what we recommend is AWS AppSync, which is our managed GraphQL service. And then you can create your schemas all within there. And then you can download it into your app. You can also add forms. So that's like one service. One that's really, really popular is our AWS Amplify hosting. And so we saw that what other hosting companies doing, we wanted to do the same. So we have a hosting that works really well with Next 13, Next 14 for server side rendering or static site generation. But you can also host any sort of static site on it that you'd like. And it's just a couple of clicks. You run a couple of commands, the command line, and you can push it up directly to Amazon services. Amazon services and that's completely managed. So you don't have to necessarily know how to set up your cloud front distribution, how to set up all the internals and get the Lambda serverless stuff for Next. We do that all for you. So we have like more of a managed service. And then one new product that we just created, and it's in developer preview right now is something called AWS Amplify Gen2. And we're very focused on the front-end developer experience. So in that case, you can create like your new Next app. And then through the command line, you can type a couple of commands and we'll auto-generate a bunch of boilerplate code for you. Actually, it's not even that much of boilerplate code, but that code can be used as what we call infrastructure's code and you can run it. And it'll provision and create in the background using something called CloudFormation, a backend for you. So you can get everything for, you can add in, your identity provider, which is Cognito. You can add an AppSync and the schemas. You can also go down to what we call the Cloud Development Kit, and then add any other AWS services. And so we wanted to make it very straightforward to use this command, generate it, and then create this code first experience to your backend. And then it connects. It almost has like a end-to-end type script, type safety feature, where you can create your database and then have it available in your front end, the schema for that in your front end. So it's typically when you use GraphQL, you get some of that, but it's usually not TypeScript specific, but this is TypeScript specific. You can create a advanced schema for your backend, all your models, and then have that available in your front end. So those are kind of some of the things that we do at AWS Amplify. And thank you for putting the links on the screen too. That's very helpful. 

STEVE_EDWARDS: I'm all about banners. They may have so much more fun. Um, okay. So let's go back and talk about a little of that. Uh, so databases you said the graph QL is obviously not your database. That's your way you connect to that's your API. Right. So what are the, uh, database types that, that you support. I mean, obviously there's your, your my SQL and your postkits, right? I'm going to guess there's some sort of Mongo or document database option or what other options do you have available? 

ERIK_HANCHETT: Right. Well, there's a couple of things there. So depending on what sort of API that you want to set up for your back end, you have some flexibility. You can have a restful API that you can set up and you can do that also with, with, with AWS Amplify. You can create basically using our CLI utility or using what I talked to you before, that Amplify Gen2 and using something called CDK, this infrastructure's code, you can create an API gateway and then have that API gateway connect to, let's say, a Lambda function. And then that Lambda function then can talk to any sort of backend database that we support. So we have SQL, NoSQL, Aurora, anything you want. DynamoDB is pretty popular. If you want to go the GraphQL route, then we recommend that you use our managed GraphQL service called AppSync, and then that defaults to DynamoDB, but you can connect other databases up to that as well if you need. So that's a few of the options, and you kind of have the flexibility of setting it up. If I was going to recommend something to someone who's listening right now, kind of want to give my AWS Amplify a spin, first obviously create your AWS account. There's a pretty hefty free tier. You can get hundreds and hundreds of hours. And even most of the services I'm talking about right now are on demand. So you only get charged when you use hundreds of hours or have thousands of users. So usually the free tiers are pretty wide. But I would recommend to use the AppSync service. And what's really nice about it is if you're familiar with GraphQL, you have to create resolvers. You have to kind of connect, do all this connective tissue between the the queries that are coming in and connecting them up to your backend and then adding if you have often that's like another layer of complexity that you have to deal with. Well, what we have in the app sync, we have this model schema where you just put whatever the data, whatever the data is dot model and then we'll create all those resolvers for you to do all the common things you would need to do with a graph QL service like create, read, update and delete. And it kind of does that all for you. And of course, if you need to kind of get into those internals and change those, there's ways of overriding it, use arrays of creating your own custom resolvers. But for most people, if you just want to kind of play around, that's all there for you. So that's how I would start. I would obviously first make sure you have an AWS account and have that up and running. You'll need a credit card to start an AWS account. And then try out some AWS Amplify and use perhaps our Gen 2 product, and then create your backend using AppSync. Does that make sense? I know that's a lot there. 

STEVE_EDWARDS: Yeah, it's a lot. So how about if I got something simple? You mentioned Astro, right? And so Astro is a well, and it's a tool that I've used and I really enjoy. I've used when I worked on a static site. So it's one of those things that started out as a static static generator and seems to be growing a little more. The whole idea with Astro is that you're getting rendered HTML, but if you want to add islands of what's the term I'm looking for, things you want to do, productivity islands of code, islands of, anyway, islands. You can use a view component or react component or a spelt component or a react component or something like that and drop it just in a certain region of your page. Now it has, I know it handles server-side rendering and it's handling more and more. It's been a while since I've talked to Fred Schott about what's going on with Astro. So that's a simple case, right? Maybe where you're using markdown files for your content or you could do something a little more complex. And here's a question for you. One of the ways I have used Astro in the past is with a third party CMS, have the CMS such as Prismic Uh, is that something you can use and not encourage? You know, you'd rather you host on an Amazon type of CMS if that's even available or are those possibilities as well? 

ERIK_HANCHETT: Yeah, you bet. So like I mentioned earlier, whenever are more popular as a service and you don't, you don't have to buy in the whole ecosystem. If I'm talking right now and you're like, well, I don't need an API gateway. I don't want to connect to a database. You can kind of pick and choose what you want. And, and you don't have to know how to create all this infrastructure for you. So with our Amplify hosting service, our managed hosting, you can connect it directly up to your version control system or Git or GitLab, whatever you're using. And then you can push it up directly to there. And for Astro in particular, we can do it two different ways. We can do it as a static site. So you can post it as a static site during the build process, if you have it connected to Prisma it could probably pull all that stuff in, kind of like a headless CMS, like you're talking about, and then you can just host it on the Amplify hosting. Or we do have something that I've actually was just testing out last week, a community-led driven plugin to allow you to do server-side rendering on Amplify hosting was made available recently. So I'm still testing it out. It seems to work well, what we did for Amplify Hosting, we have most of our customers, a lot of our customers use Next 14, Next 13. We have that, kind of automatically detects it. So if you have Next 14 and you want to do static site or server-side rendering, it will automatically detect it. Everything will work great. If you want to use a different service, like let's say Astro or Nuxt, then we have community-led plugins that you include inside your source code. And then it'll be picked up by our hosting, Amplify hosting, and then it'll configure it so you can use server-side rendering and have those API routes work. So there's one for Astro, and then there's also, yeah, integrations, I think it's up there. I haven't looked, checked that website, you just put up there. But there's also, we partnered with the Nux community, and we were just talking before the show started with Daniel Rowe. He's an amazing contributor to the Nux ecosystem, and we partnered with him and the guys at at Nuxt and they created an adapter for us for Amplify Hosting as well. So now you can use Amplify Hosting with server-side rendering without any problems. So, yep, so that's definitely a use case and you can certainly connect it to other services outside of AWS. We don't have any... It makes more sense when you connect it. Like if you're going to have a bunch of infrastructure, kind of having one place to have it all in one place is nice. But you can't have it in multiple places. 

STEVE_EDWARDS: There's a few adapters for AWS listed here. There's looks like some of them are, I don't know, duplicates or do the same. There's deployed Astro to AWS Amplify, and there's the Astro adapter of AWS serverless. Let's see here.

ERIK_HANCHETT: Yeah, the one that says A to be Astro dash AWS dash amplify is the one I just tested last week and that one worked right.

STEVE_EDWARDS: All right. Okay. Okay. That links to the GitHub repo.

ERIK_HANCHETT: Cool. 

SETVE: Yeah. Yeah. It's nice when you can just say, yeah, here I'm going to use this host, drop this in rock and roll. 

ERIK_HANCHETT: Yeah. That's one thing that I've noticed too. And is I see these people, not these people, I see many different software developers out there posting on Twitter X about their stacks. And I always see like, I'm using expert authentication and I'm using this service for my backend. Let's say our monitoring and I'm using this service for our database. And I'm using, they have like, I'm just imagine when you're doing this, you have like 10 different services, you have 10 different, uh, bills coming in every month and maybe you're in the free tier in this one, but you've gone over on this one, uh, and I just think it like, just adds a bunch of complexity and, and I'm, I'm all for like finding the best, the best service for your needs. But I also see there is a niceness to having like one over arching company or service that handles multiple these things and they all kind of integrate well together. So that could be a, a reason why you may want to look at a service like Amplify where you can have, it does multiple things and not just like one part of this bigger puzzle that you need. 

STEVE_EDWARDS: To quote Lord of the Rings. So one service to rule them all and in the darkness, bind them. 

ERIK_HANCHETT: Yes. But you don't, you don't have to, you can always pick and choose what you want.

STEVE_EDWARDS: So one of the things that you mentioned, and this has a separate page under the Gen 2, I'm not sure if it's available here, it has to do with authentication. So just to clarify, there's a difference between authentication and authorization, right? So this is just handling the authentication saying, okay, I'm gonna let you log in and you're who you say you are, right? When it comes, it's not gonna go so far as to allow you to define roles and permissions. In other words, 

ERIK_HANCHETT: I know you can do both. 

STEVE_EDWARDS: What is the extent of that? 

ERIK_HANCHETT: Yeah, you can do authentication and authorization. So you could set up special groups. You can add people to groups. It's pretty powerful. So Gentoo, just to recap what I said 10 minutes ago, is our new developer preview product that combines like infrastructure as code. So you can write your back-ending code in a very straightforward way. We wrote it in such a way that just with a few lines of code, pop up your whole identity provider, create your whole backend, GraphQL, AppSync service together and then you can drop down to CDK for other things. And we're also, before our, it goes for what we call GA, our general availability, we're looking to add even more functionality to it so you can easily add in functions and several other things. But a part of that is this thing called Auth, and then inside Auth, we that's backed up by our identity provider and Amazon system that's Cognito. And then from there you can, uh, you can do a whole bunch of things. You can add like multifactor authentication. You can add identity providers. You can add multiple identity providers, but, uh, when you're looking, when you think about authorization, authentication, you can go into our schemas and then you can tell it like, have this, have this table only have users from this group have access to it. You can do that kind of low-level, field-level customization of each thing that you send out. You can also- 

STEVE_EDWARDS: That's very low level, the table level. 

ERIK_HANCHETT: Yep, you can even do the field level too, which is really neat. So if you wanted to only have this field, have this group be able to update it, you can. Or we can do owner-based authorization. So let's say you have a table that's gets created every time a user creates a new account. So you want that, only that user can update their email address. But you'd wanna also wanna make sure that no other person in your system can update that. And you can make rules like that, or you can have an admin account that can update everything. So yeah, we do have those fine-grained authorization rules that you can add in, which is awesome. It gets quite complicated too. Like I've seen some of them where it's like, you can even drop down to create your own custom authorization rules. So that way if you're, we have these things called directives that these little at symbols and you can add it to anything. Well, in our new gen two, it's more of this dot notation. We can do dot authorization. You can add a bunch of things, but if you need it to, you can create your own custom resolver that only certain, and then you can dive into the code and do it that way as well. 

STEVE_EDWARDS: So is the idea, and I'm going somewhere with this, so is the idea that all of this code that we're talking about using and writing for authentication, authorization, and schemas and all this stuff, this is all written in JavaScript on your front end as compared, and AWS is basically your backend and you're just deploying there. Is that right or what am I missing? 

ERIK_HANCHETT: Yeah, so yeah. You got the right idea. So what we do with this gen two product, it's all in TypeScript is kind of our default. We do support other languages, but for now we're focusing on TypeScript and you would write the infrastructure as code. And then what we have things are called after you write it, that is, then you can run a couple of commands on the command line and it gets deployed into what we call an ephemeral environment. So when the background, it'll take that TypeScript code and it converts it to something called cloud formation which is read into by AWS. And then there's even a cloud formation console that you can see how what it's doing. And then it provisions and creates this whole backend for you. And then you can test locally for this ephemeral environment. And what's nice about it is every single, you can set up and spin up an ephemeral environment for every single user that's using this, for every single developer that's using this app. So let's say you have five developers. Everybody can download the Git repo. Everybody can spin up their own ephemeral environment and test locally against that environment. You can also share resources, share other things if you need to. There's a lot of different scenarios. And then you can kill those environments or stop those environments. And then once you're ready for production, you connect it to our hosting or console, we call it a console or hosting console. And then you can push it all up to that console and then we'll create the will create the production environments and those will be tied back into your get branches. So usually you have one for like develop or main, then those can be different production branches that you have.

STEVE_EDWARDS: Okay. So, well, yeah, so that's where it goes to where I was going. I'm still a little hazy on the ephemeral stuff. Basically is, is, is it basically, uh, an environment that has your assigned roles and permissions and access to Zal that you can run locally against the services on AWS? 

ERIK_HANCHETT: Yeah. So when you, let's, let's imagine a scenario here, maybe this would be easier. So let's say you are in a two person team or two developers creating the next Instagram. And you decided to use AWS Amplify. And you run a couple of commands in the command line and it puts in, it generates these files in your system. And they're in the same folder as your Next app. So your Next is gonna be your front-end app. And from there, you add in, you go into those files and you add in all, basically in TypeScript, you add in, the different tables, the different authorization rules, whatever kind of schema in the backend you want to look like. You can maybe add in your identity provider and all those rules there. Maybe you want multifactor authentication. And then you push up to your, let's say your GitHub version control system. And now the other developer, you both pull down the same repo, has the same information. You can both run a command on your command line that says, NPX Amplify Sandbox. And then all of a sudden, it'll create a brand new environment with all defaults, no data in it, but with those rules and everything you added. And each user, developer one and developer two, can just spin up this ephemeral environment and they can then put some seed data in it. You can then start testing locally against it and trying it out. Now at some point, let's say both developers have been developing, they've made some changes to the backend, they're both in sync, they played around the firewall environments, they tested locally, it looks fine. They can then stop their firewall environments or keep them running, doesn't matter. And then they can push to a specific branch that's connected to our Amplify console. And then that will then push to production. And then you'll have a production environment that'll take that same spec that you had in those ephemeral environments, and it'll create that for like a production environment tied to that branch. And then from there, they could, you could, users can start using it in production.

STEVE_EDWARDS: Okay, so raise up a couple of questions. One, so when you're developing, let's say we're using, you know, MySQL as my database of choice for the given project. And you're talking about how I can see data and so on. Is that database residing physically on my local? Can I point it there so I have access to there or is it always residing on AWS infrastructure and that's where I have to access it? 

ERIK_HANCHETT: Yes, so that's a good question. So when I say in formal environments, these are actual environments running on AWS in the cloud. They're not on your local computer. They're in the cloud. They're really running there. And so yeah, you would then have to see that data in the cloud. We're looking at that too. That's a big use case. We've heard back from our customers is that when they want to use this, especially if they have like six developers, they don't want to have to like see the data every time they stop and restart their formal environment. So we're looking at ways you can share data better that way. But no, yes, you would, those would be in the cloud. It's nothing local. So one thing we heard back in our previous versions of amplify is that people, we had tools to like do mock servers and mock DynamoDB servers. And you can download that too. If you just Google around DynamoDB local, you can download like a local version of DynamoDB and you can connect it up to do testing. But we heard it was kind of difficult for people to test their Lambda functions, to test their DynamoDB and GraphQL. And so one way to ensure that that's not an issue is to actually just create those environments, these environmental environments, so you actually are using the backend. 

STEVE_EDWARDS: So it sounds like a sort of a virtual machine type of environment? 

ERIK_HANCHETT: No, it's real cloud environment. Exactly. The only thing is that we designated it as an environment that can just be stopped at any time or destroyed at any time. But this is really like cloud data. It's not in some sort of VM or anything like that. So if the developer wants to test things out, they know that it's pretty close to what's going to be in production, because it's just we spun up all those provisions. So you're getting a brand new serverless, a brand new AppSync app, Cognito and whatever other services that you have in there. 

Time is of the essence when it comes to identifying and resolving issues in your software. And our friends at RayGun are here to help. With RayGun alerting, get customized error, crash, and performance alert notifications sent directly to your preferred channel with integrations including Microsoft Teams and Slack. Set thresholds on your alert based on an increase in error count, a spike in load time, or new issues introduced in the latest deployment, along with custom filters that give you even greater control. Assign multiple users to notify the right team members with alerts linked directly to the issue in Raygun, taking you to the root cause faster. Never miss a runaway error. Make sure you're quickly notified of the errors, crashes, and front-end performance issues that matter the most to you and your team. Try Raygun alerting today and create a world-class issue resolution workflow that gives you and your customers peace of mind. Visit raygun.com to learn more and start your 14-day free trial today. That's raygun.com.

STEVE_EDWARDS: So does this mean you basically, you can have, you talked about the deployment to prod, but you can, if you have your different branches, like, you know, if you're using a Git flow type of workflow, where you have main and then develop, and then you've got your feature branches, and when they're done, they go PR and to develop, and then the main and so on. But when you're in your feature branch, are you saying you can spin up environment and NWS to just test your code and have it like, here, go look, this is what my code's doing. You know, go to this URL and you can see it. Is that how that can work.

ERIK_HANCHETT: So there's a couple of things there. So let's continue on with this analogy. So you're like these two developers doing this Instagram, and then there's a special new feature in Instagram. Like, I don't know, it's a sepia-tone Instagram feature that you wanna do. So the developers, they create a new branch called sepia, and then they can still test locally. They can still create the ephemeral environments and test everything locally. Um, they wouldn't be able, when I, when you'd create the ephemeral environments, it's not creating like a hosting. It's not creating like a website or anything. It's just like provisioning some things locally that you can test. So when you run local host, then it connects to those backend services. It's not creating like a hosting provider, but now let's say they tested locally, they're running local hosts, they're running against this ephemeral environment. Everything's working great. They've destroyed their ephemeral environment. Now they're ready to go to push this feature to a feature branch, and they want to have a small group of beta users tested. Then they run this command on the command line that pushes it to that branch. Well, first, they basically they connect up that branch up to the AWS Amplify console. And you can tell the console, anytime you get a new merge request into this branch, rebuild the website. So then when they push to that new feature branch, it's going to build the whole website and then deploy it into this special environment that you can then have. You can attach a URL to it. You can be like beta or you can just have it. You don't even have to put a domain name if you want. And then you can have a small amount of people test it on that feature branch. And then at some point, maybe you don't need that feature branch anymore delete it and then that feature branch will be gone. That website will be gone. You can continue on your workflow. Or maybe you merge that feature branch into your main branch, which then goes to your main domain, which is www.

STEVE_EDWARDS: Okay. So yeah, that's something I've used quite a bit when I was working at, you know, much larger places where, you know, where there was Pantheon as the example I'm thinking before, where you you got your branch of spin up environment. Yep. Looks good. Okay. Now we can merge it in and, and do everything. 

ERIK_HANCHETT: Yeah. The Gitwork flu is so popular. That's exactly what I did at that insurance technology company. I was before we had like four environments. We had one for QA. We had one for our like dev environment. We had a production environment. I think we even had like a second QA, no, a pre-prod environment. So we had four. So when we did our, when the SureTech company, the way we did it is we would push to, once, and we did this all AWS infrastructure back then too, we would create a feature, then it would like go into the QA branch and that would have its own whole and servers and everything that was running against. And then if that worked well, we would promote it up to our... Well, first it would go in the dev. And if that worked well, we were ready, we'd send it to the QA, and then QA would go to pre-prod. And that's where like a bunch of stakeholders would get involved, like maybe our PMs or VPs. And then that would go into prod afterwards. So you could have that same type of workflow using Amplify Gen 2. You can create all four of those environments to all four of those branches. And instead of having to like do have a DevOps guy to have to create all that infrastructure and create all this work, like it's all built, that whole workflow is built in to Gen2. 

STEVE_EDWARDS: So from a code standpoint, when you're developing, let's say I'm doing a view front end for, you know, whether it's inertia or whether it's, you know, whatever. How much am I working on my local and pushing and how much is not? So I'm assuming my whole view structure and my pages and view files and all that stuff is local. And that's what I'm committing to get, which is getting pushed and then deployed to AWS. But all my backend stuff, my database, obviously any Lambda functions without saying, and other stuff is all on AWS and somewhere I've got some sort of connection strings or environment variables or something that are pointing to the different URLs for the different services, right?

ERIK_HANCHETT: Yep. Yeah. Yeah. So when you spin up the ephemeral environment, it creates like this file, JSON file with all your configuration strings in it. And your front end reads that. And it's an, the Amplify front end library reads it and like, oh, this is where my serverless function is. This is where the gateway is. This is where everything else is. Yep. You're right. Exactly. 

STEVE_EDWARDS: Okay. So obviously the benefit of something like this is that it's somewhat portable. Right. So if I got a new computer, you know, my laptop goes up in smoke as I thought mine was going to do a couple of weeks ago. Um, then it's just a matter of cloning my local repo that has the front-end code in it, firing it up. And as long as I have internet connection, I can connect to all my backend without having to, you know, reinstall my SQL and reinstall node. Well, I might need node and stuff like that. Right. 

ERIK_HANCHETT: Yeah. You wouldn't have to like, I know a really popular thing, especially a lot of DevOps guys like to bring up a Docker container or Kubernetes locally. You don't have to do any of that. It's just push, you just pull everything down, run a couple of commands, and then you can push everything back to the cloud to have your little local environment to test in. That's pretty straightforward. One thing you could do to your example is, if you are using AWS, you do have to, if you have a brand new computer, there's some connection strings to AWS. There's some secret keys. You'd have to pull those back into your environment and there's a few ways of doing that. There's a CLI way, but it creates like these doc doc, uh, AWS folder and it adds these keys in. So that way, when you run command line, you command line utilities, CLI utilities, that command line interfaces that they'll just connect correctly to your backend to the AWS accounts. So you might have to do that. SSH type connection or they are, no, they're like different. So there's, with AWS Amplify, we have, it's an npm command that you can run, npx, well, the first time you're creating it, you run npm create amplify at latest, and then it will create the infrastructure for you. And then when you first run npm amplify sandbox, which will create the sandbox and firmware environment for you that will look at those keys that are in your root folder. And it'll look for them on your file system or look for these variables in your account. And then it uses the API to do some kind of credential swapping in the background. And it's not, I don't think it's SSH, but I think it has the general idea of doing public and private keys, but I haven't looked into exactly how it does it. 

STEVE_EDWARDS: Okay. Now, one thing you mentioned earlier when we were talking about the code that you're using for the infrastructure is that it's TypeScript. So if you're somebody like me who has not completely drunk the TypeScript Kool-Aid, is that something that's something I would need to get up to speed on in order to use the code as infrastructure? 

ERIK_HANCHETT: Yes. So let me caveat that by saying we are focusing on TypeScript first for this developer preview. However, in the future, we are looking at other languages for people who aren't TypeScript people. If you do go, if you are looking for something that's other than TypeScript, now this isn't AWS Amplify, but I mentioned earlier, something called cloud development kit. It's called AWS CDK. It's kind of the acronym for it. Now that will work with more than TypeScript. So it has, most people use TypeScript, but you can use Java. You can use, Python, you can use a whole bunch of other framework, libraries, frameworks, programming languages to use it with. So you don't have to know TypeScript for that case. So if you want to do CDK, now the difference between CDK and what I'm talking about with the Amplify Gen 2, CDK is much more, it's very powerful, but it is a lot more Terse, I don't know, it's very specific. It has a very specific language. It has a little bit higher of a learning curve. It's very powerful. But what we did with Gen2 is we kind of added another, what we call a construct on top of it, kind of like another layer of abstraction that made it much more straightforward to use rather than having to learn all these little commands. And there's even a lower level than CDK, which is CloudFormation, which is, I would say, very powerful, but you would really have to learn all the different nuances of cloud formation to use it. And those are all infrastructure as tool codes. Infrastructure as code tools. 

STEVE_EDWARDS: There you go. Okay. Right. Okay, before we move on, anything else from a backend infrastructure standpoint that I want to talk about? 

ERIK_HANCHETT: No, I think you covered most of it. Hopefully, that was useful for people listening at home to kind of get an idea of how it's working. I think that's one, that's a big part of the Amplify Gen 2 product. The other half is our end-to-end type safety, which kind of takes the types from the back end and has them available in the front end. You may have heard of other products like TRPC for those in the next ecosystem. You may have heard of it. So we have similar things like that where you can create a back end and have the types available in the front end. So that way you never receive something you don't expect or send something you don't expect. So it's all typed correctly. That's a pretty powerful use case as well. 

STEVE_EDWARDS: All right. Now one other tool that we talked about and we've talked about, you and I have talked about on some of the views on view podcast was some of the component library stuff. 

ERIK_HANCHETT: Yeah. 

STEVE_EDWARDS: That you had worked on. In particular, I remember we talked about the view ones, obviously. Can you talk a little bit about those and what they do? I know we talked about authentication and stuff, aren't there also stuff for simple forms, options, and things like that when creating view that tie into AWS or what's the extent of those? 

ERIK_HANCHETT: Yeah, so if you go to, and I will bring it up as I talk to you, ui.d We have this full component library, and there's really two parts to it. Well, first, the component library that we have, we support a lot of different types of frameworks. We have Android, Angular, Flutter, React, React Native, Swift, and Vue. For a full component library, we have it for React. And so what I mean by that is we have all sorts of things like dividers, headings, icons, alerts, loaders, messages, placeholders, links, buttons. You can't have a UI component framework without a button, I should say. That's pretty much standing. We also have a complete theming system, so you can theme it. But I think when people ask us, why should I use this over Shad CDN or Shad CN or in the Vue ecosystem like Vue.Fi or Tailwind Prime Vue, which is a pretty cool UI framework, is that we have what are called connected components. So these connected components, there's really four or five of them that we have now. One is the authenticator. And this authenticator is available not just for React, but you can get it for Vue, Angular. That's kind of like our biggest use case for this UI component framework. And what that allows you to do is just with a few lines of code, you can add in the few lines of boilerplate code. You can add in this kind of almost like a widget, this, this piece of code, this, this authenticator, which is a way you can use, you can use to log in, log out, sign up, sign in. It has it built into our AWS services, our cognitive service. You can do social sign-ins, Facebook logins, Amazon logins. And it's just a few lines of code to add all that in there. And that's what a lot of people use because to create a full authentication system for your website, it's a lot of work to add in that login page. Have you done that before, Steve? 

STEVE_EDWARDS: No, I've, uh, no, I've heard horror stories about it. Uh, I've like, do you use stuff like, uh, Laravel that handles all that for me on my backend. So I do, yeah, I don't want to create an authentication system from scratch.

ERIK_HANCHETT: Exactly. And there's two pieces of it. It's like writing the back-end part of it and using something like Laravel. And then a lot of people use Passport.js or NextAuth or something like that. And you kind of have to write all that code yourself. And so that's one big part of it. And then the other part of it is like, oh, let's add a login page or forget your password page, a signup page. How do we redirect once we're signed in? How do we do a lot of things? So that's kind of our biggest, one of our bigger use cases is this authenticator. And we have a lot of ways to customize it too. So if you don't like the way it looks, you can completely change the look and feel of it. You can use our theme system to change it. And then the other connected component that we have, and this is for React only, but in the future we are looking to add it for like Vue and Angular and other frameworks is our account settings. And what this does, you can add like the change password and delete user. So you add this little snippet of code and then you get this box on the screen, uh, that anybody you can use to change their password after they're logged in. Oh, delete users, the same thing. Maybe have an admin user that needs to delete everybody. You instead of having to write all this code, you can just add this component onto your page. And I should say component better than widget. People, when I say widget, people think of like old school applets or something. No, no, I'm talking about like essentially a component.

STEVE_EDWARDS: That's a great, that brings back some memories. 

ERIK_HANCHETT: Yep. Uh, it basically a component that's written in the framework. So that it has all the idioms of that framework. For example, in view you have templates and you have slots, but in react, we have different types of props. Um, and we have children. So we try to use the kind of what you know and love from that framework when, with these components that you can pull in. I can go through a few others. We have FaceLiveness, which is our Amplify UI FaceLiveness detector, which uses in the backend our Amazon recognition FaceLiveness service to help determine if a user is real or not. So there's some specific applications where people might use this. We also have Geo, which is a way to add like maps onto your app, kind of like Google Maps, where you can do all sorts of mapping fun. And then storage, which is probably our second most popular component, connected component, which allows you to do like S3 uploads. It's like a file uploader. So you can upload files. 

STEVE_EDWARDS: Like a drag and drop type of UI type thing? 

ERIK_HANCHETT: Yep, you can drag and drop files directly to public, private or protected S3 buckets. And we have a nice interface for that. And then we have a storage image, which connects to S3 to show images on your page. And then we have one last one, it's called in-app messaging, which allows you to do in-app messages in your app. So that's a lot there. So we've been continuously adding more and more features to our UI component framework library. 

STEVE_EDWARDS: So are these things that I could use piecemeal as well? You know, if I have a large view app that I'm already using and I hook it up to AWS and I wanna be able to stash images in an S3 bucket. Is that something I can use by itself or does it have to be used in the context of of a larger framework? 

ERIK_HANCHETT: Yeah, you can certainly you would have to obviously have an AWS account you would have to set up amplify But yeah after you did those two things. You can then just use that one piece of it. You can just do the file upload. You can use the file You can use our storage manager or file uploader and start uploading files directly to S3. Yeah And that's... And I don't know if I finished this point, but what I was trying to say is that that's one of the reasons you may want to consider using something like AWS Amplify is the UI component framework part, is that we have these connected components that kind of take away all that time it takes to write all the connecting code to all these AWS services, and we do that all for you. And then we have a nice, very customizable, themeable component that you can add to your project.

STEVE_EDWARDS: So the theme ability stuff that, you know, if I have a component, obviously I'm probably not gonna wanna use it off the shelf or maybe you're like me and you're lazy and you do. So you're gonna wanna tweak it to, you know, to fit your brand or your look, your theme for your particular application. What's the framework that you're using for that? Is that like a custom AWS type of framework or is there something like a tailwind or bootstrap or how does that work?

ERIK_HANCHETT: We have, so with our theming, so any of these connected components we were just talking about, it's Authentic, in-air, and app messages, or even if you're just using buttons or whatever from this component library, it's all connected to our theming and you can create what's something called a theme provider. And this is all built by us. We're not using Tailwind or anything like that, but it's kind of, it's based on several design principles that are pretty common in frameworks like design tokens and we use breakpoints and overrides. So everything in your app is essentially, all the themes in your app are design tokens that you can override at any time. And you can make multiple different themes and then you can change the colors, the typography, sizes. You can have different responsive layouts. So you can have it built into the components that when it hits a certain screen size, it automatically changes. Of course we have dark mode because you can't have a UI component framework without a button in dark mode. We have that as well. And then you can... everything kind of boils down to CSS variables. So you can change... if you didn't want to use the theming itself, you can override the CSS variables and change them to whatever you want. And that includes all the colors, disabled colors, the primary colors, everything like that. Or you can use design tokens. 

STEVE_EDWARDS: So is using like atomic classes, you know, that whole tailwind, I think one of the ones that started it where you have one class does one thing as compared to one class that does 20 different things.

ERIK_HANCHETT: I would say not in the traditional sense that you're thinking of, like in Tailwind with the atomic classes, it's more along the lines of a traditional kind of app where you have multiple different variables that make up one thing. No, it's not like that now. 

STEVE_EDWARDS: Okay. All right. Awesome. That's a lot of stuff to talk about anything regarding Amplify and JavaScript that we missed. So you want to cover? 

ERIK_HANCHETT: No, I think that covers most of it. I would highly recommend if you're listening, yeah, check it out. This isn't sponsored or anything. It sounds like it's kind of sponsored, but it's not. No, I just, Steve is having me on and he's talking about fun technology. But yeah, no, I really think that AWS Amplify is a great product. Hopefully more people can check it out. 

STEVE_EDWARDS: The correct industry term, I think, is called one dig bong shameless plug. But obviously this is a well battle tested infrastructure. You know, at AWS they've been around for a long time. So, yeah, make it easier to build your app on top of their provided services. That's a win for a developer for sure. 

ERIK_HANCHETT: Yep. 

STEVE_EDWARDS: And so before we wrap up, let's talk about your work as a dev role. We mentioned you initially were started as a developer and then moved into the developer relations role. So besides coming on the best podcasts out there like this one, what are the other things that you do in your day-to-day? 

ERIK_HANCHETT: It's more like what I don't do. Developer advocacy is a, it's, it's an emerging field. Well, essentially what we're trying to do is connect with developers. We're not, I mentioned, I joked about being a salesperson. I'm not trying to be a salesperson more. What I'm more interested in is just trying to get more people to try the product out, to check it out, to give me feedback, to listen to it. We're not marketing people. Uh, and so a lot of my job is to create content. Like I create blog posts and videos, come on podcasts like this. I do a fair bit of community stuff. I can be a part of a community. I'll come and talk to them. Actually, in two weeks, I'm gonna be at AWS Sacramento, which I'm really looking forward to, to do a workshop on something we just talked about today, this Amplify Gen 2. So it's a lot of creating content. It's a lot about connecting with people. Part of my time too now is going to conferences. So I've, last year I went to 11, I think it was like 10 or 11 different conferences all around the US, all around US and Canada. I didn't go Europe, but maybe this year I'll go to Europe. And so I got to talk to a ton of people and just, and find out like what the developer community's doing, what's working, what's not, what are they excited about some of my jobs posting on Twitter and just reading other people's tweets, posting on any service that people talk about, software development. I've been trying out TikTok lately. I feel like I'm too old for TikTok, but I'm on there. And it's funny, there is some, it's funny, there is some dev developer influencers on TikTok that like dance and they talk about AWS services. It's really, it's a really fun place. So I'm trying to, it's a lot of different things you can do, but it's a lot about getting awareness out there. It's a lot about talking about products and talking to developers. And so I love it. I did before I was a software, before I was doing more developer advocacy role, do a developer advocacy work, I was a front-end engineer and I did backend engineering, but I always like created YouTube videos and created content. And I found that I just really liked doing that. It was just kind of a weird thing. It's kind of like the fun of like teaching someone, teaching someone, you don't even have me next, we're just teaching just a little bit more than the next person of what you found out. And then having people respond back to you, talk to you, it's just such a fun feeling to do that. And something I really love and I really like doing. So I think this job kind of fit really well into that because I had been doing some sort of developer reach, either going to conferences, creating YouTube videos, writing books for years now. And so this kind of all fit into place.

STEVE_EDWARDS: Awesome. Yeah, that would be fun. The upsides and downsides to that, I think, you know, you and I have talked before on views on view regarding conferences and how awesome conferences can be just in terms of, and yes, I'm gonna get to view comp. I will at some point, I promise. But just how you can meet people and put names to faces and, you know, the hallway track and all that kind of stuff. The downsides that I've heard from some people is just a crazy amount of travel. I mean, at some point, travel's got to get a little wearying, I would imagine. 

ERIK_HANCHETT: Yeah, you're right. It is quite a bit of travel. I try to put some guardrails for my travel. I try not to travel on the weekends, although I am traveling the weekends in a month from now, but most of the time I don't travel on the weekends. I try to be home by home by Friday by 5 PM so I can be with my family and I have two kids. So I tried not to do that. And I also try not to travel more than like once or twice, uh, every couple of months, few months. Uh, it can get to the point though. I heard some developer advocates where they're traveling every single, every single weekend, every single week, or maybe three times a month. I that's, that's too much. Like that's crazy. Yeah. And that, that, that does wear on you. And also just getting out there. I'm more of an introvert in a lot of ways. Took me a long time to get out of my shell, to talk to people, especially being a developer, you kind of, you just sit in front of a computer all day. You don't really act interact too much. That's not true. You do have meetings and you do talk to a lot of people. But for the most part, when you're in your zone, you're by yourself for your computer. And so getting past that too, at the first, it wasn't too much of a struggle because I've been doing videos and stuff for a while, but even some days I'm like, do I want to go out and meet people? It's that those are some of the negative things too. Yeah. And travel certainly can be one of them. 

STEVE_EDWARDS: Yeah, I used to back a long time ago, I used to travel just twice a month. And that was quite a bit. It was nice when you had all the frequent flyer miles and you got the upgrades and the, you know, the Delta medallion, gold medallion stuff, travel lounges and all that, but still travels, travels, travels. 

ERIK_HANCHETT: Yeah. I have talked to other people too, who travel way more for me. And I'm always getting like tips too. Like what's the best credit cards to get where it's the best places to go when you're at X city, when to get to the city, when to leave. There's a lot of travel hacks that I'm learning more and more about. But like I said, I try to eliminate not to have it be all encompassing, because that's no fun. 

STEVE_EDWARDS: Cool. Alrighty. Well, with that, we'll wrap it up and move to pics. Thanks, Eric, for coming on yet again. Talk about AWS. Oh, one quick question before I forget. You said you blog. Where do you blog at?

ERIK_HANCHETT: I used to blog at programwitheric.com. Oh, that's right. So if you go there, you'll find some very old articles. But I am thinking about starting it up again. Well, I recommend everybody though, we'll probably get to this again at the end, but eric.video is just goes directly to my YouTube or Twitter at ericch is like the best way to get a hold of me.

STEVE_EDWARDS: Yeah. All right. Yeah. Program with Eric on YouTube. There's a lot of videos out there. And he has really great thumbnails on his videos too. I'm jealous. If I could do those, I would do more videos. So got to have that. Got to have the, the, uh, thumbnail. 

Hey, this is Charles Maxwood. I just wanted to talk really briefly about the top end devs membership and let you know what we've got coming up this month. So in February, we have a whole bunch of workshops that we're providing to members. You can go sign up at topendevs.com slash sign up. If you do, you're going to get access to our book club. We're reading Docker Deep Dive, and we're gonna be going into Docker and how to use it and things like that. We also have workshops on the following topics, and I'm just gonna dive in and talk about what they are real quick. First, it's how to negotiate a raise. I've talked to a lot of people that they're not necessarily keen on leaving their job, but at the same time, they also want to make more money. And so we're going to talk about the different ways that you can approach talking to your boss or HR or whoever about getting that raise that you want and having it support the lifestyle you want. Uh, that one's going to be on February 7th, February 9th. We're going to have a career freedom mastermind. Basically you show up, you talk about what's holding you back, what you dream about doing in your career, all of that kind of stuff. And then we're going to actually brainstorm together, you and whoever else is there and I, all of us are going to brainstorm on how you can get ahead. The next week on the 14th, we're going to talk about how to grow from junior developer to senior developer, the kinds of things you need to be doing, how to do them, that kind of a thing. On the 16th, we're going to do a Visual Studio or VS Code tips and tricks. On the 21st, we're going to talk about how to build a software course. And on the 23rd, we're going to talk about how to go freelance. And then finally on February 28th, we're going to talk about how to set up a YouTube channel. So those are the meetups that we're going to have along with the book club. And I hope to see you there. That's going to be at topendevice.com slash sign up. 

STEVE_EDWARDS: All right. So with that, we'll move to pics. I'm assuming you remember that Eric can have pics for us. 

ERIK_HANCHETT: I have one. I just thought of. 

STEVE_EDWARDS: Okay. Well, I'll go first and give you time to get that prepped. For those of you that are regular listeners, you know that my dad jokes are the highlight of any podcast episode. But first I have a legit pick that I, well, I take that back. I have a pick that isn't a dad joke, but it's not, that's not to demean my dad jokes. It's a great article I saw on Hacker News. It's called, Why You've Never Been In A Plane Crash, by someone named Kyra Dempsey, who normally blogs about aviation incidents under the name of Admiral Cloudberg. And the article is all about how blame is handled after an aviation incident. And, uh, it's really fascinating and I've seen this before and it makes a lot of sense. Uh, and the article, the given incident that talks about happened at, uh, LAX, Los Angeles international airport in 1991 basically where a 737 was landing and when it landed it completely crushed a commuter plane that was sitting on the runway and I think 19 people died and it was just it was really bad and right away the the cause and this flight controller admitted to it was that she had left the commuter plane there. She forgot that she had told the plane. Yeah stop right here. And then she had another plane Say, yeah, it's okay to land right where that commuter plane was sitting.And so the point of the article talks about how the avi industry when something like that comes you don't You know ntsb doesn't purposely does not have power to file charges or make, you know Manslaughter murder charges or something like that. The whole goal in when it comes to aviation is figuring out why did this happen? And people are going to be more willing to talk and open up and talk about everything that had happened if they don't think they're going to be charged with something. And in this particular, it's quite a long article, but later on down the down the article, it talks that what they figured out there was like six different things in terms of equipment that wasn't working, a custom-built system that was, you know, where they had to find custom parts. Information that was supposed to be made available to her that wasn't available that she had to go searching for um a whole bunch of different things and so as a result of that they were able to uh Figure out what the problems were it addressed them and she this lady the traffic, uh Their traffic control person was offered a chance to come back and chose not to probably because she was so traumatized by this. But just a really interesting article about how when things go wrong how much more you can get when your first inclination isn't to point a finger and say you screwed up, you were wrong, you're going to pay. So again, it's called Why You've Never Been in a Planning Crash by Kyra Dempsey.

ERIK_HANCHETT: I love it. I was going to say, I am a huge fan of, I guess not a huge fan, but I like all those air disaster TV shows, like air disasters on Smithsonian. I think it's called Mayday in Canada. It breaks down like every single flight, every episode is like a different crash and then you hear about the NTSB and the black boxes and how they investigate it. So I'm always interested in that stuff. Very, very, very fascinating why it's so much safer to travel today than it is back know, a hundred years ago or 20 years ago. 

STEVE_EDWARDS: Yeah. And that's part of what this article talks about is because they're not assigning blame and they're just figuring out what went wrong. Let's fix it. Then that tends to make things much safer as compared to just you screwed up and now you're going to, someone's going to clam up and not tell the truth because they don't want to get thrown in jail. You know, 

ERIK_HANCHETT: as someone that now travels a lot more and is constantly on flights. I'm like, thank goodness that people are like that. And that article exists.

STEVE_EDWARDS: Yeah, yeah, for sure. Yeah, this uh, Kyra dempsey, if you look up admiral cloudberg, uh, it does a lot of writing that's real detailed stuff on aviation Incidents and if you read the comments on hacker news, they talk about certain youtube videos Like you said where they go in and just break down all the details. There's one that I've read before Uh, so 1978 when I was pretty young Uh is december 28th of 1978, uh, there was a I forget that model of plane, but was coming into Portland and crashed probably just a couple of miles from my house in a fair in a very heavily suburban area. And the pilot was very good, either good or fortunate or a combination of both and Amanda landed in this wooded area between two-like developments right off a major street here in in Northeast Portland. And actually out farther out towards where I live. And if you read the NTSB report on it, it talks about how basically, I can't remember if he ignored it or wasn't aware that he was low on fuel because he had tried to come into Portland and had to circle for a while. And during circling, he ran out of fuel and realized, uh-oh, I'm out of fuel, got a crash. And so he was managed to bring it in for that. But I can still remember that night and remember the crash and reading about it. It is quite fascinating stuff if you're into like probably like most developers are debugging and figuring out what went wrong and how to avoid it. So excellent. All right, so on to the dad jokes of the week. When I was younger and in school, I went up to my teacher one day and I said, would you punish me for something I didn't do? And my teacher said, no, of course not. I said, okay, I did not do my homework. 

ERIK_HANCHETT: Nice. 

STEVE_EDWARDS: So I had a friend named Jimmy and Jimmy bought an electric car and he was really excited about it. And then he bought an electric blanket and then he bought an electric guitar. Then he bought an electric chair. I hadn't heard from him in a while. I got to give credit to Stephen Wright for that one. He was on a Colbert show, late night show, and told that one. He's been my all time favorite comedian for since the 80s. And then finally, I went to the store the other day and was just getting some milk, which I had to do when we had got hit with ice and there wasn't much left in the stores because everybody was buying them out or their refrigerators had all gone bad. And as I was checking out, the checker asked me, do you want me to put this milk in a bag? I said, no, that's okay, leave it in the jug.

ERIK_HANCHETT: Love it. 

STEVE_EDWARDS: Those are my picks. What do you got, Eric? 

ERIK_HANCHETT: I saw that the Apple Vision Pro was just released. Have you seen this thing, Steve? I have heard about it, I have not seen it. So think of it like VR, the ultimate VR goggle made by Apple. You can, it adds like, when you have it on, it looks like there's like a thousand foot screen in front of you. I mean, as all these features.Like you can navigate simply by using your eyes and hands. You may have seen this little gesture in the commercials. I want to try it out. Like this looks really neat. It is, I think it's around, it's in pre-order. 

STEVE_EDWARDS: It's pretty spendy. It's like two grand, isn't it? 

ERIK_HANCHETT: Yeah. I think it's, yeah, the 256 gigabyte model is $3,499. 

STEVE_EDWARDS: Oh, good Lord. 

ERIK_HANCHETT: You can get the terabyte for almost 4,000. So yeah, it's not cheap, but it looks kind of like the ultimate geek. I want to go on, like we just said, I travel a lot. I want to see, I haven't traveled in a little bit in the last couple of months, but I wonder if I'll start seeing them when I'm traveling on airplanes, where people just like pop them in and be watching movies. That'll be really cool. Maybe if I see someone, I'll ask them to. Can I borrow your $3,500 device to try it out for a few minutes? I don't know if that'll work. 

STEVE_EDWARDS: Well, you work for Amazon. I got money. They can put you up one, right? As a dev rel, you deserve it. 

ERIK_HANCHETT: I think I saw somewhere... 

STEVE_EDWARDS: Hopefully you don't see somebody reaching out and doing something like that. Like they're playing a game or something like that, smack the person next to them on the plane. I can see that happening. 

ERIK_HANCHETT: I think there is some sort of connection. You can do AWS with the Vision Pro. And maybe with Amplify. I haven't looked into it. I thought I heard that. Anyways. 

STEVE_EDWARDS: So how would that work? I have no idea. Can I take Amplify? 

ERIK_HANCHETT: No idea. Yeah, I think there might be something with Xcode. I just googled it real quickly. And you can maybe create software for the device. 

STEVE_EDWARDS: Oh, really? 

ERIK_HANCHETT: Yeah. So that's my first pick. I'm all for the world where. And you know 50 years from now, we all have our VR headsets and we're just walking around or staying at home and we don't have to go anywhere. We just on our VR sets. 

STEVE_EDWARDS: That's all the time spoken like a true introvert. What can possibly go wrong? No, just kidding. I'm just kidding. No, that sounds dystopian. You ever seen Wally by the way? 

ERIK_HANCHETT: Yeah, that that's where we're going. I guess that's where heading that that's my only pick other than a go go Niners. You know, it's the, as of this recording. They have made it to the Super Bowl and it's going to be tough. Mahomes looks really, really good. Kelsey some fire could go either way, but, uh, I'm going to take it. 

STEVE_EDWARDS: Well, if you saw all the maps, you see all the maps and the memes ahead of the game and it shows, um, map of the U S for instance, it would say, okay, who's voting, who's cheering for San Francisco versus who's cheering for Detroit. And it would be like this little area around San Francisco and then the country's cheering for Detroit. And the same with the Ravens and the Chiefs. I prefer, I personally would have preferred the Lions versus the Ravens. Uh, my team, the Cowboys screwed up again as always. Thanks, Jerry. Um, but, um, but I'm just going to say this Detroit gave you a gift. Be happy with it. 

ERIK_HANCHETT: Yeah. We, we definitely got some good luck there. It's in the second half. Uh, yeah. I would say the whole week leading up to the NFC championship game. It felt like, yeah, even though the 49ers were overdogs, they were kind of the leading favorites. They were leading in Vegas if you looked at the point spread. I think there were seven-point favorites. Yeah. And of course they just barely pull it out. But if, yeah, if you look at the national scene, I think everybody was rooting for the lions because they never been there. It's a Cinderella story. It was amazing. 

STEVE_EDWARDS: Cinderella story. Coming from out of nowhere. It's in the hole. 

ERIK_HANCHETT: We get it done. So now we got the two not as favorite teams, not as popular teams, but hey, I'll take it. 

STEVE_EDWARDS: That was Bill Murray from Caddyshack for those who might not have recognized my impression. Anyway, all right. So with that, we're gonna wrap it up. Thanks for coming, Eric. Always a pleasure to have you here. Any questions, bug him at ericch, ericch with a K, CH, on Twitter, program with ericch, and ericch, what is it, ericch.video? 

ERIK_HANCHETT: Yep. 

STEVE_EDWARDS: All right, and he will answer your questions. Thanks for coming, everybody. Talk to you next time.