Hello everybody, Welcome to another exciting episode of JavaScript Jabber. I am Steve Edwards, the host with the Facebook Radio as you can see, and the voice for being the mind. But I'm still your host today due to last minute time changes, we won't mention why I am here with mister Eric Hanchett of Amazon Aws. You might have hearved Amazon. How are you doing, Eric? Hey, thanks for having me on. I appreciate it, and
thanks for being amazing with the time slot too, I appreciate it. No worries for those of you who might have 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, or at least a book on view back in the days of View two, 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 welcome Eric, Hey, thanks for having me. Steve, Yeah, yeah, I have. I Me and Steve. Steve hosted the thes on View podcast for many years and I got to be a coast for a little bit of that and that was amazing. But I am not here just for View. I'm here for next, React, Angular
Astro. Now I am today, I am every framework, a fan of every framework. 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 forty nine ers 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. Yeah, for sure, I'll take one step back,
just add a little little bit more to that story. I was working at an insurance company more like an insurance insurre tech startup, and I did push a lot for them to use View, but they were dead set on using Angular. They had a Java back end, 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. Think 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 view. 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 deva, server, lists, Lambda, functions, infrastructures, code, Kubernetes, and it's fun to talk to them about Well. Actually, ABS 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 dot Com website, but we actually create tools for front end developers, and so I was a part of a team we called ourselves the Amplifying 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 aw's Amplify, which I to give that
a definition is that's our amplify. Our definition, our kind of motto for ABUS 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 multi
factor 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 it. Bout 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 ADABS in general is just not DevOps and back end only, and that Amazon dot Com website you order stuff for, but that we have amazing
developer tools for everybody. 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, right, Yeah, we
have sane defaults. So let me get a little bit more specifics that have been kind of five hundred miles up right. Now, let's go down a little bit close to the service. So, for example, we have a service called Studio, which is like a drag and drop interface to create your
back end. So let's say you need to add in authentication. You just kind of click a few buttons, ads, authentication, you want to add in a database, and what we recommend is AWS app Sync, which is our managed graft QL 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 thirteen Next fourteen for service side rendering or stat 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 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 LAMB to servers, server list stuff, or for next we do that all for you, so we have like more of a managed service.
And then one new product would we just created and it's in developer preview right now, is something called Atabase amplified Gen two and we have 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 will auto generate a bunch of boilerplate code for you.
Actually it's not even that much a 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 back end for you, so you can get everything for You can add in your identity provider, which is Cognito, you can add in app sync and the schemas. You can also go down to what we call the Cloud Development Kit and then
add any other AWOS 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 back end, 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 graft ql you get some of that,
but it's usually not typescript specific, but this is typeescript specific. You can create an advanced schema for your back end, all your models, and then have that available in your front end. So those are kind of some of the things that that we do at AWS amplify. And thank you for putting the links on the screen too, that's very helpful. I'm all about banners. They so much more fun. Okay, so let's go back and talk about a little of that. So databases. You said, now the
graphic QL is obviously not your database. That's your way you connect to you that's your API, right, So what are the database types that that you support. Obviously there's your your my SQOL and your postcis right. I'm going to guess there's some sort of Mango or document database option or what other options do you have available? 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 AWS amplify. You can create basically using our cli utility or using what I talked to you before that amplify gen two UH and using something called CDK or this infrastructures code, you can create an API gateway and then have that API gateway connect to let's say a LAMB to function, and then that LAMB to function then can
talk to any sort of back end database that we support. So we have SQL, no SQL, Aurora, anything you want. Dynamo dB is pretty popular. If you want to go with the graph ql route, then we recommend that you use our managed graph QIL service called appsync, and then that defaults to Dynamo dB, 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 setting it up. If if I was going to recommend something to someone who's listening right now, kind of want to gives I amplify aw's s amplify a spin first, obviously create your awos account for it's you can 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 you know, hundreds
of hours or have thousands of users. So usually the free tiers are pretty pretty wide, but I would recommend to use the at the Apsinc service. And what's really nice about it is if you're familiar with graph col you have to create resolvers. You have to kind of connect do all this connective tissue between the equeries that are coming in and connect them them up to your back end, and then adding if you have off in that's like another layer of
complexity that you have to deal with. Well, what we have in the Appsinc. 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 the graph ql service like create, read, update, and delete, uh, and it kind of does that all for you. And of course if you need to
kind of into those internals and change those there's ways of overriding it. Used to raise it creating your own custom resolvers, but for most people, if you just want to kind of play around, that's all that's all there for
you. So that that's that's how I would start. I would obviously first make sure you have an awos account and have that up and running you'll need a credit card to start an AWS account and then try out some aablese amplify and use perhaps our gen to product and then create your back end using app sync. Does that make sense? I know that's a lot there. Yeah,
it's a lot. So how about if I got something simple. You mentioned astro right, and so astro is is well, and it's a tool that I've used and I really enjoy I've used when I've worked on a static side So it's one of those things that started out as a static sided generator 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,
guidelands of anyway islands. You can use a view component or React component or spelt component or you know React component or something like that and drop it just in a certain region of your page and now it has I know, it handles service head rendering, and it's handling more and more. It's been a while since I've talked to Fred Shot about what's going on with pastro. So that's a simple case right, maybe where you're using markdown files uh 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, had the CMS such as Prismic. 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? Yeah, you bet so. Like I mentioned earlier, one of our our more popular or service And 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 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 GET or get lab whatever you're using, and then you can push it up directly to there. And for Astro in particular, we can do it to two different ways. We can do it as a static site, so you can post it as a static site in during the bill
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 hosting Amplified Hosting. Or we do have a something that I've actually just testing out last week. A community led driven plug in 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. But what we did for Amplify Hosting, we have most of our customer a lot of our customers use Next fourteen Next thirteen. We have that kind of automatically detects it. So if you have Next fourteen and you want to do staticcite or service 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 Next, then we have community led plugins that you include inside your 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 service side rendering and have those APR routes work. So there's one for Astro, and then there's also yeah, in integrations, I think it's up there. Haven't looked like that website
you just put up there. But there's also we partnered with the Next community and we're just talking before the show started with Daniel Row. He's an amazing contributor to the Next ecosystem and we partnered with him and the guys that at Next and they created an adapter for us for Amplify hosting as well. So now you can use Amplify hosting with service side rendering without any problems. So yeah, 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 kind of connect it, like if you're going to have a bunch of infrastructure, kind of having one place to have it all and one place is nice, but you can't have in multiple places. 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 at astro to AWS amplify, and there's the Astro adapter of a do AWS server lists let's see here, Yeah, the one that says a Astro dash aws dash Amplify is the one I just tested last week and that one worked great, right, Okay, Okay, that leaks to the GitHub repo. Cool. Yeah, Yeah, that's nice one. You can just say, yeah, here, I'm
gonna use this host drop this in rock and roll. 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'm always say, like, I'm using expert authentication,
and I'm using this service for my back end. Let's say, are monitoring, and I'm using this service for our database, and I'm using they have like I'm just imagined, when you're doing this, you have like ten different services, you have ten different bills coming in every month, and maybe you're in the free here in this one, but you've gone over on this one.
And I just think it like just adds a bunch of complexity and and I'm all for like finding the best the best service for your needs, but I also say 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 that could be a reason why you may want to look at service like amplify, where you can have it does multiple things and not just like one part of this bigger puzzle that you need to quote Lord of the Rings, so one service to rule them all and in the darkness behind them. Right, Yes, but you don't. You don't have to. You can always pick and choose what you want. So one of the things that you mentioned in this has a separate page under the GIN too. Yeah, I'm
not sure if it's available here. It has to do with authentication. M So, just to clarify, there's a difference between authentication authorization, right, So this is just handling the authentication saying okay, I'm going to let you log in and you're who you say you are right when it comes. It's not going to go so far as to allow you to define roles and permissions. In other words, Uh, no, you can do that. 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 GEN two, just to recap what I said ten minutes ago, is our new developer preview product that combines like infrastructure as code so you can write your own your back ending code in a very straightforward way. It's it's we. We wrote it in such a way that just a few lines of code, you can pop up your whole identity provider, create your whole back end graph cels absinct 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 available ability, we're looking to add even more functionality to it, so you can easily add in functions and and and several other things. But a part of that is this thing called OFF and then inside OFF we that's backed up by our identity provider and the Amazon system that's cognito. And then from there
you can you can do a whole bunch of things. You can add like multi factor authentication, you can add identity providers, you can add multiple identity providers. But 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 yep, you can. 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 gets created every time a user creates a new account, so you
want that that only that user can update their email address. But you'd want to also want to 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 that those fine grained authorization rules that you can add in, which is 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 out, we have these things called directives. They have these ad symbols and you can add it to anything. Well, in our new Gen two it's more 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. 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 schemes and all this stuff, this is all written in JavaScript on your front end as compared and ADWS is basically you're back in and you're just deploying. There is that writer or what am I missing? Yeah? So yeah, you got the right idea. So what we do with this Gen two product,
it's all in type script is kind of our default. We do support other languages, but for now we're focusing on type script. 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 in the back ground, 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 cloudfirmation console that you can see how what it's doing, and then it provisions and creates this whole back end 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 get 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 our hosting or con 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. Okay, that makes sense, 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 it basically an environment that has your assigned roles and permissions and accesses all that you can run locally against the services on AWS. Yeah, so when you let's let's imagine
this scenario. 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 you decided to use a w S amplify, and you run a couple of commands in the command line and it puts in it. It create generates these files in your system, and they're in the same folders your next apps. Your next is going to 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 back end you want to look like. You can maybe add in your identity provider and all those rules there. Maybe you want multi factor authentication. And then you and then you push up to your let's say your GitHub version control system. And now you you the other developer, you both
pull down the same repo has the same information. You can both run a command and 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, you 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 back end, they're both in sync, They've played around the phermeral environments. They they tested locally, it looks fine. They can then stop their in phariremeral 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 have that'll take that same spec that you had in the UH in those ephemeral environments, and they'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. Okay, So brings
up a couple questions. One, So when you're developing, let's say we're using you know, my SQL 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 and it's tructure and that's where I have to access it. Yes, So that's a good good question. So when I say in pharmal 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 did their 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 seed the data every time they stop and restart
their pharmeral environment. So we're looking at ways so 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 Dynamo dB service and you can download that too if you just Google around Dynamo dB local. You can download like a local version of Dynamo dB
and you can connect it up to do testing. But we heard it is like it was kind of difficult for people like to test their land to functions to test their Dynamo dB and graphic QL, And so one way to ensure that there's that's not an issue is to actually just create those environments, these environmental environments, so you actually are using the back end. So it sounds like a sort of a virtual machine type of environment, No, it's it's
real like cloud environment exactly. The only thing is is that we designated like 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 testings 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 can get a brand new server list, a brand new app, Sync app, and brand new Cognito
and whatever other services that you have in there. So does this mean you basically you can have you talked about the deployment to praude. But you can if you have your different branches, like you know, if you're using a Gifflow type of workflow where you have main and then develop and then you've got your future branches and when they're done they go pr and to develop and then
domain 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? So there's there's a couple of things there. So let's
say let's let's 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 and Instagram like I don't know, it's a Sepia tone Instagram feature that you want to do. So the developers they create a new branch called Sepia and then they can still test locally. They can still create them ephemeral environments and test everything locally. They wouldn't be able when I when you create the efemeral 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 back end services. It's not creating like a hosting provider. But now let's say they tested locally, they're running local host, they're running gainst this inphermeral environment. Everything's working great. They
destroy their epedmeral environment. Now they're ready to go to push this feature to a feature branch, and they want to like a small group of beta users tested. Then then they run this command of the command line that pushes it to that branch. Well that well, first they basically they connect up that branch up to the AWOS amplify console and well you can tell that. You can tell the console like anytime you get a new merger request into this branch,
rebuild the website. So then when they push to that new feature branch, it's going to create a new it's going to build the whole website and then deploy it into this special environment that you can then have. You can attach URL to it. You could be like beta Dotminu, Instagram dot com,
or you can just have it we give. 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 future branch, and then at some point, maybe you don't need that feature branch anymore, you can delete it and then that future branch will be go on, that website will be gone and 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
dot mynew Instagram dot com. 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 got your branch a spin up environment. Yeah, it looks good, Okay, now we can merge it in and do everything. Yeah, the good workflow is so popular. That's exactly what I did at that insurance technology
company. Else 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 in this sure tech company, the way we did is we push to once we this is all aw's 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 of going 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 woul 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 amplified Gen two, you can create all four of those environments to all for those branches and instead of having to like do have a DevOps guide to have to create all that infrastructure and create all this work like, it's all
built. That whole workflow is built in to Gen two. So from a code standpoint, when you're developing, I say, I'm doing a view front end for you know, whether it's inertia, 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 in 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 AWS. But all my back end 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 RLS for the different services, right
yep, yeah, yeah. So when you spin up the ephemeral environment, it creates like this file, Jason file with all your configuration strings in it, and your front end reads that, and it's an Damplify front end library reads it and like, oh, this is where my service function is, this is where the gateway is, this is where everything else is. Yep, you're right, exactly. 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 ause I thought mine is going to do a couple of weeks ago. 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 all my back end without having to you know, reinstall my SQL and reinstall node.
Well might note and stuff like that, right, yeah, yeah, yeah, you wouldn't have to. Like I know, a really popular thing, especially a lot of DevOps guys, like to bring up a like doctor 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. That's pretty straightforward. One thing you could do to your example is, uh, 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 dot dot AWS folder and it adds these keys in so that way, when you run command line command line utilities CLI utilities that command line interfaces that they'll just connect correctly to your back end to the AWS accounts. So you might have thish SSH type connection and they are no, they're like different. So there's with UH with a with AWS amplify,
we have it's an MPM command that you can run NPX and UH. Well, in the first time you craining and you run NPM amplify at latest, MPM create amplify at latest, and then it will create the infrastruction for you. And then when you first run MPX amplify sandbox, which will create the sandbox and federal environment for you. That will look at those keys that are in like your root folder, and it'll look for them on your file system or look for these very variables in your 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 a S s H. But I think it has the general idea of like doing public and private keys, but I haven't looked into exactly that how it does it. Okay, Now, one thing you mentioned earlier when we were talking about the code that you're using for the
infrastructures that it's typescript. So if you're somebody like me who has not completely drunk the typeescript 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. 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 Aw's amplify, but I mentioned earlier something called cloud development It it's called AWSCDK. 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 Typeescript
for that case. So if you want to do CDK, now, the difference between CDK and what I'm talking about with the amplified Gen two CDK is much more. It's very powerful, but it is a lot it's a lot more a 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 want to did we when we did with Gen two is we kind of added another what we call a construct on top
of it, kind of like another layer or 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 colutformation, 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 infrastructures tool
codes to infrastructure as code tools. Okay, right, okay, before we move on anything else from a back end infrastructure standpoint that I want to talk about, No, I think I think you covered most of it. Hopefully that was useful for people thing 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 amplified Gen two product. The other half is our and 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 their 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. 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 with some of the component library stuff, yeah, 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 autmtion and stuff. Aren't there also you know, stuff for simple like forms options and things like that when creating view that tie into AWS or what's the extent of those. Yeah, So the if you go to and I will bring it up as I talk to you, UI dot dot dot amplified. At AWUS, we have this full component library and there's really two parts to it. Well. First, the component library that we have we have we support a lot of different types of
frameworks. We have Android, Angular, Flutter, React, React, Natives, Swift in view 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 framework without a button, UI component framework without a button. It's just say that's pretty much standing. We
also have a complete theming system so you can theme it. But what I think when people ask us is what why should I use this over shad CDN or shad CN or uh in the view ecosystem like view TOFI or tailwind prime View, which I it's 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 view Angular. That that's kind of like our biggest use case for these this UI component framework. And what that allows you to do is is just with a few lines of code you can add in the few lines of boiler plate 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 serve versus our cognitive service, so 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 No, I've no. I've heard horror stories about it. I'd like to use stuff like Laravell that handles all that for me on my back end, So I don't Yeah, I don't want to create an authentication system from scratch 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 next off 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, I forget your password page, a sign up page, how do we redirect once we're signed in? How do we do a lot of things? So that 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 theming 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 View 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 that anybody you can use to change their password after they're logged in a delete users the same thing. Maybe have an admin user that needs to delay to 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 app lists or something. Now now I'm talking about like essentially a component that's Britten memories. Yep. 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 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 face Liveness, which is our U I face amplify UI face Liveness detector which uses in the back end or Amazon Recognition face Liveness service to help determine if a user is reel 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 mapp being fun. And then Storage which is probably our second most popular component. Connected component which allows you to do like S three uploads. It's like a file uploader, so you can upload drop type UI type thing yep, you can. You can drag and drop files directly to public, private, or protected S three buckets and we have a nice interface for
that. And then we have a storage We have a storage image which connects to S three to show images on your page. And then we have one last one is called in app messaging, which allows you to do messages in app messages in your in your app, so that's a lot there, but there's so we've been continuously adding more and more features to our UI Component Framework
library. So are these things that I could use piecemeal as well? You know, if I have a large, you know, a view app that I'm already using, and I hook it up to AWS and I want to be able to stash uh images in an S three bucket, is that something I can use by itself or does it have to be used in the context of a larger framework. Yeah, you can. Certainly, you would have to obviously have an aw's 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 up lading files directly to S three. 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 ABS
amplify. Is it 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 connecting code to all these AW services and we do that all for you, and then we have a nice, very customizable themable component that you can
add to your project. So the theme ability stuff that you know, if I have a component, obviously I'm probably not going to want to use it off the shelf, or maybe like me and you're lazy and you do, so you're going to want to 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 it something like a Tailwind or bootstrap or how does that work?
We have so we with our theming, So any of these connected components we're just talking about, its authentic Internet 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 we're not using Tailwind or anything like that, but it's
kind of you. It's based on several design principles that are pretty common in frameworks like design tokens, and we use breakpoints and over rides, 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 automatically changes. Of course, we have dark mode because you can't have a UI component framework without a button and dark mode, and 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 variable the CSS variables and change them to whatever you want, and that includes all the cover the
colors, disabled colors, the primary colors, and everything like that. Or you can use design tacons. So those are 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 twenty different things. 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 it's not like that. No, Okay, all right, awesome. That's a lot of stuff to talk about. Anything regarding Amplify and Joba script that we missed see one cover. No, I think that covers most of it. I would highly recommend if you're listening, Yeah, check it out. This hasn't sponsored anything. It sounds like it's
kind of sponsored, but it's not. No, I just Steve is having me on and is talking about fun technology. So but yeah, no, it's it. I'm I really think that it'll be simplified as a great product and and it's hopefully more people can check it out. The correct uh industry term I think is called one dig bong shameless plug. But because obviously this is a well battle tested infrastructure, you know at AWS, they've been around for a long time, so uh yeah, and then make it make it
easier to build your app on top of their provided services. That's a win for developer for sure. Yep. And so before we wrap up, let's talk about uh your work as a devreu Uh. We mentioned you initially were started as a as a developer and then moved into the developer relations role. So besides uh, coming on the best podcast out there like this one, what what are the other things that are that you do in your day to day It's more like what I don't do. Developer advocacy is a it's it's
an emerging feel. The essentially what we're trying to do is connect with developers. We're not I mentioned I joked about being a sales person. I'm not trying to be a salesperson. 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. 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 go, I'll come and talk to them. Actually, in two weeks I'm going to 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 two. 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 eleven I think it was like ten or eleven 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 is 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 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
am. I'm on there, and it's funny. There is some there. It's funny. There is some dev developer influencers on TikTok that like dance and they talk about AWS services and it's really it's a really fun place. So I'm trying to it. 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. We're all
double for developer advocacy work. I was a front end engineer and I did back in 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. Did she teaching someone? You don't even have me next, We're just teaching it 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 it's something I really love and I really liked 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. Awesome, Yeah, that would be
fun to I've heard the upsides of downsides to that. I think you know you and I have talked before on views on view regard conferences and how awesome conferences can be. Just in terms of and yes, I'm in and 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. Downsides that I've heard from some people is just a crazy amount of travel. I mean, at some point travels
I got to get a little weirying. I would imagine, 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 five PMS. 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 every couple of months a
few months. It can get to the point, though I heard some develop advocates where they're traveling every single every single weekend, every single week, or maybe three times a month. That's that's too much, Like that's crazy, yeah, and 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 doctor people. Especially being a developer, you kind of you just in front of a computer all day.
You don't really act interact too much. That's not true. You do have meetings and and you do talk to a lot of people, but for the most part, when you're in your zone, you're by yourself from your computer. And so getting past that too. At the first 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 it's that those are some of the negative things too. Yeah,
and travel certainly can be one of them. 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, Golden Medallion stuff, travel lounges and all that. But still travels. Travel is travel. Yeah, it's I have talked to other people too that
travel way more for me. And I'm always getting like tips to like what's the best credit cards to get where it's the best places to go when you're at ex city, When to get to the city, when to leave. There's there's a lot of travel hacks I'm learning more and more about, but like I said, I try to limit it, not to have it be all encompassing because that's no fun. Cool alrighty, Well, with that, we'll wrap it up and move to picks. Thanks Eric for coming on yet
again. Talked about aws. Oh one quick question before I forget you said you blog where you Where do you blog at? I used to blog at program with Eric dot com, 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 the skin at the end. But Eric dot video is just goes directly to my YouTube or Twitter at Eric c h is like the best way to get a hold of me. 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 gotta have the got to have the thumbnail. All right, So with that, we'll move the picks. I'm assuming you remember that Eric and I have I have one. I just thought of, Okay, well I'll go first
and give you time to get that prepped. Uh. You know, for those of you that are regular listeners, you know that my dad jokes for the highlight of any podcast episode. But first, I have a legit pick that I said, Well, I take that back. I have a pick that isn't a dad joke, but it's not. That's not 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 it's really fascinating and
I've seen this before and it makes a lot of sense. And the article, the given incident that talks about happened at LAX Los Angeles International Airport in nineteen ninety one, basically where a seven thirty seven was landing and when it landed, it completely crushed a commuter plane that was sitting on the runway and I think nineteen people died, and it was just it was really bad and right away. The cause and this light controller admitted to it is 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 is sitting. And so the point of the article talks about how the AA 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 or murder charges or something like that.
The whole goal 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 about 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 a whole bunch of different things, and so as a result of that, they were able to figure out what the problems were to address them, and this lady, the traffic the air
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 Plane Crash? By Kira Dempsey. I love it. I was going to say I am a huge fan of I guess not a huge fan, but I liked all those air disaster TV shows, like Air Disasters and Smithsonian's I think it's called may Day in Canada. You know, 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 that stuff, very very very fascinating. Why it's so much safer to travel today than it is back you know, one hundred
years ago or twenty years ago. 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, you know, much safer as compared to just screwed up and now you're gonna someone's gonna clam up and not tell the truth because they don't want to get thrown
in jail. You know. As someone that now travels a lot more and is constantly on flights, I'm like, thank goodness that people are like that in that article exists. Yeah, yeah, for sure. Yeah this uh KYI dempscy. If you look up Admiral Cloudberg, it does a lot of writing that 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. So there's one that
I've read before. So in nineteen seventy eight, when I was pretty young, is December twenty eighth of nineteen seventy eight, there was a I forget the model of plane that was coming into Portland and crashed probably just a couple of miles from my house in a very heavily suburban area and the pilot was very good, either good or fortunate or a combination of both, and Mandids landed in this wooded area between two developments right off a major street here 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 was unaware that he was low on fuel because he had tried to come into Portland and had the circle for a while and during circling he ran out of fuel and realized, oh, I'm out of fuel, got a crash, and so he was man 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 probably like most developers are debugging, and you know, figuring out what went wrong and how to avoid it. So excellent. All right, So onto 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 nice. So I had a friend named Jimmy, and Jimmy brought a 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 haven't heard from him in a while. I got to give credit to Stephen right for that one. He was on Colbert's show Late Night Show and told that one. And he's been my all time favorite comedian for since the eighties.
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 less in the stores because everybody's 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. Love it. So those are my picks. What do you got, Eric? 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 my Apple you can and 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 hand, eyes and hands. You may have seen this little gesture and the commercials. I want to try it out, like this is this? This looks really neat.
It is I think it's around. It's in pre order. It's pretty spendy. It's like two grand, isn't it. Yeah, I think it's uh. Yeah, the two hundred and fifty six gigabyte model is three four hundred and ninety nine dollars, but you can get the Terabyt for almost four thousand, so yeah, it's it's not for it's not cheap, but it
looks kind of like the ultimate geek. If I want to go and ide, like we just said, I travel a lot, I want to see I haven't traveled in a little bit the last couple of months, but I wonder if I'll start seeing them in at 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 threety five
hundred dollars device to try it out for a few minutes. I don't know if that'll work, but I'm well, you work for Amazon, I got money. They can take that point right as a debre. You deserve it. I think somewhere, yeah, go ahead, somebody like you know, 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. I think there is some sort of connection. You can
do aws with Division Pro and might may even with Amplify. I haven't looked into it. I thought I heard that anyway, So would that work? I have no idea, no idea. Yeah, I think there there might be something with x code. I'm looking. I just googled it real quickly, and you can maybe create software for the device. Oh really Yeah,
So that's that's my first pick. I'm I'm all for the world where in you know, fifty 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're just on a vir set sets all the time, spoken like a true introvert. What can possibly go wrong? Just kidding, I'm just kidding. No, that sounds just stopian. You ever seen Wally by the way, Yeah, that that's where we're going. I guess that's we're heading.
That's my only pick other than go Niners. You know, it's that as of this recording, they have made it to the super Bowl and it's gonna be tough. Mahones looks really really good, Kelsey, It's on fire. It could go either way. But I'm gonna if the maps, you see all the maps and the memes ahead of the game, and it shows map of the US, 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 So Francisco and then rushed 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. My team, the Cowboys screwed up again as always, Thanks Jerry, But but I'm just gonna say this, Detroit gave you a gift be happy. Yeah, Yeah, we
definitely got some good luck there in the second half. Yeah. I would say the whole week leading up to the NFC Championship Game, it felt like, yeah, even though the forty nine ers were overdogs, that they were kind of the leading favorites before they were, they were leading, and in in Vegas, if you looked at the points 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've never been there. It's a Cinderella story. It was amazing get it done. So now we got the two not as favorite teams, not as popular teams, but hey, I'll take it. That was Bill Murray from Cadyshack for those who might not 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 Eric Eric with the k THH on Twitter program with Eric and Eric Eric got video yep, all right, and he will answer your questions. Thanks for coming, everybody, talk to you next time.