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.