Amplify and DataStore with Shawn (Swyx) Wang

Episode Description

Swyx discusses learning in public, developer experience at AWS Amplify, and his thesis on the third age of JavaScript.

Episode Summary

Shawn "Swyx" Wang joins the Full Stack Jamstack podcast to share his journey from finance to tech through a coding bootcamp and how the concept of learning in public transformed his career. He explains that years of excellent work trapped in private employer inboxes motivated him to share his knowledge openly, leading to stronger networks and job offers based on reputation rather than resumes. The conversation shifts to his role at AWS Amplify, where he breaks down how Amplify simplifies the sprawling AWS ecosystem for front-end developers by abstracting away service-specific naming and providing a serverless-first deployment experience. He compares Amplify's approach to competitors like Netlify and Vercel, describing them as "cloud distros" that sit atop major providers, and discusses trade-offs between locked-down developer experience and access to underlying infrastructure. The discussion touches on containers as a universal deployment unit, the potential of Amplify's DataStore for offline-first and real-time syncing apps, and how tools like DataStore and GraphQL represent efforts to abstract beyond REST. Swyx closes by reaffirming his third age of JavaScript thesis, arguing that the next decade will consolidate fragmented tooling into faster, unified solutions as legacy browser support fades.

Chapters

00:00:00 - Introductions and What Is Developer Experience

The episode opens with lighthearted banter about how to pronounce Swyx before introducing Shawn Wang as a developer advocate working on developer experience at AWS Amplify. Swyx defines his work as spanning developer tools and developer communities, mentioning his time at Netlify, his open source advocacy, teaching on Egghead.io, moderating the ReactJS subreddit, and running a paid community around non-technical career skills.

The hosts and Swyx explore how content creation fits into the developer experience picture, with Swyx describing it as a natural side effect of everything he does rather than a separate job. Anthony Campolo frames developer experience as a spectrum between community and content creation, while Swyx suggests tools form a third pole, setting up the broader conversation about how developers can grow by sharing their work openly.

00:02:56 - Learning in Public and Career Transformation

Swyx unpacks his philosophy of learning in public, distinguishing it from traditional teaching by emphasizing that he writes notes for himself without slowing down for any particular audience. He traces the idea's roots back to Kelsey Hightower and even NASA's knowledge transfer practices, arguing that moving from zero to even five or ten percent public sharing unlocks outsized opportunities in networking and career growth.

He shares the personal catalyst behind this philosophy: years of outstanding research work in finance that disappeared into employer inboxes when he changed jobs. After graduating from Full Stack Academy and finding himself underused at his first engineering role, he began blogging and speaking at meetups, which quickly became a greater source of learning than his workplace. He describes how a public body of work renders traditional resumes and interviews nearly obsolete, with employers already knowing what a candidate can do before the conversation even starts.

00:10:32 - Practical Advice for Content Creation

Christopher Burns raises the tension between building a product and documenting insights publicly, acknowledging that as an entrepreneur he struggles to find time for writing. Swyx responds with pragmatic advice: timebox it, skip the polished introduction and conclusion, and ship a rough core insight in five minutes using a tool like Loom rather than aiming for a perfect blog post.

The group discusses how the biggest barrier to content creation is the belief that every piece must be substantial and polished. Swyx advocates for starting with a stub and fleshing it out only if there is demand, treating blog posts as living documents rather than one-time publications. He emphasizes that the most effective posts are often the shortest ones that go straight to the solution, saving readers from wading through unnecessary context.

00:13:34 - What Is AWS Amplify

The conversation pivots to Swyx's work at AWS, where he explains that Amplify is a dedicated team focused on making AWS accessible to front-end developers. He describes how Amplify abstracts away AWS-specific naming and complexity, letting developers add authentication, storage, or analytics with simple CLI commands instead of navigating hundreds of services and configuring VPCs or IAM policies.

Swyx positions Amplify as a superset of what Netlify and Vercel offer, noting that it is ideal for companies already invested in AWS infrastructure who want a streamlined developer experience without migrating to a separate billing system or identity provider. He highlights the breadth of curated services available, from GraphQL gateways to SQL and NoSQL databases, all unified under the same cost controls and deployment settings, and mentions potential integration points with Redwood.

00:19:28 - Cloud Distros, Containers, and Deployment Models

Christopher shares his frustration with raw AWS complexity, prompting Swyx to distinguish Amplify from what he calls "cloud distros" like Netlify and Vercel. He explains that Amplify scaffolds CloudFormation resources that persist independently, whereas second-layer providers create a tighter abstraction users cannot easily eject from, each approach carrying different trade-offs around flexibility and simplicity.

The discussion moves into containers as a deployment unit, with Swyx highlighting Amplify's recent launch of container hosting that lets developers run frameworks like Rails alongside serverless functions. He argues that containers offer a standardized learning curve compared to each provider's custom configuration, and the group debates whether frameworks could auto-Dockerize projects. Swyx references Netlify's massive open source Docker build image as an example of how complexity gets swept under the rug rather than eliminated.

00:29:10 - DataStore, Local-First Apps, and Abstracting REST

Swyx introduces Amplify DataStore as a local on-device replica of a remote DynamoDB database that enables offline CRUD, automatic syncing, and collaborative editing out of the box. He compares it to Meteor's Minimongo and contrasts it with Apollo's cache, arguing that DataStore eliminates the need for developers to manually write optimistic updates, conflict resolution, and retry logic.

He presents his broader thesis that GraphQL, React Server Components, and DataStore all represent different strategies to abstract beyond REST, which he sees as the wrong level of abstraction for modern app developers. The conversation touches on React Query, Redwood's evolving client-side data layer, and how bundling authorization models with data access creates a significant advantage for integrated platforms like Amplify over piecemeal tool combinations.

00:35:24 - The Third Age of JavaScript and Closing Thoughts

Swyx revisits his third age of JavaScript thesis, explaining that the first decade built out the language, the second decade established tooling like Node, NPM, Babel, and Webpack, and the current decade is about consolidating that fragmented toolchain into faster, unified tools. He points to esbuild's dramatic speed improvements over Webpack and the slow death of IE11 as key catalysts for this shift.

He acknowledges that ecosystem churn will continue but frames it as an opportunity for open source developers to build the next generation of tools free from legacy constraints. Anthony Campolo wraps up by praising Swyx's historical perspective on web development and encouraging listeners to follow his writing, while noting that the conversation barely scratched the surface of topics they could have explored together.

Transcript

00:00:00 - Christopher Burns

Do you prefer to go by your actual name or S-W-Y-X?

00:00:04 - Shawn "Swyx" Wang

Whatever you feel comfortable with: Swyx or Shawn.

00:00:06 - Anthony Campolo

I would usually say Shawn Wang, popularly known as Swyx on the internet, and get both of them in there.

00:00:11 - Christopher Burns

Is that how you actually say it?

00:00:13 - Shawn "Swyx" Wang

Yeah, there is no other way. People are always unsure, but there's no other way.

00:00:17 - Anthony Campolo

I know, right? To me, it's always been a fairly intuitive pronunciation. It's like Swix, like Swix. Duh. Like you said, how else would you pronounce it?

00:00:36 - Christopher Burns

Welcome back to FST. Today we've got a really exciting guest, Shawn Wang, also known as Swyx on Twitter. He's a developer advocate working on developer experience.

00:00:47 - Anthony Campolo

Developer advocate who works on developer experience is probably how I would describe it.

00:00:52 - Christopher Burns

I hate these terms. He's a developer advocate who works on developer experience at AWS Amplify. Welcome, Shawn.

00:01:01 - Shawn "Swyx" Wang

Thanks for having me. I can fill out my intro if you need to, or we can just get right to the topics.

00:01:07 - Anthony Campolo

I'd love to get how you describe yourself, because, as we're saying here, these terms are a little bit fluid. I struggle to define exactly what I do as well, but I think you and I are kind of swimming in the same boat in terms of the work we do. So I'd really love to hear how you describe your work.

00:01:22 - Shawn "Swyx" Wang

I like to describe it as working on developer experience in general. The two things that kind of fall out of that are developer tools and developer communities. Most recently, I was at Netlify. My job title was literally Developer Experience Engineer. I do a lot of open source advocacy and research. I don't maintain any big, popular open source tools, but I'm basically friends with all of them. I do a lot of writing about them, teaching on Egghead.io as well as on my own personal blog, and then a fair amount of community work. I helped to moderate the ReactJS subreddit, helping it to grow to over 200,000 members. And then I left. I started this Felt Society meetup. That's a growing community now. I'm also managing my own book community because I wrote a book last year. It's a paid community for people talking about the non-technical aspects of technical careers. That's been doing pretty well as well. I think the summation of it is that developer experience is a holistic approach in terms of the tooling as well as the people.

[00:02:22] I'm pretty interested in both sides.

00:02:24 - Anthony Campolo

Yeah, I usually think of it in terms of two poles, but you're actually helping me think of it more as a three-pole kind of thing. I usually think of it as community being one end and then content creation being kind of the other end, where it looks like you're thinking of community on one end and tools on the other end. And for you, I guess content creation is kind of for all of it. Yeah.

00:02:42 - Shawn "Swyx" Wang

My approach is to just try to treat it as side effects of everything that I do. It works better if you don't treat it like a job. You just treat it as a thing that you do normally anyway. It's like breathing. You don't think about breathing as a separate job. You just breathe.

00:02:56 - Anthony Campolo

You are known for learning in public. It's kind of your catchphrase that you've really spent a lot of time getting out there and explaining. What is this? I'm someone who used to be a teacher, and as a teacher the feedback loop between teaching and learning yourself is baked in. You can't teach without learning. So when I first heard you talking about this, I was like, oh, so you're saying you're a teacher.

00:03:19 - Shawn "Swyx" Wang

I would never say I'm a teacher. I just write my notes, the notes that I wish I would have had. Sometimes it's useful just for myself, and sometimes it's useful to others. The assertion is that you do a much better job of it, you learn a lot faster, and you grow your network a lot faster if you do it in public. The default that we've been taught in schools is to do everything in private because schools have a very zero-sum view of the world. The reality is the world is very positive, so you should treat it that way.

00:03:45 - Anthony Campolo

It's one of the things I find that people have a hard time wrapping their minds around, what teaching actually is. That's why I feel like there's a huge disconnect between, like you say, what you do and what is considered teaching, because our school system has warped people's minds.

00:03:57 - Shawn "Swyx" Wang

I don't call it teaching because when you're a teacher, you have responsibility for the student to learn something. That necessarily means sometimes you slow yourself down to match the pace of the student. I don't really care about that. You're either with me or you're not. And it's fine if you're not because there's someone else who's going to be more your speed. I'm just going to do my best. Those people who sort of vibrate at the same frequency as I do can follow along. The rest, it's not a fit, and I'm not going to change who I am just to cater to a particular student audience. I mean, I can if I want to, right? I just don't think that is the best use of time sometimes.

00:04:33 - Christopher Burns

I sometimes question, with learning in public, what your experience was before you started learning in public, and whether it was institutionalized. So you've already walked out with a computer science degree, and now you're learning in public, or you're starting from nothing and you're learning in public.

00:04:50 - Shawn "Swyx" Wang

So first of all, I don't have a CS degree. I went through a boot camp. My previous career was in finance. I worked in investment banking and hedge funds. Some of the best work of my life I did in those hedge funds and banks, and I'll never see that again. I wrote my research reports and my investment thesis, and my boss was super impressed with them. He sent me warm, congratulatory messages about some of the really good stuff that I did. And now it's gone. I will never have it again. No one ever saw it. It just sat in my boss's mailbox. And then we both moved on to different companies, and now it's just gone forever. That's a really deep experience that really cut to my core because that's five or six years of my life I'll never see again. And I don't want to live like that. That's a fundamental desire for me to live life in higher resolution than, "this is just a job, and whatever I do is property of my employer."

[00:05:44] I think tech is a fundamentally more open industry than finance, and so I'm embracing that as much as confidentiality and all that will let me. So definitely open source and this whole movement of building in open and learning in public is really helpful. But I didn't really get this religion, if you can call it that, until I graduated from my boot camp and I was in my first software engineering job post-boot camp, and I was very underused. So I actually just started blogging and speaking at a meetup just to learn stuff because I was not learning at work. And that actually became a bigger source of learning than my workplace. And then I realized this is the kind of teaching that I can create for myself and the opportunities that I could create for myself if I did this in public.

When you limit yourself to just the current employer that you work at, then it's really like a roll of the dice, because some of them, you know, I did not have a good mentor, and I would have been stuck with this guy if I didn't put in the effort to find mentors outside of work.

[00:06:40] It started working for me, and then I just kept at it. And now I'm about three or four years in. The majority of the job offers that I get are all through my relationships. It's a fundamentally different thing to have someone sit down and interview you and say, "Oh, this is just a formality because I Googled you, and you're the kind of person we're looking for." And that's because there's nothing left to prove. If you learn in public, you go so much more high-definition than just the CV, because the CV is very lossy. If you think about compressing years of my life into this one page and hope that the other side has the same key to unlock it and decompress it to see if it's a match, it's such a ridiculous game. And let's not just talk about the CV. Let's talk about the interview as well. Set up some artificial 30-to-45-minute scenario where you can show us your coding skills. Why not do more than that?

[00:07:28] Basically, show this body of work that can really give the full impression of what you can and cannot do. The more I explore this idea, the more I fell in love with it. I would not push it so hard if I didn't truly believe that people would benefit from it. It's not my idea. I got it from Kelsey Hightower, who's sort of Mr. Kubernetes. I'm sure he got it from somewhere else. The earliest mention I can find of this actually goes back to NASA, which uses learning in public as a form of knowledge transfer within the organization.

It's an idea with a very strong intellectual history, and there are a bunch of reasons why it works. I think developers would be well served to do it. And I'm not saying to put yourself out in public 100% of your time and to live-tweet every single thought going through your head. Nobody wants that. But the default is zero, and you probably want to go from 0 to 5 or 10% public. That will open you up to a lot more luck and learning and networking than you had before.

00:08:23 - Anthony Campolo

You did Full Stack Academy, right? That was your boot camp. Yeah, yeah, because I had heard of Full Stack Academy because they actually put out a lot of really fantastic short YouTube videos of people giving presentations there. And so it seemed to me like they were kind of more focused on actually teaching their students what advocacy is. Did you do any of that when you were in Full Stack Academy, or was this stuff that you got after your boot camp?

00:08:47 - Shawn "Swyx" Wang

I mostly got it after. The videos are kind of a portfolio piece, but they're not done with the purpose of doing advocacy. It's just a way to present your work.

00:08:57 - Anthony Campolo

Yeah. It's just a nice kind of side effect of that, I guess. Did that kind of push you more in the advocacy direction?

00:09:02 - Shawn "Swyx" Wang

There is a video of me. It's not very good, but there is a video of me presenting my projects somewhere. It's a great boot camp. The thing that I got from them is to focus on systems over goals. Setting goals alone just doesn't really tell you how to get them. You need to focus on a system anyway. And then once you're focusing on a system so much, you don't really care about the goal, because all you have to do is keep working on the system to be better than you were the day before, and that's all that matters.

00:09:25 - Anthony Campolo

Yeah, my music teacher, Stuart, called it process, not product. That was the term we used.

00:09:30 - Shawn "Swyx" Wang

Sure. Different names for the same thing.

00:09:32 - Christopher Burns

So one of the things that I always think about learning and teaching in public is it works both ways. As you said, it shows that you're worth a lot more than just what's on the CV. But then you're also teaching other people how to follow your path. How many times have we come up against a problem and gone, "Am I the first person to be figuring this out?" And then you solve the problem. You don't actually document it. And if you then do document it, is that in private or is that in public?

This is the thing that I have to hold up my hands and say I struggle with for multiple reasons, because the product I'm building, I believe we're doing a lot of firsts with what we're doing with Redwood. There's so many things, like I need to write a post, how to do that, I need to write that, I need to write that, and then I just get lost because I'm so focused on the point of building. But I understand that's very unique to an entrepreneur developer compared to someone that's working for a company.

00:10:32 - Shawn "Swyx" Wang

Yeah, there's a lot of stuff there, I would say. I mean, Redwood is still so new that you may very well be the first person running into this stuff, and it would be very valuable. But don't feel the pressure to do it. You do have a day job already, which is trying to build this company. You limit yourself to what you can do, right? I think you should just fundamentally internalize that you're not going to produce at the level of professional content creators.

But like two to three minutes from you on the core insight, just as a screen share, right? I really like the idea of Loom. Loom is this app that just lets you record and share video clips. Just five minutes from you showing the insight, a good title that people can search, some code snippets that people can copy from, that might save someone hours and days of just searching around, and they may connect with you and they might work with you in the future.

[00:11:21] You never know. But if you just kept it to yourself, then it will not happen. That's the one thing that's for sure. So I think if you timebox it, okay, I only have five minutes, 30 minutes, let's put down the most important things I learned in this period and then just do it. And whatever you end up with, you just have to ship it. You don't give yourself some choice that it has to be perfect or like a super well-written blog post with introductory context and an end conclusion. Get rid of all of that. Just go. Core insight, done. Next, move on.

00:11:52 - Christopher Burns

Step one is the first bit of code. Step two, here's the second bit. Step three, run it and have a look at this post.

00:11:59 - Shawn "Swyx" Wang

Even that may be too much effort, right? Literally, sometimes you just have to go, like, I was doing this and then I tried this other thing and it worked. End of story. And sometimes those are the best blog posts because they're straight to the point. You're not telling me about your day. I don't care as a reader.

00:12:13 - Anthony Campolo

I think that's really the hardest thing for people. Getting started in content creation is this idea that it has to be this big thing, and it has to be really involved, and it has to be perfect.

00:12:22 - Shawn "Swyx" Wang

Yeah, we copy what we see in others, and sometimes that's important. Sometimes the context and the introduction is important. But if you're going to do this every day, get rid of it. Only do it when it really matters. In fact, I see a lot of people do this. They'll start out with a stub with the core. If people see a lot of demand for it, then they'll flesh it out over time.

A blog post is not like this static thing that you write on that day and you never touch. You can start out with a stub and then flesh it out if people want more. But if people don't want more, then why are you investing so much effort up front?

00:12:53 - Anthony Campolo

People want a lot more SvelteKit according to my blog metrics.

00:12:58 - Shawn "Swyx" Wang

It's just a new toy.

00:12:59 - Christopher Burns

The State of JS just came out, and Svelte was on top for "most want to use." I think it was the highest satisfaction.

00:13:07 - Shawn "Swyx" Wang

And then there was another one, highest interest for learning, something like that. It's doing well. What's funny is I'm invested in Svelte's success. I think React is great too. I'm at a point where I'm not going to make money betting on either. As long as I can use either one of them, they're both great. I can make user interfaces with them. Let's talk about other stuff that actually helps me make money as an entrepreneur or developer.

00:13:34 - Anthony Campolo

Yeah. You're in a very interesting position in your job at AWS. I'd like to get into this because this is something we're really passionate about. This is, of course, the Full Stack Jamstack podcast. When I look at the kind of areas you're spinning around with AWS, to me it's very full-stack-focused and it's very much in the same kind of ideas of what we're trying to enable here with Redwood, and a lot of tools, a large suite of things you're kind of working on. To me, I personally think of it as Amplify's big bucket. You may or may not agree with that, but I'd be kind of curious, for my sake at least, to start there and say: what is Amplify?

00:14:12 - Shawn "Swyx" Wang

Sure, Amplify is like a dedicated team to solve front-end developer-specific issues using AWS. AWS is an existing bundle of services, something like 200-ish services, solving problems at all sorts of scale for all sorts of customers. The problem is, you kind of have to go to nine months of cloud school to even get anywhere doing that, and it doesn't really resonate with front-end developers when I talk about VPCs and IAM policies and stuff like that. And that's fine.

Companies like Netlify and Vercel have really paved the way to the kind of workflow that front-end developers like, which is very minimal DevOps and as much business logic writing as possible. And then you just push to Git and it deploys. That's a very fundamental concept of Jamstack, and I think that's something those two startups have really pioneered. The main thing that Amplify does is essentially help you do that with AWS tools.

[00:15:10] So the idea is that if you're a company that already is primarily on AWS and you want to have that kind of developer experience without using a separate startup's cloud, separate billing process, or separate identity system, like you already have an existing database that you want to plug into AWS, or you already have an existing identity system with all your customers already on it, you don't want to replicate that to some other random system just to have a different developer experience. So Amplify is there to smooth out the developer experience for front-end developers, even right down to the point of abstracting away the AWS-specific naming.

So instead of saying, "Oh, I want to add Amazon Cognito to my service," you just say amplify add auth, and that's the CLI command that you type for adding authentication to your app. Or, "I want storage." Okay, amplify add storage. And you don't really have to know about S3, even though that's eventually what you're going to get.

[00:16:08] There's a full set of services that are available. And I think that's something I really like about Amplify, which is that they really just go all out because AWS has so many great services. It's kind of like the best of the best. They curate the services for you. So there's a solution for analytics. There's a solution for GraphQL gateways. There's a solution for NoSQL databases as well as SQL databases. It's all on the same platform. It's got the same cost control measures. It's got the same environment and region deployment settings. And these are all proven at scale at AWS.

I really like this alternative that is available, and I think probably we could do more with Redwood.

00:16:47 - Anthony Campolo

I've talked to Nader a couple of times about it.

00:16:49 - Shawn "Swyx" Wang

Yeah. The thing is, the problem with working on such a broad platform is that you never really know what to collaborate on because, apart from Redwood, there's the Vue ecosystem and the Angular ecosystem. They all have legitimate claims. For us, as long as we identify where you put your build artifacts and where you put in all the UI-specific components that we offer, that's about it. If you know JavaScript, then you know all the other things that you can provide. And it's kind of up to you with your specific meta-framework or whatever to plug into that hosting platform.

So I'm not too concerned about it, but it'd be nice. The thing about Redwood that always stuck with me, right? Even when I was at Netlify and I wrote the world's first blog post on Redwood, you're following along the tutorial and you're deploying to Netlify and all that. It's great.

[00:17:35] And then you need the database and they're like, yeah, go to DigitalOcean and spin up something. And I'm like, that's not what I want, right? So, you know, ideally Redwood would have a host, one place to handle everything. I think that would be a nice ideal. Tom Preston-Werner has mentioned stuff about this before, but it seems like Netlify hasn't gone that way yet.

00:17:53 - Anthony Campolo

You hit on so many great things in there explaining what Amplify is. To me, it's a lot like explaining what Redwood is because it's hard. It's a lot of things, and it's also doing a lot of things for you potentially. But at the same time, it can't do everything, so you have to know what it does for you and what it doesn't do for you, and what options you can have with it, and how you can finagle it around with other tools and things.

I'm happy to hear that you're interested in getting more integration there because I agree, I think it's at this point where there still needs to be some more things kind of ironed out in Redwood in terms of how the auth fits in and how to get it to work with NoSQL. That stuff is going to be a little complicated, but there's definitely a lot of potential there in terms of how they could interop.

00:18:37 - Shawn "Swyx" Wang

Yeah, Amplify is NoSQL by default, but we do have an integration with Aurora SQL. That's an option. Yeah, Amplify is also super full stack. It's hard for me to even identify what it doesn't do because we just launched container hosting. So you can run Rails on Amplify. Then there's really no limit. So, I mean, that's decidedly not Jamstack, but it's really stretching this idea of what serverless even is, because the deployment paradigm really is the same as a serverless function. It's just that instead of deploying a simple Lambda function, you're actually deploying a container. That's wild.

But yeah, I mean, Amplify is really stretching it based on the existing capabilities of AWS. And I really like that idea. Honestly, to me, I'm also just trying to learn. I think every developer, you can't go your whole career without knowing at least some AWS. So I think this is a really great job to do that with.

00:19:28 - Christopher Burns

I have an interesting opinion about AWS. It's just too complex. So I've gone through three iterations to find what we're building now, and the first iteration was all built on AWS three years ago now, so I don't even think Amplify was a thing then, but you just got lost in all the connections.

What I'm really interested in knowing about Amplify: is it almost a second-layer provider on the first layer? Netlify runs on Amazon, but that second layer gives a lot of peace of mind. Myself, personally, I don't mind that you run on AWS. I know I never have to worry about AWS. Is Amplify almost like a mask for AWS, or is it just AWS?

00:20:16 - Shawn "Swyx" Wang

It's the latter. I've actually written a blog about second-layer clouds. I call them cloud distros, distributions of clouds. Amplify is not that. It basically scaffolds out CloudFormation for you, which is the default language of Amazon. What that lets you do is that once you deploy with Amplify, it kind of goes away if you want it to, and you're just left with the AWS resources that you needed in the first place.

With Netlify and Vercel, you do have a startup that's in between, and you can't really easily port between that and the underlying layer, or eject to the underlying layer, if you needed to. There's one other startup that is doing this ejectable scaffolding, which is Begin, begin.com. They're really interesting experiments because it's this idea of how much do developers actually care about the underlying abstraction. The argument of Netlify and Vercel is that if you lock everything down and you don't let people escape to the underlying layer, then you're able to provide a much better user experience because they don't have that many things to configure and there aren't so many options.

[00:21:14] Whereas Amplify, if you look at the CLI, there's a ton of different options and there's a learning curve to that. So there are trade-offs all the way. There's a law of leaky abstractions. Basically, all abstractions leak. It matters what your approach to leaking is. Eventually it's going to leak. Either you let people know up front or you push it to later when they're going to find out at some point in time. But I don't think it's a hard rule. I think there's space in the market for both of these kinds of solutions.

But yeah, I do have a lot of thoughts on the second layer of cloud. Let's say there are three big clouds. There's more than three, but Amazon, Google, Microsoft. How do you make the fourth big cloud or the competitor cloud, which is what Render and Vercel and Netlify? That's the ultimate end game, which is you build the second-layer cloud, you get all the developers on them, and then you move off of AWS.

[00:22:01] You buy your own machines and data centers, and you build the fourth or fifth independent cloud. That completely blows away the sort of legacy AWS-ness that nobody loves. Nobody goes in, wakes up one day and goes, "You know, I really aspire to grow up to be an EC2 wizard." I think the end game is people want to build the next independent cloud. So maybe that's one way to do it. As far as AWS Amplify goes, it's just a tool to use AWS easier.

00:22:26 - Christopher Burns

Netlify and Vercel have really good abilities to onboard certain sections instantly. You never have to use Netlify or Vercel from the start. You can obviously transition to them later. Is Amplify kind of like something you need to use from the start, or you can pick up later when DigitalOcean is no longer good enough for you? Or at all?

00:22:47 - Shawn "Swyx" Wang

Could you repeat? I don't understand the premise of the question.

00:22:50 - Anthony Campolo

Can you migrate into Amplify? Can you migrate an existing project into Amplify? Is what he's wondering.

00:22:56 - Christopher Burns

Migrate, yes.

00:22:57 - Shawn "Swyx" Wang

Define "migrate."

00:23:00 - Anthony Campolo

Just lift and shift with no work whatsoever.

00:23:03 - Christopher Burns

From other services.

00:23:05 - Shawn "Swyx" Wang

To?

00:23:05 - Christopher Burns

You're saying "AWS alternative."

00:23:07 - Shawn "Swyx" Wang

You're saying you can do that for Netlify. That's your standard.

00:23:10 - Christopher Burns

In certain scenarios, it's just a front end that needs to be hosted somewhere. Netlify.

00:23:15 - Shawn "Swyx" Wang

Yeah. Yeah.

00:23:16 - Christopher Burns

Does that, you know...

00:23:17 - Shawn "Swyx" Wang

I'd say Amplify's capability is a superset of what those two offer. So that's a yes. But then, you know, my definition is very different. When you say lift and shift, when you say migrate, I'm thinking the full stack, non-Jamstack. It could be Rails. It could be Laravel. Yeah, that might take a lot more effort. But with enough elbow grease, you can migrate anything. So that's why I asked you to define migrating.

00:23:39 - Christopher Burns

Yes. Because, for example, and this is where Redwood is kind of going to a slight extent, they started with this is going to be run on serverless functions. If you want very, very good performance, you need to host something. You need to get a Node runner. I found that serverless wasn't quite cutting it. So then I had to learn PM2, boot it up on PM2, host an Ubuntu system. Every time you do those extra steps, you're adding an extra step of complexity.

00:24:12 - Shawn "Swyx" Wang

That's why I like this idea of containers as the deployment unit, because everyone can speak containers, and then all you have to do is fit your app into the container and then it's understood by everyone. Basically, all the Jamstack providers are essentially creating their own configuration system. It'd be nice if we all got together and sat down in a room and decided on one format. That's what Glen Maddern from Linc, which just got acquired by Cloudflare, is trying to do. The frontend application bundle is what he calls it.

00:24:38 - Anthony Campolo

Yeah. FAB. I first learned about FAB from Peter, actually, the Redwood developer.

00:24:42 - Shawn "Swyx" Wang

It's an interesting idea, with the only problem that it's so focused on Cloudflare Workers that nobody else can adopt it. For a spec to work, it needs adoption. This has no adoption apart from Cloudflare. And now Cloudflare has acquired it, so there's even less incentive to make it work.

Ultimately, what we've got to do is have this idea of containers for front-end developers. Maybe the spirit of Fab will live on, but I think for back-end services, for serverless, I really like this idea that we use Docker containers just like everyone else. That's something that Amplify released recently, which is this idea of serving containers in a similar deployment workflow as serverless functions. I really like it. It's something that I would explore for Redwood, given what you just said, Christopher.

00:25:22 - Anthony Campolo

Fargate was the first one that Peter was kind of looking at in terms of getting Redwood on a containerization-type thing. And I'm kind of curious about this because it sounds like Amplify is set up in a way where there are certain opinionated stacks already built into it, but obviously they want to give you flexibility.

Do you think of a canonical Amplify stack, or does that not jive with what you think of as Amplify? Do you think there is an opinionated Amplify stack, or do you think that you can have it be configured just as well to work serverless or, say, with containers?

00:25:55 - Shawn "Swyx" Wang

The answer is somewhere in between. So Amplify is very opinionated that you should use AWS. If you're not looking to use AWS, you should use something else. And then within AWS, Amplify is pretty opinionated that you should use the serverless versions of whatever is available within the AWS offerings. So it's kind of like best of AWS serverless offerings.

So even Fargate, which is the serverless containers thing, is marketed as part of the whole serverless offering, which is kind of blending this idea of what serverless even is. Why should your function terminate within five minutes or 15 minutes? Why can't it go for five hours or five days or 500 days? There's cost issues and all that. But when your infrastructure starts to leak implementation detail into your code and you're trying to code around it, that's when there's an opportunity to improve the infrastructure so that developers can express what they want and the infrastructure figures it out. That's the ultimate goal for Amplify.

And that's my answer for the opinionated people who think that, you know, serverless seems to be the deployment model people enjoy.

[00:26:52] It's not perfect, but it is improving every single year.

00:26:54 - Christopher Burns

My one comment with containers is: do you think the struggle with it is the creation of containers? Because every time I've used Docker, I found it very easy to pull containers through Compose, but actually creating containers and understanding that side of the ecosystem I found really hard to understand at the beginning.

00:27:16 - Shawn "Swyx" Wang

Yeah, well, Dockerizing. There are a lot of tutorials on that. The assertion is, what else are you going to do? What is the alternative to Docker, just because there is a learning curve? At least it's a standardized learning curve compared to a bunch of custom instructions that you have to learn every single time you approach a new project. So I don't know what the alternative is.

00:27:38 - Christopher Burns

Could it be done for you through one command, "Dockerize this," from a framework perspective?

00:27:43 - Shawn "Swyx" Wang

Sure. Maybe someone could build it. I'm not smart enough to have explored that yet, but if it doesn't exist, why doesn't it exist? Exactly.

00:27:51 - Anthony Campolo

Get kicking, Chris.

00:27:52 - Shawn "Swyx" Wang

It's one of those things where probably learning the thing is easier than coding some generalized tool that abstracts it away for everyone. I'm definitely on that side of the bucket. Yes, it took me some time to learn it, but it wasn't that hard.

00:28:05 - Anthony Campolo

Yeah, solving something for everyone instead of yourself, I think, will always be harder in all situations.

00:28:11 - Shawn "Swyx" Wang

Yeah, but I mean, that said, you know, never say never. People come along all the time and surprise us with their persistence. I think someone just has to feel the pain enough. And maybe people haven't felt the pain. Like Netlify, I don't know if you've seen Netlify's Docker image. It's essentially this giant Dockerfile that is just built up over like six years of existence. And it's essentially like the Dockerfile for all Netlify users.

00:28:34 - Anthony Campolo

Is that on the Docker repo?

00:28:36 - Shawn "Swyx" Wang

Search GitHub slash Netlify slash build image.

00:28:40 - Anthony Campolo

That is really interesting. I'll be interested in checking that out.

00:28:43 - Christopher Burns

Yeah, because you can build it locally. You could host the Docker yourself.

00:28:47 - Shawn "Swyx" Wang

And yeah, it's a way to debug.

00:28:49 - Anthony Campolo

It's just on GitHub. That's cool.

00:28:51 - Shawn "Swyx" Wang

Yeah. It's also on Docker Hub too. Yeah. And there are some blog posts about that. It's one of those things where you're just kind of sweeping the complexity under the rug. You're never really going to reduce it. Either the startup solves it for you, or someone else comes along and solves it in an open way. But that is often a bit harder because, by definition, they're not going to be making any money from it.

00:29:09 - Christopher Burns

Yeah.

00:29:10 - Anthony Campolo

Another thing I would like to talk about is a project I think you've put a decent amount of work into, which is DataStore. Can you say what AWS DataStore is?

00:29:19 - Shawn "Swyx" Wang

Ooh, yes. Okay. All right. This is great because I want to know what the Redwood perspective is. DataStore is a local replica of your remote database. For us, it's DynamoDB. It's an on-device local replica. So, in other words, this helps you do offline CRUD. It helps you make offline-first apps. And as a nice side effect, it also eliminates any need for optimistic mutations, like optimistic updates, because you're just coding against it directly. It also helps you sync live. If anyone else connecting to the same app makes updates, your client automatically receives it because it's like a publish-subscribe model.

So it really inverts a bunch of things that we take for granted in today's apps, which is very much request-response. And then all the state is kind of held in local state, or, sorry, the component state or whatever, or your Redux store. And the developer is responsible for writing all the syncing code and the invalidation code. What if we centralize all of that into a data store with very well understood syncing and conflict resolution and offline handling semantics that we could just use and code against?

[00:30:28] That actually reduces a lot of code, because you don't have to code for retries and failures and all that, and optimistic updates. And it produces a much better user experience because the app just feels a lot faster, which is really great. People who have been around the block in JS land will compare this to Minimongo from the Meteor ecosystem. And I would say that's basically exactly what it is, except that it's the AWS version. It's attached to DynamoDB, which is a very, very scalable database. I like it a lot.

There is one trade-off, which is the JavaScript bundle weight. So you do have to take care to code-split it and only use it where it makes sense. But for the weight you use, it's like 500 KB. It's not bad. It's a local, on-device data store for your app. So if you need anything that is offline-first and you want a very snappy user experience, I really like it.

00:31:14 - Anthony Campolo

Yeah, this is super interesting, and I wish we had Dom here because Dom talked about this on his episode, episode seven, Shipping Web Applications, how he wants to create what he calls a local-first application. And it's exactly what you just described. The type of thing he's looking for, it sounds like, is DataStore. It sounds like the way we're managing this is with Apollo's cache. I'm not sure how similar those things are, but at least that seems to be the tool we're using to try and approximate the ability to do that. I am not deep enough into the Redwood codebase to know about this, but I know it is a pain point that people are looking at in Redwood.

00:31:52 - Shawn "Swyx" Wang

So I have some familiarity with it, and I'd say Apollo's cache is still too manual. You still have to write your own optimistic updates, and you still have to decide what the invalidation is and if there's any conflicts. You have to decide that and you have to decide retries and all that as well.

We should just agree on what this behavior is and have some toggles of settings, like use this setting for this kind of use case and use this other setting for this other kind of use case. Obviously you can drop it down if you want to, but most people are not going to.

I really like the fact that it also does the live syncing with other devices, so you can do collaborative editing just right out of the box. Try doing that with Apollo Cache. I don't know where to get started. Here's the really big brain thesis. I haven't blogged about this, but this is like a preview of a blog post.

[00:32:35] What we're doing here is abstracting over REST. We basically realized that REST is not good enough for the developer experience. The amount of state management and code needed to deal with REST on the client side and on the server side is unnecessary. GraphQL is a layer on top of REST. React Server Components is essentially a new protocol that serializes React components down the wire, but it's another layer on top of REST because we don't want to deal with all this crap.

And that's also what Amplify DataStore and Meteor's Minimongo are: another form to bypass REST. You have your local data store, you interact with that data store and you do all your updates with it, and the data store just syncs with its remote counterpart and handles all that syncing. You're not responsible for any of that code, and that's really great.

So that's my core insight. I think that you spend a lot of time doing state management and data fetching and retries, and maybe what if we did not have to do any of that?

[00:33:27] And that's a wild simplification of how frontend apps are made today, I think.

00:33:32 - Anthony Campolo

I love that. I was having this argument on Twitter with Dan Shapiro the other day. He was like, what's wrong with REST APIs? I'm just like, what's wrong with like really no challenges whatsoever for you?

00:33:43 - Shawn "Swyx" Wang

They're not wrong because ultimately we're still going to probably use them under the hood. Or we could use WebSockets. It just doesn't matter. It's the wrong level of abstraction for app developers.

00:33:52 - Christopher Burns

I think in the latest Redwood update, Apollo is actually optional now as the default client. Nobody's taken the off-the-beaten-path route yet and replaced Apollo, but I'm looking at it in my startup and looking to convert to React Query as part of the stack. We'll see how that goes.

00:34:14 - Shawn "Swyx" Wang

Fun fact: I coined the term "stack" too.

00:34:18 - Anthony Campolo

That's so funny. I remember when I first saw that because I use The Stack and the full stack. Before I was doing the Full Stack Jamstack podcast with Chris, I had a newsletter called Minimum Viable Stack, and I was like, dude, just named a stack after himself. Next level. Happy to hear that you're the one who coined that. That's funny.

00:34:36 - Christopher Burns

I love how it is called The Stack, even though it's just three sections right now. It's not the full stack yet. Just three sections.

00:34:43 - Shawn "Swyx" Wang

Yeah. No, but Tanner's a good friend. He's prolific. I don't know how he does it because he has a day job too. He doesn't do this full time. React Query is really great. It solves the data-fetching problem in React. I just do think that it probably should exist one level higher in abstraction, with essentially your schema also on your local device. And if there's an authorization model together with your database, that's even better. That's something that Amplify definitely really invests in.

I think often access control should also come with your data. It takes a lot of integration to get that right. I think that's something that is probably a comparative advantage of Amplify compared to piecing together your own tools, because you're going to have to go there yourself if you want all that.

00:35:24 - Anthony Campolo

Do you have any last questions, Chris, before we close it out here?

00:35:28 - Christopher Burns

Do you still believe in the third age of web?

00:35:31 - Shawn "Swyx" Wang

Oh, even more now.

00:35:32 - Anthony Campolo

JavaScript.

00:35:33 - Shawn "Swyx" Wang

The third age of JavaScript.

00:35:34 - Christopher Burns

JavaScript.

00:35:35 - Shawn "Swyx" Wang

Yeah. So for those listening, this is this thesis that every ten years there's a changing of the guard in JavaScript. The first ten years were kind of about building out the language. The second ten years was about the tooling and the infrastructure. That's the ten years that just concluded from 2009 to 2019. 2009 was the same year that Node, npm, and ES5 were born. Pretty much the past ten years were about sort of realizing the consequences of that.

Now, the next ten years is about consolidating those levels of tooling. Why do we need to wire together ESLint and Prettier and Babel and Webpack and what have you? Why is that not all one tool? Why are we still building JavaScript dev tools in JavaScript when it's proven that esbuild is 100 times faster than Webpack? So there's all these questions that arise, and we can talk about Svelte versus React as well. There's all these questions that are kind of legacy assumptions.

[00:36:27] And I think one of the big drivers is the death of IE11, which is in a slow decline. It will be completely gone by 2030. That gives us a lot of opportunities for a new generation of tooling that doesn't have legacy assumptions and collapses together a bunch of tooling that has become industry standard.

Yeah, I think it's a lot of innovation and a lot of opportunities for open source developers if they want to, but also it's going to be a little bit tiring in terms of the churn of the ecosystem. But it's nothing new for JavaScript developers, and if anything, we've shown that we're very resilient to changes in our tooling.

00:36:59 - Anthony Campolo

Yeah, I think part of this churn is because there's such a historical bent in web development. Web developers aren't taught older tools, which makes sense because you really shouldn't, but you just need to know the context. That's why I love the blogging you do and the historical context you put into your writing. So we'll definitely link to that in the show notes. I think most listeners probably already know this. Why don't you let them know where people can find you online, where the best places are to read your stuff and get in contact with you?

00:37:30 - Shawn "Swyx" Wang

Sure. I'm active on Twitter, @swyx, and then my blog is at swyx.io.

00:37:36 - Anthony Campolo

Very cool, man. Thank you so much for being here. I got so much respect for the work you do and the stuff that you're kind of spinning around. It's fun. It's cool stuff. I love how much you get out and communicate these things. It really resonates with my values. So thank you for doing what you do.

00:37:53 - Shawn "Swyx" Wang

Thank you, and thanks for having me on.

00:38:26 - Anthony Campolo

Yeah, yeah. This is one of those things where I could talk to you for freaking hours about this stuff. So many things, so many rabbit holes. So many times I did not jump into a rabbit hole because I was like, we've gotta stay on track. We've got important things to talk about here.