Ep. #69, Full Stack Serverless with Nader Dabit of AWS

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line we've got Nader Dabit. What's up, Nader?

Nader Dabit: What's up, Brian? Thanks for having me back.

Brian: Yeah, it's a pleasure.

For our listeners, if you're normally just reading his blog post and never had the chance of seeing him speak at a conference, Nader was on episode number 32 talking about progressive web apps and AWS Amplify as well.

I think at the time too, you were pretty new to Amazon, specifically as an employee.

Do you want to tell us what you've been up to since?

Nader: So, I've been there now for a little over two and a half years.

I started in January of 2018 and I have continued to work on the team that used to be the mobile team, and now we're transitioning into the front end and mobile team.

We're doing a lot of stuff with web and we're consistently focused on improving the developer experience, for AWS specifically and for devs that are typically front end or mobile developers that are not cloud developers.

We're really mainly focused on lowering the barrier to entry for cloud computing and making it easy for developers to use the existing skillset that they've had that they've been using to build things like JAMstack apps, React apps, VUE, even iOS and Android, and take that skill set and we're trying to enable them to apply it to build cloud apps.

That's really what I've been working on for the past couple of years.

Brian: That's what I was super impressed with in our original conversation, lowering the barrier of entry to getting into mobile development, which was a specific thing at the team you're working on.

Kind of in the tune of Firebase, and we went in this conversation already, but things that I enjoy with tools like Amplify, not a charity you're working with, is that I don't have to make all the decisions up front.

I can opt-in, is that still the case when you leverage tools like that?

Nader: Pretty much. We've done a lot of work around a CLI, which is essentially a cloud formation or infrastructure as code generator that is agnostic to the actual service names and all of the lingo and acronyms and naming that goes along with understanding how the underlying infrastructure works.

We have a little higher level of an abstraction that allows you to use words that we're familiar with and terminology that we're used to saying, like "Authentication" and "APIs" and "GraphQL" and stuff like that.

We're using the CLI as the base for generating these cloud services, and it's just one of the few parts there.

Now we've built a lot of other things to Amplify, I think, since we last talked.

We're now focused a lot on hosting and integrating all of these things together, the CLI, the client and the hosting.

But you can also just take one of these pieces and use them without using the other three pieces, so they worked really well together but they also really work well standalone.

That's just one of the things that we're trying to make easier.

To make people understand that they can do that, but also to make them work well together if they do choose to go that path.

Brian: Cool. I'm curious too as well, because part of the reason that you're back on the podcast is because of the book you just released.

I haven't read the book yet, I hope to grab a copy soon, but the title is Full Stack Serverless.

So I'm curious, I guess, of the title itself.

But also, how does that also encompass in some of the stuff you've been working w ith AWS as well?

Nader: The book came out of a discussion that I had with someone from O'Reilly, actually.

I finished writing my first book, which was React Native in Action, and that was with Manning Publications.

I've always wanted to write for O'Reilly and I've heard good things about writing for O'Reilly as far as the process is concerned , so I wanted to do that but I didn't know who to talk to.

I actually went on LinkedIn and just found an acquisition editor and just inboxed her, and I was like "I want to write a book for O'Reilly."

It was actually that easy to at least get a conversation going.

Of course, from then you have to pitch your idea and you have to submit a proposal, and the proposal then gets iterated on and there's pushback and you have to get to the point where you get your idea accepted. That process was interesting, because as it relates to the naming of the book, we were kicking back and forth ideas, and the ideas came from me but also from her around what the demand is and what's selling and what's popular.

A couple of the ideas I had were either around JAMstack, they were around just React in general, and they were also around cloud computing with serverless.

One of the ideas that we were talking about was combining the serverless and the front end stuff, and it went really well along with what we were already doing at AWS and some of the trends that we were seeing around the adoption of Amplify.

We thought at first that a lot of the adoption was going to come from existing AWS customers and people familiar with cloud computing, but what we actually saw happening was front end developers were picking up Amplify and they were using it a lot more than we were seeing adoption from existing AWS customers.

The idea was this Full Stack Serverless or full stack cloud, that was the path that we were headed towards.

So the book came about from that discussion, and we went with the name Full Stack Serverless because that's essentially what Amplify enables, and that's what the book is about.

It's about building full stack applications with Amplify, and almost all of the services that are underlying are serverless technologies, so it just made a lot of sense.

Brian: OK, excellent. That's funny, because that's a term-- "Full Stack Serverless" is something--

Actually, I used to use the term "Serverless side rendering" a lot back in the day, I think prior to even "The JAMstack" term taking off.

It was really just around, I was just trying to attempt to do a bunch of stuff without all the complications of things like server side rendering and managing full stack monolithic applications.

So I'm curious, with the full stack serverless thing and I assume Amplify also gives you the opportunity to create Lambda functions as well as some other stuff, is that what the whole--?

Like, what you get out of the book? Being able to piece the console together and make an application?

Nader: Essentially you get all the pieces you need to build a full stack application on a cloud, so when you think of something like AWS or GCP or Firebase or any of these things, you think about the actual back end services.

You think about the client technologies that need to be there to integrate with those, and all of the underlying complexity that a lot of times comes along with making secure calls to these back end services.

I think the problem with AWS in the past, or the challenge I guess you'd say, was that the AWS JavaScript SDK was the main route for interacting with these services.

The user experience and the developer experience wasn't very friendly for front end developers, in my opinion.

If I was coming in to AWS and I was trying to build something, it was really hard for me to get going.

So, what we're trying to do on our team is we're building out the abstractions and all of the tooling and stuff that's necessary on the client to actually make that process a lot easier.

If you want to talk to an API backed by Lambda function we have different categories that handle all of the things, like headers and signing all of the authorization requests and all of the different tokens that you would need to have an authenticated request, and send all of that data in the header.

Like the refresh token, all of the different tokens that you would need like the identity token and stuff like that.

I think Full Stack Serverless is the idea that you can go with one suite of tools and get the ability to generate all of the different services.

You get the client APIs that are needed to interact with those services, and you have a way to understand how to actually create these services in the proper way so that they're actually secure and scalable without being a cloud expert.

It's "Full stack" in the sense that you're getting the front end and the back end and everything works together.

Brian: When you say "Full stack" too as well, is this attached to a certain library or framework?

Like, can you build a React app? Can you build a VUE app with this technology?

Nader: Our team has multiple teams within it.

So, we have a React team, we have a VUE team, we have an Angular team, we have now a Flutter team a native iOS team and a native Android team.

Each team owns each client, so we own all of those clients.

If you're a mobile developer and you're building apps with Swift UI, we have a team that is building SDKs and libraries specifically for you.

Therefore we're owning all of that front end complexity, and we're just providing those libraries.

We're not offloading those to the open source community, we're building that ourselves and we're providing those, and we have everything as open source and we're able to go in there and create issues.

So, we have a general JavaScript library but we also have React components and VUE components and things like that, that abstract way even more.

I think I may have even talked about this the last time we talked, if you need authentication and you need to get up and running really quickly, there is a typical process where you create a sign in flow and a sign out flow, and you have to handle the state management and all that stuff.

We have UI components for all of these different frameworks with just a couple of lines of code that just scaffold all the stuff out, make it somewhat configurable, and just gives you a really quick way to throw something up to have authentication.

Also, we have other components around storage and other things.

Brian: So are you saying that there is a design system built into the SDK as well, or is that separate?

Nader: It's somewhat of a design system, in the sense that all these UI components are consistent in the way that they're designed and you can configure them, but there's not any design system in the sense that you would have buttons and navigation components and stuff like that, that you would use now.

Brian: OK, cool. It's nice to know where the framework for this library stops, but also just zooming out it's a great time to be a front end dev, to be quite honest.

There's so many things off the shelf-- I am an AWS fan, and I guess it was the first cloud computing platform that spoke to me enough that I could understand it.

Even though, as you mentioned before, it is a confusing console to navigate.

Which is why these CLI tools exist today to make it even more easier for me, but what I'm getting at is the fact that we can pick a design system off the shelf and we can pick where we're going to host the stuff, how we're going to interact with the JavaScript code.

It's mind blowing to think of 5, 6 or 7 years ago.

Front end developing was essentially jQuery, and a bit of coffee and maybe JavaScript.

Now we've expanded it to the point where you don't have to make the decision on how the server is running or how you are scaling it as well.

Which is even better, because now I can-- If I'm already using AWS as my technology, I know I can tap into the CDN. Is the CDN Cloud Formation? I forget the namings of all the stuff.

Nader: Yeah, Cloud Front.

Brian: Cloud Front, that's right.

Nader: There's Cloud Front, and then with Amplify we also have AppSync which is GraphQL as a service that you can use as the API layer.

But no, you're right. It's an amazing time to be a front end developer.

A lot of people complain about things in the front end world.

I understand where they're coming from in a certain sense, but there's also a positive light.

Like you mentioned, all of these things are there.

Not only is React, they just came out with a new version with no new features and some people were making complaints about that, but most people weren't.

Most people are actually pretty positive about it, and I think it's really cool to see that we're to a point where a major framework comes out with a major version without any new features, because maybe there's enough already there to make everything already work really well.

Then you look at stuff like Gatsby and Next.js that make building static sites and also whatever you call Next.js with these dynamic routes and API routes, it's so easy.

Then you have stuff like Netlify and you have stuff like what Azure is doing with their serverless functions.

They're doing a lot of stuff with static sites and front end stuff, and you have GCP with Firebase and they're improving their stuff all the time.

There's so many amazing options, and you have stuff like Begin. Have you have you looked at Begin yet?

Brian: I was going make a very bad pun, but yes, in the beginning of Begin, I've been circling back to them because it was some pretty cool stuff with functions.

I think they figured out the product, because when I looked at it about two years ago they were still trying to figure out the experience.

They had just came out of a pivot, but it's something I should probably have Bryan and then possibly Ryan on the chat about that.

Nader: All the stuff is really great, so if you want to build a full stack application with the same infrastructure that companies like Netflix use, you could literally do that in like 30 minutes with one of these guides that you can find on the getting started pages for these different back end technologies, "Full Stack Serverless" technologies, or JAMstack technologies.

It really is pretty amazing, and it's pretty mind blowing.

I mean, the abstraction is really high in some of this stuff and it is a lot of magic going on.

A lot of people are going to be put off by some of that, because they're going to be like, "OK. I want to know everything that's going on," and when you start digging into it there is a lot of complexity.

If you build a Gatsby app and you want to know what's going on and you start opening the source code, there's a lot of complexity.

But what it gives you is super powerful and it is pretty configurable.

I think as long as people are building the right escape hatches into these things, then it is extremely powerful.

Because not only are you getting all of this great power, I guess, and I hate to say "Powerful in power," but you're getting all this power.

But you're also being able to have that escape hatch, so if there's something that isn't supported you're able to still do that thing.

Brian: Speaking of building companies on all this magic, one of the companies I sign all the time when it comes to AWS and S3 and how they unlocked that magic was Instagram.

Are you familiar with the story of Instagram and how they got started?

Nader: I'm not too familiar, other than I know that they had a really small dev team.

Brian: They got acquired, I think, with 11 or 14 people for $1 billion dollars by Facebook.

But the way they got started was through image hosting, because at the time if you wanted to do a photo sharing app or whatnot, you had to run your own servers in your kitchen or your bedroom or whatever, just to get up and running.

Then you'd go buy server space somewhere else.

But they ended up leveraging S3 and AWS pretty early on in their career or their startup infancy , so because of that decision they were able to scale and grow where other photo sharing apps on iOS could not.

Because of that, they were able to do really cool things.

One of the problems that they had was that they had to--

The uploading to S3 took time, so during that time they had to figure out what to do while the user was waiting to upload the photo.

So, they created filters. The entire time you pick your filter for Instagram, back in the day--

Now it happens instantly at this point, but while you were picking your filter for Instagram it was uploading in the background.

Nader: Interesting.

Brian: A lot of that trickery that we see in a lot of sites, that anticipated loading, those are things that I think about in the side projects that I work on.

Where I'm like, "This is going to take some time."

I could go down and fine tune and put on the gloves and start trying to figure out what servers and what places to put things, or I could just do some really cool front end trickery and some animations and make it beautiful.

That's a story I think about a lot when I build front end UIs, I was like "I can make it better and make it faster, which I should. Or I can just ship it and have people use it and then have them tell me what's more important to do."

Nader: That's true. A lot of the stuff that we do as front end devs is essentially that, just sleight of hand.

A lot of the people that I learned the most from were the engineers that were just really good at coming up with ways to do that, and I think that's part of becoming a good developer sometimes, is figuring that out.

Finding your way of doing that, because there isn't really always a right way to do things and there's just more along the lines of doing things that work well for you or that just work well, period.

Brian: Speaking of learning from developers, I've chatted with Tim from Next.js a couple of times, which I want to have him on the podcast hopefully soon, this is probably the fourth time I've called him out in person on the podcast.

Like, I should have him on.

But what I'm getting at is that I just built a Next.js app this week, literally yesterday, it took me a couple of hours and I had an idea for reselling stickers and giving away stickers for my side project.

So, I figured I spent all this time on the UI and the brand, I might as well make some stickers.

I threw together a Next.js site after some conversations in Discord, I was like "I can do this."

But that is what I'm getting at, is the sleight of hand, the trickery they're doing to hand over server side rendering and then the static routes, and all that magic that happens.

It's mind blowing.

This is something that 4 .5 years ago when I started this podcast was not something that was easy to do, so much that I would avoid server side rendering with all cost, like don't even touch it.

Now it's like, "I just create Next app. I've got it out of a box, I just make sure my routes match and I'm good to go."

That blows me away that I can just take advantage of someone else's hard work thanks to open source, and I can just move on.

Similar to Amplify, connecting all the stuff that I want to do in AWS and just giving me something like a nice layer of an actual human readable documentation that I can just--

"I want to do a login. Help me find the application layer. OK, it works. Now I can do the next thing."

I don't have to spend weeks on top of weeks trying to make sure my secrets and security and everything like that is secure.

I just get it out of the box, which is-- Again, a great time to be a front end dev.

Nader: You called out Next.js And Tim and we have to say Vercel and Guillermo and that entire team.

He is, to me, just one of the most amazing people to watch.

He's just so smart and his entire team is just so good, and the stuff that they do is next level in the sense that they just are innovating in so many ways.

It's just amazing to watch, and it's just one of the many tools that are out there.

The services and things that you can just pick up as a front end dev, and their docs are really good, and everything just works really well. It's amazing.

Brian: So, I wanted to take a step back and talk more about the book itself and that process, because you actually unearthed a lot of questions I had about writing a book.

I've been approached to write a JAMstack book in the past and I've politely declined, because I just feel like I can write a blog post but when it comes to writing a book, it seems like such a big workload to do.

I'm curious of how you broke that up, and to be able to ship something. What was that process like?

Nader: Absolutely. This is my second book, so I've had a bit of experience at this point and I've learned a lot from the first one and from the second one.

I feel a lot more confident now about even writing another one, I would say after my first book I was a little discouraged about writing because the process was so long and it was so much work.

The payoff that you get is-- You're not sure what's going to happen when the book gets out, and then there's the discussion around "Should you self publish or should you go with the well-known publisher?"

I have some pretty good ideas around my opinion there and stuff, but I would say the process is just like anything when you're trying to undertake something very big.

Like, if you go into a very large code base and you're trying to learn something new, you typically just want to break it down into the smaller chunks and look at it that way.

Understand that for writing a book, it's just going to be a long and consistent process, like a marathon that you have to work out every day to get there. You have to focus on the end goal.

Like, remember one day this book will be in paper form and you will be done with it and you will reap some benefits from it, even if it's just having your hands on a finished book.

If that's the reward, that should be good enough.

Anything else is just additional, so don't -- I was just always focused on having a finished book, and that was the thing I always looked towards.

To get started you would probably approach a publisher.

If you're a decent developer, there are enough publishers out there actually looking for people to write books that you can at least get a conversation going with the acquisition editor.

That's probably who you would want to talk to, find them on LinkedIn or find me on LinkedIn and ask me, I'll try to refer you to a couple.

Then from there, you're going to propose something and you're going to probably have a discussion around what you're going to be proposing, like the titles and what's there, and why you're the right person to write the book.

Then once you figure out the topic, you're going to propose a table of contents.

Once you get that table of contents done, then you have that entire proposal that they're going to take and they're going to look at not just the acquisition narrative, but maybe some other people in the company.

I'm not sure exactly how that goes, but a bunch of people are going to review that and either approve it or they're not going to approve it.

If they approve it, then that means you have a book deal and you may or may not get some money up front for that. You're just going to have a bunch of deadlines that go along with that table of contents, and you're going to say, "OK. A month from now I have chapter one, two months I have chapter two." And you're just going to work every day or however your schedule is to ship that book, and you're going to have a lot of review that goes along with that.

You finish the book or you finish a chapter, people are going to be reviewing it and they're going to be giving you feedback, and you have to go back and re-do a lot of stuff.

In the case of my first book, I had to go back and rewrite 3-4 chapters and that was really tough for me.

It was really discouraging because I had spent so much time, doing the work that I have someone come back and be like, "You have to completely rewrite this."

It sucked, but my first book was React Native in Action and it did fairly well, but I feel like this next book that I've done has gotten a lot better.

It's been a lot more well received and I think it's sold a lot more copies already, and I think it's mainly because React Native in Action was focused on React Native.

I think there's just more developers interested in AWS that are using React and GraphQL.

So, this book is actually-- I think at one point it was sold out on Amazon after it came out, and I've had so many people reach out to me on LinkedIn and Twitter and different places, and email, saying that they've bought it and that they're reading it.

I've had a good response from the editor at O'Reilly, and of course being with O'Reilly probably helped.

Also the fact that I launched this book with like 40,000 Twitter followers, whereas the last book I launched with like 2,000.

That probably also helped. So it's hard to know, but I would say it's definitely worth it to write a book.

The things that came out of my first book weren't really the book sales and the money, it was more around "You wrote React Native in Action? I am going to hire you to be a consultant at this really high rate because you obviously know what you're doing."

That was what I got out of my first book.

I don't really know what I'm going to get out of this book, but so far just finishing it was enough for me, and I'm extremely happy to be done with it.

I think that what I wrote in this book was a distillation of what I've learned over the last three years, and if I just started with AWS and I had this book, I would have maybe taken a year's worth of the work that I had done to learn this stuff.

So, that's the way I look at it. This is the book I would have written for myself.

I know a lot of people say that, and I think that's a really good approach, because if you want to teach something to someone you should teach it in the way that you would want to have taught it to yourself.

That's the way I did with this book.

Brian: Excellent. How long did it take you to complete it, from start to finish?

Nader: This book wasn't that long.

It was maybe an 8-9 month process, and my first book was much longer. I think that's just because this book is a little shorter, I think it's 11 chapters.

Also, I have to say, working with O'Reilly has been really nice and they're very quick to respond.

The feedback they give is very good and very concise and very actionable.

Brian: Excellent. I look forward to picking it up, so hopefully it's not sold out anymore.

Definitely going to grab that, sell those concepts between AWS but also Amplify as well as GraphQL, those are all things that I'm super into right now.

It's good to-- The one thing I like about picking up books on even technologies I already know is that I always find out something that I didn't know by just learning from other people.

Watching a screen cast, going to the conference talks, I always just find out brand new things.

Top of mind, just a couple of weeks ago I learned a new git command out of the blue because I was pairing with somebody and I didn't realize that you could do git remote update.

That basically just grabs-- It grabs your remotes, but it also updates at the same time, which is like if you did git batch--

Anyway, that's too much in the weeds and off topic.

Nader: No, I totally get it. I'm always learning something from someone.

I love Twitter because I see so many different people sharing so much interesting stuff, I love Egghead because I learn from those short and concise videos.

I love YouTube-- I'm there with you, and I'm always picking up books.

Brian: Can I ask, how did you get to 40,000 Twitter followers from 2,000?

From someone who is on their way to 40,000 from 4,000.

Nader: I think working at a big company helps for sure, and from there you have people assume that maybe they would probably be more likely to follow you.

I've just been consistently talking about stuff on Twitter, trying to make jokes, memes, get involved in interesting conversations, sharing stuff and noticing what people respond to and what they don't respond to and trying to gravitate my tweets towards that.

I don't want to be one of those people that just says stuff just for engagement, like I've seen happen a lot in some areas, but I do notice what people seem to respond to and I do try to tailor what I say towards that.

So, if I'm going to share something I will try to word it in a way that I think is going to get more engagement than not.

So, there's definitely some thought to it.

Just being consistent and sharing stuff and trying to make it part of my daily routine to respond to people and get an interest in conversations, over time it has gotten to that point.

It didn't happen like overnight, it's definitely happened over the course of the last three years or a few hundred followers a month, or whatever over time.

Brian: I would say that the pictures of your wife's cooking. I like those all the time.

Nader: Man, food is my thing.

Everyone loves food, but I love talking about food on Twitter and posting pictures.

I think that a lot of people-- I'm Palestinian, and my wife and all of my wife's family and even my own family is always cooking interesting and delicious Palestinian and Arabic food, so I always post that.

If you're interested in that, follow me on Twitter.

Brian: Actually, I need to start responding.

Because I always have questions. I show my wife, I'm like "What is this? We need to make these things."

But I'll jump into the conversation next time you have dinner and you post it, for sure.

Nader: If you ever need recipes, hit me up. If you ever come near Mississippi, hit me up, we'll have you over.

Brian: Excellent , cool. So as we're winding down, I want to switch to picks, but I want to also briefly ask about the JAMstack CMS and how that's going.

Because I know you launched at least a year or two ago, is that also mentioned in the book? Or is that just a completely aside from it?

Nader: O K, it's actually a Full Stack Serverless project and it's a great example of why I think this is a really great space to be in.

We didn't really talk about infrastructure as code, which goes along with what that JAMstack CMS is and what Full Stack Serverless is.

But I mean, JAMstack CMS launched in October of last year so it's been around for almost a year.

Then I also launched JAMstack E-commerce and I'm about to launch JAMstack E-commerce with a back end, which is a Full Stack Serverless project.

But essentially, one of the really powerful things about a Full Stack Serverless app is that it can be shared and redeployed so people can actually build out reference architectures and example projects that tie the front end and the back end together.

For a boilerplate, essentially, if you think of a lot of the React or Gatsby and JAMstack boilerplates that you see , they're just the front end.

As a developer, I think it would be really cool to be able to also have the back end for that. In the past, you couldn't really do that because if you needed to provision a server and write a database, all that stuff took a lot of back end knowledge. Of course, it wasn't really able to be abstracted away.

But with infrastructure as code and some of the different things that we're seeing happen around infrastructure as code, for me there's CDK, which is extremely interesting.

It allows you to write Python or JavaScript to create infrastructure, and I think TerraForm is about to come out with their version of it.

Amplify CLI is a way to create infrastructure as code using CLI, and then there's this new thing I just saw, I think it's called "Adapt" or something like that.

Adapt.js is like React for infrastructure as code, you're able to create React components.

But the thing with JAMstack CMS, and the thing with all of the Full Stack Serverless stuff is you have two artifacts from your project.

You have a front end and you have a back end that is able to be shared and redeployed, so if I build a photo sharing app I can actually give the link to my GitHub repo to you, and you can then deploy that entire back end and the front end, and then iterate on that and create your own version.

That's one of the really powerful things about it, and JAMstack CMS is essentially a full stack CMS.

I think when I get to V1 with that, it's actually going to be mainly focused on just the CMS part and be agnostic about the front end.

I'm going to provide a front end, but I think the real power there is allowing people to have a way to generate and host and deploy their own CMS that is just running on serverless technologies.

Which means, you're not going to be paying a monthly fee for your CMS like you would with some of these other things.

Instead, you will just be paying for the resources as they're used in a serverless manner.

I think there's a lot of future for that, I don't know if my project is going to be the one that nails it, but I think it's a good proof of concept and we'll see where it goes.

Brian: That's excellent. I completely brain farted on JAMstack e-commerce.

I remember that getting tweeted out a while ago, because I had just built basically an e-commerce site in Next.js to sell stickers.

Nader: Nice.

Brian: It would nice to know, to actually think of this first too as well, because all the infrastructure is here.

It looks like it's actually powered by Stripe as well, so I highly recommend -- It looks like JAMstack CMS the org itself.

All those projects you mentioned are sitting right there, waiting for people to use them.

Nader: Yeah, and I'm actually working on another org called Full Stack Serverless, and it's going to be open to any Full Stack Serverless back end.

So Azure, Firebase, Netlify, anything that you can actually create infrastructure as code in.

I would be hoping to get pull requests and stuff from those, and it actually hasn't been officially launched yet because I haven't finished the number of projects that I would like.

I would like to launch with five projects that I'm working on, a chat app, a blog, and full end to end authentication flow.

A couple of other things like e-commerce, so I'm building those right now, but right now you can go ahead and check it out.

I have CDK and Amplify and that's what's going to be launched with, but I'm going to be completely open to having other people add other providers.

Essentially, it'll be like the back end and the front end, like what I'm talking about.

So if you want to get started with an app and you know you need authentication and you know you're going to be using web technologies, you can start from a place and then take it from there.

Brian: Excellent. I'm definitely going to start kicking the tires on this thing, and I look forward to trying out for one of my future projects.

I'm doing an overhaul of my blog and a couple other sites that have gotten a little crusty and haven't really been touched a lot, so I'm actually picking different tools to migrate them to just to keep my brain up to speed as a developer who's been around the block for a bit.

I just want to make sure I'm keeping up to date with some things on some of these side projects, so I think I might grab one of those.

Nader: Yeah, totally.

Brian: And leverage your JAMstack CMS for sure.

Then as well as the book, and the future org as well, I'm going to keep an eye out for that.

I wanted to transition us to picks, I appreciate the conversation on Full Stack Serverless, the book talking about Amplify.

Talking about JAMstack as a whole, and just the front end of that.

I hope everybody's gotten real good insights from this conversation, and I think we could all find each other on Twitter as well.

Actually, what is your Twitter, since we spent some time talking about it?

Nader: Yes, it's @Dabit3.

Brian: Why a three?

Nader: Same with GitHub. I think that was just a username I found early on, and I just copied it across all of my different social media stuff.

Brian: Excellent. No one's asking, but I'm @bdougieYO on Twitter as well.

Anyway, I want to transition us to picks. These are jam picks, things that we're jamming on.

Usually it could be tech related, music, food related, movies.

I know we're all spending a lot of time at home, so we could pretty much check all those boxes.

But if you don't mind, I'll go first and give your brain some time to think of a pick.

I wanted to first talk about-- So, I mentioned my YouTube channel last week.

Which if you go to YouTube.com/ILikeRobot.

That is my YouTube channel, and it's a URL, it used to be the channel I recorded and put music on when I was in college.

So that's why it's called "I Like Robot," but for whatever reason I cannot figure out how to change it because it's so old.

I guess you can only change your YouTube name once and I changed it in 2008 when I first got it.

But anyway, that's beside the fact. That's the Brian Douglas YouTube.

I've been doing some screen casts, and I mentioned that last week in the last podcast, Git Action Traction.

But I wanted to also mention, because you're here, I saw a tweet a couple of years ago on how to record a screen cast.

You had mentioned, "You should record it and then redub the audio," or some sort of forum.

But anyway, I specifically remember a tweet that you said, which is the way I do screen cast today, which is I will record the entire screen cast in one take, and then I'll chop it down to if it was going to be the final take.

Then I'll just take the actual video of the screen cast and I'll just do the audio again while the video is going.

So, what I've been doing is I've been using this tool called Transcriptor, which is built on AWS Transcribe.

So one of my friends down in San Diego, Jay Miller, he's KJ Miller.

If you look on his repos one of them is Transcriptor.

He built this Python tool to basically take any audio and video and transcribe that audio and video into words, and that's what I do to redub my audio on my screen cast.

I've basically got my screen cast recording down to only two takes.

I do one take, it works, I chop it up and make sure it looks good, and then I record it one more time with the transcription.

Then I've got transcriptions for the final thing if I want to use transcriptions for closed captioning, and then I also have actual clean audio where it doesn't sound like I'm doing "Ums" and "Ahs"and all that other stuff.

Hands down, it's probably been the best way to do screen cast for work and for side project reasons, and I'm super appreciative of stumbling on your tweet years ago.

I don't know if you remember that tweet, or remember your pattern for screen cast.

Nader: Yeah, absolutely. That's the way I do it. It works great for me.

Other people have their own ways, but I think this seems to be a really efficient way to do it this way.

I'm not wasting a ton of time, I just have to-- I know I have to do both, you do the first take and the second take, but that's it.

You don't really have any other things that you have to do after that.

Brian: Timing wise, if you go to Netlify in their docs, some of those videos are still me.

That was when I first did my first ever screen cast, probably five years ago.

Then after I did those, I spent probably, like, a Friday just recording all these two minute videos but it took me half a day to do.

Because I didn't know what to do and how to approach it and how to plan it, so I just figured it out then.

Then I ended up seeing this tweet of you explaining how you did your screen cast, so I was like "Genius."

Ever since then, I've been able to optimize.

Nader: Awesome.

Brian: I had one more pick too as well, being in the house with my six year old we have been playing a lot of Super Smash Brothers: Ultimate, which is a nice trip down memory lane.

When I was a kid, The Smash Brothers on 64 had been out.

I played that and I was pretty boss on that, but I am not great at Smash Brothers today.

I've got a lot of learning to do, but I'm a big fan of the Switch and leveraging Smash Brothers.

Everybody grab a copy, and if you DM me-- Follow me on Twitter and then DM me, and I'll tell you my Nintendo handle and then we'll battle.

Nader: Cool.

Brian: So, you got some picks?

Nader: I guess, my picks are going to be a couple of people that I've been following on Twitter that are doing some cool stuff.

The first one is Catalin Maron , and he's doing some really cool stuff with React Native .

React Native has always been my thing, and I'm always interested in seeing what people are doing.

He's doing some really interesting stuff with animations and just UI stuff, he's been creating some really cool videos and releasing the code that goes along with that.

So, that's someone I would check out and I'm pretty interested in that.

Then there's Yan Cui, he's @TheBurningMonk on Twitter.

He's doing a lot of interesting stuff around serverless, so if you're interested in just really raw serverless stuff in the sense that he's doing stuff closer to using CDK and serverless framework, and stuff like that.

Or just direct AWS services, he's creating a lot of really great content.

He does free blog post videos and stuff, but he also has a couple of paid courses and he's someone I really am interested in and I enjoy following.

The last person is Chelo Loco, he's someone that joined our team at AWS about two months ago, and he has a really good YouTube channel.

I've learned a lot from his videos because he's really great.

He's a really popular YouTuber, but he's really great at creating content and I've learned a lot from his videos but I also really enjoy watching his videos.

He has videos around getting into tech, and some of the things that have happened during his career that he's talked about that are pretty interesting.

He also has technical videos around using Swift UI, and of course some of the stuff that we're doing on our team at Amplify.

Brian: Very cool. Hopefully everybody can find those links in the show notes.

Again, Nader, thanks for coming on and chatting about the Full Stack Serverless. Listeners, keep spreading the jam.