Fullstack Serverless with Nader Dabit

Episode Description

Nader Dabit explains how full stack serverless empowers front-end developers to build scalable cloud apps using managed services like AWS Amplify and AppSync.

Episode Summary

In this episode, AWS senior developer advocate Nader Dabit joins to discuss the concept of full stack serverless and how managed cloud services are transforming what front-end developers can build. He explains that serverless has evolved beyond functions as a service into a broader category of managed abstractions, enabling front-end developers to leverage their existing skills with APIs to create complete applications without building back-end infrastructure from scratch. The conversation explores how this doesn't replace back-end developers but rather frees them to focus on more complex, business-differentiating work while front-end developers handle standard patterns. Nader walks through AWS Amplify's evolution from a simple JavaScript library to a full tooling suite encompassing a CLI, graphical interface, and hosting service, all built to abstract away the complexity of CloudFormation and AWS configuration. The discussion highlights AppSync as a managed GraphQL layer that can connect to virtually any AWS service, with real-world examples like Orangetheory's rapid pandemic pivot and a Clubhouse-Twitch hybrid startup. The episode also touches on serverless-first development philosophy, Amplify's pricing model, and how Nader approaches creating developer education content.

Chapters

00:00:00 - Defining Full Stack Serverless

Nader Dabit introduces himself as a senior developer advocate at AWS on the front-end web and mobile team, and the hosts set up the episode's central theme: exploring the parallels between full stack serverless and full stack Jamstack. Anthony notes that both communities share a passion for enabling developers to build complete applications with modern tooling.

Nader defines full stack serverless as the convergence of improved front-end tooling with increasingly managed cloud services. Since front-end developers already know how to call APIs and render data, the main barrier to becoming full stack was building and scaling back-end infrastructure. Managed services for databases, authentication, storage, and APIs have removed that barrier, allowing front-end developers to build robust, scalable applications using their existing skill sets and cloud abstractions.

00:03:17 - Bridging Front-End and Back-End Development

The conversation shifts to whether full stack serverless benefits only front-end developers or also serves back-end engineers. Nader explains that back-end developers thrive in these environments too, especially when more advanced scenarios arise, like complex DynamoDB data access patterns or global secondary indexes that require deeper expertise.

He draws an analogy to React Native, where JavaScript developers can build cross-platform apps quickly but still need native developers for bridging complex native code. Similarly, serverless teams benefit from having back-end expertise available for advanced problems, while back-end developers are freed from repetitive tasks like building CRUD APIs and authentication layers. Nader emphasizes this isn't about replacing back-end roles but making both front-end and back-end developers more effective, while cautioning that newcomers shouldn't rush into these tools before mastering front-end fundamentals.

00:06:50 - AWS Amplify's Evolution and Developer Advocacy

Nader describes his role within AWS's front-end web and mobile organization and traces Amplify's evolution from a client-side JavaScript library launched in late 2017 to a comprehensive tooling suite. That suite now includes a CLI for spinning up cloud infrastructure, a graphical user interface for configuring services, and a hosting platform for static sites.

He also discusses how developer advocacy has shifted over time. Early on, the focus was building awareness since nobody knew about Amplify. As adoption grew, the team pivoted toward improving developer experience by listening to customer feedback and channeling pain points back to engineering teams. Now that Amplify has significant traction, the emphasis is on making the product genuinely good so that users' organic sharing of experiences drives continued growth.

00:10:42 - How Amplify Simplifies AWS Infrastructure

Chris asks whether Amplify requires full adoption from the start or can be adopted incrementally, and Nader confirms it supports both approaches. He explains how Amplify abstracts away the complexity of AWS infrastructure as code, replacing intimidating CloudFormation files that can span thousands of lines with a friendly CLI that uses intuitive category names like "authentication" instead of "Amazon Cognito user pools."

The conversation covers how Amplify generates infrastructure as code behind the scenes, deploys it with a simple push command, and provides client libraries that handle token management, API calls, and authentication across platforms including iOS, Android, Flutter, React Native, and web. Nader positions Amplify alongside other tools like Serverless Framework, Terraform, and CDK, acknowledging each has its strengths depending on the developer's background and project needs.

00:15:44 - Real-World Use Cases and AppSync as a Data Layer

The hosts ask what kinds of applications people actually build with Amplify, and Nader shares concrete examples. Orangetheory Fitness pivoted to a remote exercise platform during the pandemic, building and deploying their web application in roughly two weeks. Another startup built a Clubhouse-Twitch hybrid with live streaming, voice, and chat functionality as a quick proof of concept.

Nader then highlights AppSync as the most compelling piece of the ecosystem, describing it as a managed GraphQL service that can map operations to any AWS service or even third-party databases like MongoDB. He shares how Ticketmaster used AppSync in beta to scale to tens of millions of connected clients, and how he personally built a basic Clubhouse clone in about two hours by connecting AppSync to Amazon Chime through Lambda with a simple IAM permission flip.

00:22:40 - GraphQL's Migration from Mobile to Web

Anthony steers the conversation toward why GraphQL, which originated heavily in the mobile development world, has become so popular among web developers. Nader explains that AppSync was initially designed with mobile in mind, targeting benefits like offline persistence, real-time data, and smaller payloads for better performance over mobile networks.

However, those same advantages apply universally, and the sheer number of web developers compared to mobile developers has driven broader adoption. The development experience that GraphQL provides as an API layer works well regardless of where it's consumed. The hosts reflect on their own journeys into AWS through mobile development and how that technology has naturally carried over to benefit web applications as well.

00:25:36 - Pricing, Serverless-First Philosophy, and Tutorials

Chris asks about Amplify's pricing, and Nader clarifies that the Amplify framework and CLI are completely free and open source, with costs coming only from the underlying AWS services and the optional hosting service. He emphasizes that most Amplify services follow a serverless pricing model, meaning you pay nothing if you have no users, with exceptions for containers and Elasticsearch.

The conversation wraps up with a discussion of serverless-first versus container-first approaches, where Nader advocates for specializing in serverless and only spinning up servers when tasks genuinely can't fit the paradigm. He also shares how he picks tutorial topics through a combination of customer feedback, personal curiosity, and tracking industry trends like Next.js. The episode closes with a lighthearted exchange about Anthony's upright bass and where listeners can find Nader online.

Transcript

00:00:00 - Nader Dabit

Yeah, I'm ready.

00:00:11 - Anthony Campolo

Nader Dabit, welcome to the show. Super happy to have you here. Why don't you go ahead and introduce yourself to our listeners?

00:00:18 - Nader Dabit

Hey, what's up, Anthony? Yeah, thank you for having me, and thanks for the intro. My name is Nader Dabit, and currently I work as a senior developer advocate at Amazon Web Services on the front-end web and mobile team.

00:00:28 - Anthony Campolo

Awesome. You've done quite a lot of podcasts in your time. You've even hosted a number of podcasts as well. We'll have plenty of links so people can dive in more.

But we'd really like to explore your ideas, especially around full stack serverless, because this is something we're passionate about.

I think there's a lot of interesting parallels between what you call full stack serverless and what we call full stack Jamstack, so I'd like to tease those apart. Why don't we start with your definition of what full stack serverless is?

00:01:16 - Nader Dabit

I think the idea of full stack serverless, or even full stack cloud, is that front-end development has changed quite a bit over the last few years. There's been growing complexity, but there's also been a big improvement in tooling. At the end of the day, a front-end developer is typically building a user interface, calling an API, fetching data, and rendering it to the screen. We're dealing with things like authentication on the client.

But we're often working with other people's APIs. What we're starting to see in the cloud ecosystem, and in a lot of things that fall into the category of serverless, is that these APIs and databases as a service are becoming more accessible to front-end developers by being more managed.

[00:02:10] They're bringing these managed solutions. Therefore, since front-end developers already know how to interact with APIs, the thing that was limiting us from becoming full stack developers in the past was how to build and scale a database, an API layer, authentication on the back end, or a storage solution.

Since all of these things are now becoming more and more managed, a front-end developer is able to not only build the front end, but also take advantage of back-end technologies without having to build them from scratch. They're able to use their existing skill set and build full stack applications.

I think the serverless paradigm is making this possible because serverless no longer means just functions as a service. It's now more like managed services or some type of abstraction that takes something you would have needed to implement yourself in the past and puts a nice abstraction layer on top of it, making it more accessible.

[00:03:05] So I think full stack serverless is opening the door for front-end developers to use their existing skill set to build real-world, robust, scalable applications, typically using some type of cloud technology.

00:03:17 - Anthony Campolo

Very cool. Yeah, definitely jives with what we're doing here with Redwood. Something I'd be curious about is we find that it's enabling for front-end developers, but I also notice it's a good middle ground for front-end and back-end devs to meet in the middle. I'm curious if, in the stuff you work on, you also see back-end devs who see it as a way to get more connected to the front end, or do you think it's really just front-end devs coming in through these technologies?

00:03:46 - Nader Dabit

No, I mean, there are certain areas within these systems that, in some circumstances, require a back-end developer's expertise to understand how to do more advanced things. Back-end developers especially thrive in these situations.

The real benefit is it's not only for front-end developers. Back-end developers are able to more quickly build stuff. But let's take DynamoDB, for example. That's a technology I work with a lot. If you're a front-end developer, you can probably use an abstraction on top of DynamoDB to get up and running and build out a CRUD application. But once you start getting into more advanced scenarios and need to take advantage of different data access patterns, global secondary indexes, sort keys, and things like that, it becomes more advanced. A back-end developer would probably be able to spin up this full stack application using these technologies, but when they were faced with that more advanced scenario, they would probably solve it a lot faster.

[00:04:48] I look at it like React Native, which is a different abstraction that I specialize in as well. JavaScript developers can get up and running quickly, building a cross-platform mobile app with React Native. But a native developer needs to be around to solve the tough issues where you need to bridge native code to JavaScript.

I see the same thing in a serverless environment or workflow, maybe even a team that focuses on building this way. You have developers who can build full stack serverless by understanding the front-end layer and how to take advantage of these APIs. But you might also need a back-end developer around, because when you run into more advanced scenarios, you still need someone who understands how to do that.

[00:05:40] And that becomes especially important there. But I also feel like back-end developers can focus on more important stuff. They're no longer just building CRUD APIs or the same authentication layer over and over. They're able to focus on more important tasks and business-differentiating things than they would in the past.

So I don't think it's like people sometimes hear this and think, "Is this going to take away the job of a back-end developer?" No. I think it's going to make back-end developers even more important while making front-end developers more useful and able to do more things.

But while it's lowering the barrier to entry for cloud computing for front-end developers, when you come into this space as a brand new developer, it is another thing you end up seeing, and it makes the whole front-end world look a little more confusing, right?

[00:06:34] We have to be really careful about the way we talk about this stuff. It's not something I feel like every developer should get into, but once you become comfortable as a front-end dev, this is a great next step to accelerate your career and take it to the next step.

00:06:50 - Anthony Campolo

Yeah, that makes a lot of sense. I usually say don't jump straight into these meta frameworks until you've played around a little bit with something like Create React App. Everyone hears about these tools, but you have to educate people about what they're for and why you'd even want to use them.

You have a pretty cool role doing DevRel and leading a DevRel team. I want you to talk a little bit about your role. You're on the Amplify team, so what do you see your role as, and what is your day-to-day like?

00:07:26 - Nader Dabit

AWS is broken up into separate organizations. You might think of Alexa as one org. There's the containers organization, serverless, and then my team is the front-end web and mobile organization. We're kind of the only team that is specifically focused on front-end and client-side technologies. We have a lot of front-end devs within our organization, a lot of great engineers building out client-side SDKs and libraries for front-end developers.

I think this is something to throw out there, because when people think of AWS, a lot of times they don't think about front-end development. But a large number of people within our organization are front-end devs, and they're building front-end tooling and stuff like that.

When I started at AWS a little over three years ago, the goal was to have some type of abstraction and entry point into cloud computing for developers that were traditionally front-end developers or developers that wanted to get up and running quickly with a back end on AWS but did not want to learn all of AWS.

[00:08:26] When I joined, Amplify was a client-side JavaScript library that had launched maybe one month prior. I joined in January of 2018. Amplify launched in December of 2017 or maybe November of 2017. At the time, it was just a JavaScript client-side library.

Over the last couple of years, it's evolved. Now it's also a CLI that allows you to spin up cloud infrastructure. We now have a GUI, a graphical user interface, that lets you create tables and authentication and wire all this stuff up together. We have a hosting service for static sites. It's grown into this tooling suite that allows people to do this sort of thing.

[00:09:18] The role of a developer advocate depends on which team you're talking to and what their goals are as a developer advocate group or person. For us, it's changed over the last couple of years.

At first, no one really knew about Amplify at all, so we focused on awareness. Ultimately, we want to build something that makes people successful at building apps easily. Once we got awareness, our focus moved to improving the developer experience and improving the product.

A lot of the work we're doing now is listening to customers, companies, and startups that are using this stuff, taking the feedback, and channeling it back to the engineering teams. We give them the pain points people are having so they can improve that and improve the product itself.

[00:10:23] At some point, once you get enough people using it, you don't have to worry as much about awareness because people will share their good and bad experiences, and that takes care of itself. Now we just want to make it a good experience, listen to what people want, and build that for them.

00:10:42 - Christopher Burns

One of the things I always like to ask is what's the use case? As I understand it, Amplify is an architectural platform that simplifies AWS through a CLI or a web interface. But my big question is, is this something you need to adopt at the start, or can you adopt later and incrementally?

00:11:11 - Nader Dabit

Yeah, that's a good question, and we get it a lot. You can adopt it incrementally. You can adopt it all as a greenfield application. Of course, you can also use one or the other. You don't have to use everything that's part of Amplify.

When you break it apart, let's say you're an app developer and you want to build something on AWS. There are a couple of things you need to take into consideration. First, what platforms are you targeting? Are you building for native iOS, or are you building for web? The next thing you might take into consideration is how you're going to build your infrastructure and allow your team to iterate on that infrastructure.

A lot of people, when they think of AWS, imagine going into the AWS console and clicking around and creating stuff. But in the real world and in most production engineering teams, people are using infrastructure as code, and infrastructure as code can be written in a bunch of different ways.

[00:12:05] CloudFormation was one of the original ways people were doing it in the last ten years or so. There's been a lot of improvements there. You've seen things like the Serverless Framework come out, CDK, Terraform, and a few other great ones as well from other companies.

What people are actually using now in production is some type of infrastructure as code provider. So you need to understand what you're going to use for your infrastructure as code. How are you going to interact with those services once they're created? How are you going to iterate on those things? When you take those into consideration, you can look at the tooling that's available to you. That's where we're trying to fit both of those needs.

First, the infrastructure as code. If you're a new developer to AWS and you look at a CloudFormation file, you might see a file that contains 1,000 or 10,000 or maybe even 100,000 lines of configuration.

[00:12:58] When I first looked at that, it was extremely confusing. It was verbose, and it was confusing because I didn't know what any of it meant or did. I think a lot of new developers coming into AWS get that same confusion.

So the goal for our team is to abstract that away and make it much easier to consume. Like I mentioned earlier, Serverless Framework and CDK do a pretty good job of this. But with Amplify, you don't have to know anything about the underlying services. We walk you through it in a CLI interface and now in a graphical user interface. We give you names that make a lot more sense to most developers.

Instead of saying Amazon Cognito user pools and identity pools, which doesn't mean anything if you've never heard of it, something like authentication makes sense. So we're like, "Okay, I want to add authentication," and then we just do that for you.

[00:13:50] Then we walk you through a bunch of steps and give you some default configuration. We generate that infrastructure as code for you, and you deploy it using an Amplify CLI command called push. That deploys your infrastructure. Then you iterate and push updates from the CLI. We generate all that infrastructure as code, deploy the services, and you're done at that point.

Then you have the client libraries that need to interact. When you're working with something like Cognito for authentication, or GraphQL/AppSync, you need to take into consideration things like making API calls and managing tokens. How do you manage refresh tokens, identity tokens, access tokens, and all that stuff? How do you authenticate and authorize a user on the server? There's a lot to consider there.

The client libraries take care of a lot of that work for you as well, both on native platforms like iOS and Android and on cross-platform.

[00:14:52] So we support Flutter, React Native, and web. The idea is we're giving you tooling both for infrastructure-as-code provisioning and deploying, as well as the client-side libraries.

We're combining everything into a category-based naming system. Not only are you working with the authentication layer on the CLI, but you're also using the same naming convention on the client. So you're like, "Okay, auth matches auth," and I want to sign in very declaratively. It's very understandable for most people.

It is an abstraction on top of AWS, but it's a little different than some other abstractions. I'm not going to say one's better than the other. I think Amplify is great, but I'm also a big fan of Serverless Framework, Terraform, and CDK. There's a huge pie, and it depends on where you are as a developer, what you like, what makes sense for you, and picking the tool that works best for the job.

00:15:44 - Anthony Campolo

Yeah, I think what Chris is getting at is he's curious what a canonical app would be that you'd want to build. Is it good for a shopping cart or a chat app or something of that matter? What is it that you'd actually want to build with it?

00:16:00 - Nader Dabit

We see all types of customers building all types of stuff with it. Any app you can think of, you could probably build with Amplify. I can give you a couple of examples.

Orangetheory is a fitness company. At the beginning of the pandemic, they had to switch their business model to a remote version of their on-site fitness. They wanted a way for people to exercise at home but still follow along. They were able to build and deploy an application in about two weeks using Amplify, and then scaled it out to all of their customers. This was a web application. It took them about two weeks to build.

I met with a startup recently. They had an idea for a company, a combination of Clubhouse and Twitch. It's kind of hard to explain exactly, but they needed a combination of live streaming with voice and a chat functionality. They were able to build that and get a pretty good proof of concept out in a short period of time.

There are some limitations of Amplify as well. Let's say you want to build the next Facebook or something. You're probably going to run into a point where you're limited by what Amplify offers. But under the hood, since Amplify supports CloudFormation, you can extend what Amplify does.

[00:17:44] A lot of times people reach that limitation, and then they end up having to write their own CloudFormation. It is a little tough right now, and that's one of the focuses of this year. We want to make it extensible and able to support all of AWS.

But when you think of a data layer, that's the main thing people are interested in when they're building an app. When you think of a modern application, you might take into consideration things like data access patterns, real-time functionality, and offline functionality.

The main data layer that Amplify supports is AppSync, which is a managed GraphQL service. We have a bunch of large customers using this in production. I think Ticketmaster was one of the first big customers using it in beta, and it scales out to tens of millions of connected clients in a GraphQL subscription implementation.

[00:18:41] A lot of people are using it for real time, and anyone that needs to build an application that needs real time, this is a great choice. Since AppSync is a GraphQL layer, you can map your GraphQL operations to any AWS service, any underlying AWS database, and also to other third-party microservices.

You can take your GraphQL query or mutation and map it to an existing microservice or an existing database living somewhere else. So let's say you're using MongoDB hosted somewhere else. People are still using GraphQL as that API layer.

00:19:15 - Christopher Burns

When you build an application, say we take a very typical application, how much functionality would you say AppSync and Amplify handle for you? User logins is one, but obviously subscriptions and live processing of data is another.

00:19:37 - Nader Dabit

When you look at the AWS suite of services, there's like 200, I think over 200 at this point. I don't know the exact number. We support a small subset of those. We support about 12 different services directly.

One of the services we support is Lambda. A lot of people use that as kind of the escape hatch into pretty much any other service. The main things people work with would be the GraphQL API layer; a REST API layer, which is a combination of API Gateway, Lambda, and DynamoDB, or just API Gateway and Lambda; authentication, which is Amazon Cognito; storage, which is Amazon S3; and functions directly.

You can use Lambda functions for other stuff like triggers. Let's say someone updates something in your database and you want to trigger a function. You can do that. We also have hosting, like static site hosting. We support machine learning services.

[00:20:31] About a dozen machine learning services are supported from Amplify. Another interesting one is XR, like virtual reality. Amazon Sumerian is there. I haven't seen a lot of usage there. In my opinion, it's not something a lot of people use in a real-world application, for the most part.

A few others are push notifications and pub/sub. But the most interesting thing to me, not only about Amplify, but even if Amplify never existed at all, is AppSync as the data layer. I'm super interested in ideas like AppSync. I would be interested and hopeful to see other cloud providers building similar things because I think they're super powerful.

With the GraphQL API managed by a cloud provider, you can map any GraphQL operation to any of the hundreds of cloud services out there directly. This is something I'm putting together talks and a blog post about, because when I first started using AWS, I saw all these cool things but didn't know how to build APIs around them.

[00:21:37] How do I actually use this machine learning service? It was really complicated because, as a front-end developer, I'm always looking for the entry point, like how do I send a call to this thing? It was confusing because the documentation at AWS isn't that good, in my opinion, and a lot of other people's opinions too. It's getting better for sure, but to be honest, you have to be honest.

Anyway, I'm interested in how to interact with all these different services. It turns out GraphQL is a perfect way to do this because you can map your operations into Lambda, and from Lambda you can grant permissions to talk to pretty much any service. So I was able to build out, for instance, a couple of weeks ago, a really basic Clubhouse clone. I got the base functionality up and running within about two hours using a service called Amazon Chime.

[00:22:28] It turns out all you need to do is flip on an IAM permission from Lambda to be able to start interacting with it. Stuff like that is super powerful and super cool to me. I'm really excited about those types of data layers.

00:22:40 - Christopher Burns

So what you mean is AWS has all this functionality, multiple services, etc., and you use GraphQL as a way to programmatically talk to each of these AWS services.

00:22:54 - Nader Dabit

That's right.

00:22:55 - Anthony Campolo

Yeah. We've talked about AppSync in a previous episode, episode nine. I did a deep dive into it because I agree with you. I think it's a really interesting technology, and it sits at a very interesting intersection of a lot of this stuff. It seems to have come out of the mobile world but has become more of a thing used by front-end web developers.

You actually tweeted about this once, how GraphQL is something that a lot of mobile developers had been using, and now some front-end developers are using. I responded to that saying I've never done mobile development at all, and GraphQL is a huge part of my toolchain. I'd be curious if you have any perspective on why these tools that were so useful for mobile are starting to leak out into these other areas.

00:23:44 - Nader Dabit

That's a good discussion point. When we first started AppSync, the main goal for our team was mobile. For a while we were called AWS Mobile. We thought this was the perfect layer for mobile apps, mainly for the combination of offline persistence, real time, and the ability to send smaller payloads across the wire, making it more performant.

But all of these performance gains and features are good for mobile developers and for any type of development. The development experience that comes along with GraphQL is really good. The sheer number of web developers is much larger than mobile developers, and I think we're seeing that overflow of people adopting it because of that.

A lot of people are building responsive web applications that might have different data fetching and different types of views based on screen size. That makes sense in those scenarios.

I don't really have a good answer. I think when you have something that works really well as an API layer, it doesn't matter where you consume it. Web developers are noticing that and using it.

00:24:55 - Anthony Campolo

Yeah. I was just curious to ask you that because I know you've done a lot of mobile development in your time as well. I used to host React Native Radio.

00:25:02 - Christopher Burns

My first, you could say, adventure into AWS was with a mobile app. I can see how we've borrowed a lot of this technology. It's useful for the web as well, and then you go, oh yeah, so it is, and then we've started going down that way.

My last question is, say you're a small business or a hobbyist or any type of business, what does it cost to use Amplify? Is it generous, free tier, or on top of AWS, or just each product has its free tier?

00:25:36 - Nader Dabit

The Amplify toolchain and framework are completely free. It's open source tooling on top of existing AWS services. The only Amplify service that actually costs money is the hosting service. Let's say you want to connect your GitHub repository and host your static site or website. That would have its own costs related to it.

There is a free tier for the first year. It's fairly generous. If you're interested in learning more about pricing, you can Google Amplify hosting pricing and that should show up. When you're using Amplify, you're using underlying services like DynamoDB, AppSync, and Lambda. So you need to understand which services your app is using, and then you can Google those prices or go to the pricing pages and it should show up.

But I think the most important point about pricing is that pretty much everything in Amplify is considered serverless or using a serverless model. The only things that are not serverless are containers, which I didn't mention, and Elasticsearch. Those two things are not serverless in the sense that if you deploy something, you're paying a monthly fee or monthly cost for those things to be hosted. But everything else is free unless you actually have users. If you don't have any users in your DynamoDB table and your AppSync API, it's probably going to cost you nothing. I think Cognito has a free tier of like 50,000 users or something like that.

00:27:03 - Christopher Burns

Yeah, I was just going to say if it's an abstraction on top of AWS, you'd probably need a finance officer, and you'd have to give them a very complex website to work out how much AWS will cost.

00:27:17 - Nader Dabit

Are you saying if someone wanted to build something using Amplify and they want to know the cost?

00:27:23 - Christopher Burns

Yeah, it's quite hard to predict.

00:27:26 - Nader Dabit

Yeah. I would say it's just like any AWS deployment. You look at the services you're using and you can get a general idea of the cost.

One way that works for me, though there are probably better ways, is to make a spreadsheet and say, "Okay, I'm using AppSync, I'm using DynamoDB, I'm going to have this many API requests, this many users, and they're going to be using it one hour a week." You can get a general idea.

There is actually pricing in some of these areas where they put together an example application that ties together a bunch of stuff and gives you a general idea. But typically you're in the really inexpensive area until you get into the tens of thousands of users.

00:28:17 - Anthony Campolo

The AWS spreadsheet.

00:28:24 - Anthony Campolo

You had mentioned containers versus serverless. This is something we actually asked about when he was on. I'd be curious to get your perspective as well, how you think about when you would want to use containers versus serverless with Amplify, or if you think there are good use cases for one or the other, or if it comes down more to personal preference or how you think about it.

00:28:48 - Nader Dabit

Yeah, I think it depends on the person, their philosophy, their expertise, and what their team is comfortable with. I don't think there's a right answer for everyone. But for me, I'm a big fan of serverless, and all the research suggests the industry is moving in that direction, so I'm going to focus on that.

If I'm working for a company and building an application, I'm going to take the serverless-first approach. Anything that I cannot fit into that paradigm, then I'll spin up some type of server and do that long-running work or whatever the reason is. But that's just my approach. I don't think that's the right approach for everyone.

I'm a big fan of serverless and finding something that works, specializing in it, and getting really good at it. That way you can pretty much solve any problem with your skill set. If you're focused on improving that skill set over a long period of time versus trying to understand everything, that's my approach.

[00:29:34] Serverless first. Anything that can't fit into the serverless paradigm, maybe you have a really long-running task, you might spin up a server somewhere to manage that.

00:29:52 - Anthony Campolo

Yeah, that makes sense. I always say serverless by default is how I think of it. It starts off serverless, and then you can branch out from there if need be.

I also understand why someone would want to go container-first, because in that sense your whole application is contained at the beginning and then you can break off different functions. Whereas starting off serverless by default or serverless first isn't super straightforward unless you have a framework that's geared specifically towards setting you up for that in the first place.

But that's kind of what I see a lot of the Amplify services doing, because you have all of this infrastructure-as-code stuff baked into it. That is what makes it easier to get into this serverless world. You can do the copy-and-pray thing, but it actually works because, as you say, the code creates a deterministic rendering of your resources.

[00:30:51] So it becomes code that is very portable and very shareable. You can get these full applications spun up with it really quickly. It's super interesting stuff that you're working on. It's super relevant to all the stuff we're doing here with frameworks.

The last thing I'd like to talk about is your series of tutorials. I think it's really cool how you show how to connect different front-end frameworks and even meta frameworks to Amplify services and the stuff that spins around the Amplify world. I'd be curious to hear how you think about those tutorials, how you pick projects, and how you prioritize that.

00:31:32 - Nader Dabit

The work as a developer advocate aligns really well with the things I like to do anyway. I like to tinker with new things and try new stuff out, so it's cool that I get to do this as a job.

I typically do a combination of listening to what people ask me to do or the questions people have on GitHub, along with my curiosity and the trends I see happening in the industry.

For instance, I started using Next.js. I thought it was really cool. I started seeing momentum there, so I was like, "Okay, let me create some content around this and learn how to use it pretty well." Now I feel like I know Next.js really well, and a lot of those videos have done really well. It depends.

It's typically a combination of feedback from customers who want to learn how to do stuff in a certain framework, along with the things I'm interested in and maybe where I see the industry headed.

00:32:20 - Anthony Campolo

Very cool. All right, I think we're getting close to the end of our time. Thank you so much for being here, and thank you for all the work you do. Your work is a huge inspiration to me. Seeing you expand out and build this whole team of other badass developer advocates is really cool. Thanks for always being out there and being a positive presence in the industry, communicating these ideas and all that stuff. Really appreciate it.

00:32:49 - Nader Dabit

Thank you. I appreciate you having me on. I appreciate the kind words. I had a question. Do you play the cello?

00:32:53 - Anthony Campolo

Yeah, it's the upright bass. There's multiple levels. The cello is kind of the tenor instrument in the orchestra, and the string bass is twice the size. That's why they call it a double bass. It's kind of hard to tell from the pictures.

Usually when you see someone play cello, they have it between their legs. Whereas in my picture, the headstock is up above my head because it's like six feet tall. That's kind of how you can tell the difference.

00:33:19 - Nader Dabit

I've seen your picture so many times, and I've always wanted to ask you that question.

00:33:25 - Anthony Campolo

Awesome. Why don't you go ahead and let the listeners know how they can find you? What's the best way to get in contact with you?

00:33:31 - Nader Dabit

Yeah, I'm on Twitter, I'm on Clubhouse, and I'm @dabit3 on GitHub. That's pretty much where I've been hanging out lately, those three places.

00:33:42 - Anthony Campolo

All right. Well, thanks so much.

00:33:43 - Nader Dabit

Thank you for having me. Have a good rest of your day, and thanks for listening for anyone that checked us out.