Building Fullstack Jamstack SaaS with Mike Cavaliere
Mike Cavaliere discusses his book 'Cutting to the Jamstack,' React Native's cross-platform potential, Prisma migrations, and building full-stack SaaS apps.
Episode Description
Mike Cavaliere discusses his book 'Cutting to the Jamstack,' React Native's cross-platform potential, Prisma migrations, and building full-stack SaaS apps.
Episode Summary
In this episode, Anthony Campolo and Christopher Burns welcome Mike Cavaliere, a senior engineer at Echo Bind with two decades of experience in web and mobile development. The conversation opens with Mike's background, from receiving a Commodore 64 as a kid to building Baywatch.com in the late 90s, before pivoting into his current work across React, React Native, and Next.js. A significant portion of the discussion centers on React Native Web and its promise of true write-once, run-everywhere development, with Chris suggesting it could become a major force in the Jamstack ecosystem as frameworks like Redwood and Blitz pursue first-class mobile support. Mike then introduces his upcoming book, "Cutting to the Jamstack," which teaches readers to build and ship a full-stack SaaS photo-sharing app called Jam Shots using Next.js, Prisma, Chakra UI, Cloudinary, and NextAuth. The hosts and Mike trade perspectives on Prisma's evolving migration system, the challenges of image optimization across frameworks, database hosting options like Heroku and Railway, and the importance of authentication in modern full-stack frameworks. Throughout, Mike emphasizes the indie hacker ethos of shipping viable products with minimal cost using free-tier services, and the need for educational content that bridges the gap between individual tool tutorials and real-world application development.
Chapters
00:00:00 - Introduction and Mike's Background
The episode opens with some behind-the-scenes banter about how the FSJam podcast came together before Anthony formally introduces Mike Cavaliere. Mike shares his professional background as a senior engineer at Echo Bind, where he balances client engineering work with product development and content creation, including his upcoming book "Cutting to the Jamstack."
Mike then traces his journey into programming, starting with a Commodore 64 he received as a gift and continuing through a theory-heavy CS degree in the late 1990s. Frustrated by the gap between academic coursework and the booming web industry, he taught himself HTML, JavaScript, Perl, and early CSS, eventually landing freelance work that included building Baywatch.com. This self-directed learning ethos clearly carries through to his current focus on JavaScript across its many modern forms.
00:05:53 - React Native, Cross-Platform Development, and Expo
Christopher Burns steers the conversation toward React Native, and Mike discusses his hands-on experience with React Native Web, describing how its API mirrors React Native so closely that knowledge transfer is seamless. The group explores the dream of writing React code once and deploying it across web, mobile, and desktop, drawing comparisons to how jQuery once unified cross-browser inconsistencies.
The discussion extends to Expo's evolution from a limited bootstrapping tool to a more flexible development platform, and Chris makes a compelling case that React Native integration will be the next frontier for Jamstack frameworks. Anthony confirms that both Redwood and Blitz have early proof-of-concept mobile efforts underway, signaling that mobile-first full-stack JavaScript development is approaching reality for the broader community.
00:12:46 - The Bison Article and Cutting to the Jamstack
Anthony highlights Mike's getting-started blog post for the Bison framework as the content that first brought him to the show's attention, and they discuss the importance of accessible documentation for developer tools. Mike explains how the Bison article reflected his broader belief that frameworks need clear onboarding guides, not just powerful internals.
The conversation transitions into the book itself. Mike outlines the core stack — Next.js, Prisma, React, Chakra UI, React Hook Form, and the Cloudinary API — and explains his decision to keep the scope intentionally lean, omitting GraphQL and CI tooling to focus on the minimum knowledge needed to ship a SaaS application. He describes the book's demo app, Jam Shots, a simple collaborative photo-sharing tool inspired by his desire to easily share family photos outside of major platforms.
00:20:59 - Image Optimization, APIs, and the Indie Hacker Ethos
Mike discusses his choice of Cloudinary as the image API for the book, emphasizing its generous free tier and the appeal of building SaaS products with minimal upfront cost. The group then dives into the broader challenge of image optimization on the web, comparing the Next.js Image component with Gatsby's long-established image tooling and debating which framework handles images better today.
Chris shares his experience using ImageKit at Everfund, and the hosts joke about how similar all image CDN services appear under the hood. Mike connects image optimization back to his indie hacker philosophy: the ability to ship and experiment without heavy hosting expenses is crucial for solo developers and small teams who want to test product ideas without significant financial risk.
00:31:25 - Database Strategy, Prisma Migrate, and Deployment
The conversation shifts to database tooling as Anthony asks about the book's database setup. Mike explains his plan to guide readers through local Postgres development and free-tier hosted options, with Anthony suggesting Railway as a newer alternative to Heroku. The group then shares war stories about Prisma's migrate feature, with Anthony noting that Redwood's entire tutorial library broke when migration commands changed.
Mike praises Prisma's declarative approach to migrations, comparing it favorably to the mature but imperative system in Ruby on Rails, while acknowledging the tool is still emerging from its experimental phase. Chris recounts a nerve-wracking production migration upgrade, and the group agrees that despite the growing pains, Prisma's long-term potential makes it worth the investment for anyone building full-stack JavaScript applications today.
00:37:28 - NextAuth, Authentication, and Closing Thoughts
Mike highlights NextAuth as a key technology in his book and an underappreciated library in the ecosystem, praising its ability to handle one-click sign-up with providers like Google, Facebook, and Discord while managing the full-stack communication between frontend and backend. Anthony connects this to the broader trend of authentication being treated as a first-class concern in modern frameworks like Redwood and Blitz.
The group briefly touches on alternatives like AWS Cognito and Auth0 before wrapping up with lighthearted banter about what fruit flavor best represents the Jamstack — raspberry wins the day. Mike shares where listeners can find him online and learn more about "Cutting to the Jamstack," and Anthony extends an open invitation to the entire Echo Bind team to join future episodes of the podcast.
Transcript
00:00:00 - Anthony Campolo
I was kind of talking to him and said we should get a podcast going. Then Chris did the round table with the three. I remember after that he was like, “Hey, how was it?” I was like, “It’s great. This is why we should have a podcast.” And here we are.
00:00:23 - Mike Cavaliere
It’s great that it came from you and Chris throwing around the idea and you guys ran with it. That’s awesome. I think it’s a perfect time for it because you’ve got these frameworks that are starting to come together and be really useful. It’s something you’re going to get a lot of traction on, I believe.
00:00:40 - Anthony Campolo
We already have.
00:00:42 - Mike Cavaliere
I mean, it’s why I put the book together, right? Because this specific knowledge around using Jamstack tools with full stack technology to build apps, there’s a really strong need for that type of learning.
00:00:57 - Anthony Campolo
Mike Cavaliere, welcome to the show.
00:01:00 - Mike Cavaliere
Great. Thank you for having me. It’s good to be here.
00:01:03 - Anthony Campolo
Why don’t you let us know what your role is, what you do, and how you got involved with all that?
00:01:08 - Mike Cavaliere
I’ve been in technology engineering-related disciplines for about 20 years at this point. Don’t try and guess my age. I’ve been writing code for a long time in different technologies. I’ve been working with them for probably coming up on three years at this point.
I was doing some consulting and jumped on a consulting project with them, and I really just liked their vibe and the way they work. They’re awesome people and awesome technologists. I’m a senior engineer with them right now. I’m also doing a bit of product work over there.
I often work on client product projects, but I also have a large interest in developing products, both content-related and technical. I figured what better way to get started with some of that than developing technical content that people can learn from. That’s a large amount of what I do there: largely engineering, but a little bit of product-related stuff and creating content.
00:02:05 - Anthony Campolo
Yeah, it’s cool. We’ll definitely get into some of the content that you’re working on. You’ve got a book that you’ve got cooking called Cutting to the Jamstack. Yes. Very cool title that I like.
Before we start getting into that, I’d be curious to talk about the tech you’re working on. I know that Echo Bind has done a lot of mobile in the past, but they’re not just doing mobile. So I’m curious, are you in the mobile world, the web world, or do you straddle both?
00:02:31 - Mike Cavaliere
I do. I’ve been working with JavaScript for a really long time, like my whole career, as well as other technologies. But that’s been the one that’s the most consistent in all its different forms.
In the past maybe five or so years, I’ve done tons and tons of React: React Web and React Native. I work with both. We’re a pretty versatile shop, so we do plenty of React Native, and we’ve gotten a little bit of recognition for that because we do so much of it. In addition to that, we work plenty with React on the web, with the Jamstack, specifically with Next.js. We also do general-purpose JavaScript.
This last project I was working on, I was building microservices with Next.js and Typeform. That’s the great thing about JavaScript. It’s like the Swiss Army knife for programming. It goes everywhere.
[00:03:27] Those are also just great frameworks. Next.js is an awesome framework for building microservices. The last couple of months, that’s been a lot of what I’ve been working on. React Native, React Web, Next.js, pretty much all of it.
00:03:42 - Anthony Campolo
It sounds like you predate the whole boot camp world. Did you have a CS degree? What really got you into programming in the first place?
00:03:55 - Mike Cavaliere
I actually do have a CS degree from a while back. I got involved in computers before that. When I was younger, my sister’s high school boyfriend introduced me to computers. He was using an old, actually I’m really dating myself here, but he gave me a Commodore 64 back in the day for Christmas one year. I did a little bit of programming on it, but it was mostly for games. Navigating software and utilizing it was really interesting to me.
By the time I got to college, it was a natural fit to get a CS degree. Oddly enough, the college I was at at the time, their CS program was very heavily theory-based, and they weren’t really using modern programming languages. This was around the late 90s when the dot-com boom was happening. So I said to myself, I’ve got to grasp web technologies because there’s a lot happening there.
[00:04:53] Also, you see the fruits of your labor very quickly. For me that was awesome. So I learned HTML in a one-credit course, and I started putting together 90s-style web pages, which were ugly as hell but really interesting to see what you created very quickly and that someone else on the internet could consume it if it was interesting enough, which mine were, of course, but they were still interesting.
From there, I taught myself HTML, JavaScript, Perl, and a little bit of CSS, which was just coming of age at the time. From there, I got into the freelancing world and started building web pages. I remember the first professional, well-known web page that I worked on was Baywatch.com for the original Baywatch. Being able to work on something that was public like that was really interesting.
Fast forward to the modern age, that’s been a big chunk of my whole career: building things that people could potentially see and then building the pieces under the hood that people can’t necessarily see, but do some pretty amazing things too.
00:05:53 - Christopher Burns
I’m really interested to talk about React Native and to go deeper into React Native. I’ve done React Native development in the past, and you’re the first guest we’ve had that I would say is bigger into React Native as well.
00:06:09 - Mike Cavaliere
So you’ve got to get some other Echo Binders on the podcast. We do. We do a lot.
00:06:14 - Anthony Campolo
React Native for sure.
00:06:15 - Mike Cavaliere
Yeah.
00:06:16 - Christopher Burns
My first question on the list would be, have you heard of React Native Web?
00:06:24 - Mike Cavaliere
Actually, I’m working on a project that utilizes it right now. I just switched from the microservice project that I was talking about to one that’s built in React Native Web. So I’m not super well-versed in it, but I’m getting some exposure to it now.
00:06:38 - Christopher Burns
You understand the concepts of write once and go everywhere. I’ve not used it, but I’ve watched it with a keen eye and I personally think it’s the future. At one point in the future, it’s just going to become so obvious to use something like that over React.
00:07:00 - Mike Cavaliere
Yeah, I could see it being possible. I’m still just getting exposure to it, but in concept that sounds great, right? React itself kind of promised that when it was becoming popular. And then React Native came out; that’s actually what a lot of people thought. It was like, oh, I write it once and it just works on mobile.
But it wasn’t exactly the case because the API is very different, but the concepts still existed and they were similar. React Native Web, as far as I’ve worked with it so far, the API is exactly the same. My knowledge transfer has been really easy because I’m just writing React Native code. On this project that I’m working on now for a client, the goal is to make it into a shared component library that exists on web and mobile.
It definitely seems possible with this technology because you’re developing UI in exactly the same way, and it doesn’t necessarily care about how the device under the hood renders things. It’s doing all that work for you.
[00:07:57] I liken it to how jQuery was when it first came out. Before jQuery, there were a lot of workarounds that you had to do in JavaScript with XMLHttpRequest across browsers to make it play as nicely in Firefox and other browsers. So jQuery came along and said, “Okay, we’re going to do that for you. So everybody just start doing this.” That type of approach is always going to be really popular because whenever you can do two things so that the person using the technology can do one thing, it’s going to be embraced by a lot of people. It definitely has a lot of potential.
00:08:39 - Christopher Burns
Yeah, I see the potential not in the next year, but definitely within the next five years, where you could very much get to the point where you write React Native code that would go across web, mobile, and more native applications as well, like Mac and Windows, because Microsoft’s doing a lot of work with React Native as well. I believe it’s called React Native Windows and macOS. I think it is. It’s this point where all it takes is one mastermind to string it all together to the point you could write React once and it would potentially work in every environment. That’s the dream, right, Anthony?
00:09:30 - Mike Cavaliere
That is the dream. We’ve been looking at React Native desktop at Echo as well. We’ve been contemplating using it on certain desktop projects we might be taking on. The promise of it is great. I’d like to see the execution of it and see how well it works out. I haven’t used React Native desktop yet, but it looks great as well.
When I said JavaScript is the Swiss Army knife of technology, if React could become that, where you’re just writing a React API on whatever operating system you want to develop on, that would be amazing for developers and for maintainers. Companies love React Native for a lot of reasons, but one of them is that you don’t have to develop two separate code bases for a lot of use cases. It’s very cost-effective to write that way.
00:10:23 - Anthony Campolo
Let me see if I can guess one of Chris’s questions. Ask if you are using Expo.
00:10:29 - Mike Cavaliere
We are now. I think on some projects we’ve looked at Expo over the years. Before I started working with it, I definitely used it on individual projects and it was great for bootstrapping something or for working on a simple project that didn’t need certain things that Expo couldn’t support.
Internally, for years we relied on React Native and Create React Native App as the default at Echo Bind. But from what I’m hearing, Expo has come such a long way now, it’s definitely worth taking a better look at because you’re not so bound to their limitations anymore. I haven’t worked hands-on with it lately, but I know others that have and they’ve said great things about it.
00:11:12 - Christopher Burns
Yeah, the last time I used React Native, I didn’t use Expo because I needed a lot of native modules that Expo didn’t support. But from what I understand of React Native and what’s happened since I last used it, it’s now been rebuilt to be more plug and play. It’s super exciting.
The reason I bring up React Native is it’s going to be the next big thing in Jamstack or FSJam in the next year or two because everybody’s already tackled the web platform, but also every single one of them is probably promising a React Native version as well.
00:11:59 - Mike Cavaliere
Interesting.
00:12:00 - Anthony Campolo
Yeah, a lot of flag planting has already gone on there. Both Redwood and Blitz have very explicitly said they want very nice first-class mobile support, most likely through React Native. Already being React-based, it’s just kind of natural. Both of them have very rudimentary proof-of-concept things going on. I know there’s someone in the Redwood community who’s working on it, and there’s someone in the Blitz community as well who’s working on it. So as Chris said, we’re definitely going to start seeing that this year.
I’ll be curious to see when those projects start to reach maturity, but it’s always something to keep an eye on. If you’re more of a mobile developer, there should be a lot of interesting stuff happening in FSJam for you coming up.
00:12:45 - Mike Cavaliere
Definitely awesome.
00:12:46 - Anthony Campolo
All right, let’s transition into the book. I’d actually like to talk about an article you wrote. This is what got you on my radar in the first place: you wrote a Getting Started blog post for Bison, and this was something that I’d been really hoping someone would write. I was probably going to write it myself if someone else didn’t do it eventually.
Bison is this really cool framework that we’ve talked about a ton of times on the show by now. It doesn’t have the kind of really hand-holding, getting-started guide that Redwood has because Redwood has this whole tutorial-driven development thing going on. Bison is more of a framework that was like a really powerful boilerplate, almost. That’s kind of how I think about it that you guys had put together, you guys and gals had put together.
There weren’t really as many docs and things like that, but it was still something that I thought was really interesting that more people should check out. I was hoping there would be more content like that. I’d be curious how you think about writing those getting-started tutorials, and what you thought was lacking from the docs that you could contribute with that article.
00:14:04 - Mike Cavaliere
Yeah, and thanks for being the proponent of that article. I appreciate that.
In the docs, I’ve actually evolved a little bit since that article was published. They’ve got a little bit more of a getting-started guide. It could certainly use more growth in that area because, like you said, it’s a very enhanced boilerplate with some opinionatedness in there that aims to give you a full-stack Jamstack toolbox, kind of like what I’m talking through the guts of in the book, like how do you put all these pieces together to create a full-stack Jamstack application, but it does it for you.
You need a good guideline into it to know what it’s doing for you, what you need to know about that, and what all the cool parts are. There are obviously very cool parts to Bison that can save you a lot of time and energy, but if you don’t know they’re there, then you’re just going to have to figure it out. Or you’re forward-thinking enough to really embrace the concept very quickly without having the documentation there, which is not everybody. We should have really good documentation.
[00:15:18] So it’s definitely gotten better since then. It could certainly use some more. I definitely plan to contribute to Bison itself a little bit in the future. The book took my attention away because I want to put this thing together and get some of the knowledge out there that involves it. The book isn’t intended as a Bison how-to, but the concepts translate well over.
00:15:41 - Anthony Campolo
You’re building a similar stack in terms of using Next.js. Are you doing GraphQL at all for the Jamstack book?
00:15:48 - Mike Cavaliere
Not in the book, no. I thought about it. GraphQL is definitely a piece of the typical FSJam puzzle, but I wanted to keep the book kind of MVP. I don’t want to overwhelm the reader either. I want to show people, if I want to embrace the Jamstack and ship a full-stack SaaS application, what’s the minimum knowledge set that I need?
I tried to keep it condensed without trying to get all the bells and whistles in there. Initially, I was thinking of putting CI using GitHub Actions and test-driven stuff in there, but I thought, okay, let me focus on a little bit more centralized stuff. I also want to make sure that I get the book done. I don’t want to give insane amounts of work for me before I get to point A. So those things I’ll probably add on later as bonus content.
[00:16:42] For now, I’m keeping it simple. Here’s what you need to go from zero to shipped in a SaaS application using the Jamstack.
00:16:50 - Anthony Campolo
That’s really great because you’ve got to scope these things. As someone who does a lot of content, what people don’t realize is that you have to build the thing first. You can’t really start writing a word of content until the actual project is there, or else you’re just kind of spinning your wheels. You end up rewriting all sorts of stuff. It’s such a crazy process.
Let’s actually talk about the tech. We already mentioned that it uses Next.js. Give a high-level overview of the full stack that you’re working with here.
00:17:22 - Mike Cavaliere
The core pieces are Next.js and Prisma and React, which is included in Next.js. There’s going to be Chakra UI for the visual stuff. React Hook Form is going to be in there for form manipulation. We’re going to be using the Cloudinary API.
Just to talk about the premise of the book really quick, I’m going to be touching on a lot of different technologies by building a SaaS and shipping it, then showing people how I did it step by step. It’s not going to go as deep into a single technology as you might on the web. If I was writing a purely Next.js book, I would be touching on every single detail that Next.js has to offer. I don’t want to do that.
What I saw as a void in programming learning is that you don’t always show people the different topics you need to touch on in order to ship an application and the way those pieces fit together. I think there’s a lot of room for that to be done out there.
[00:18:19] For example, in the course of building the app for the book, the app is going to be called Jam Shots. It’s essentially a simple photo-sharing app that I saw a need for. My wife and I have a 20-month-old son. He’s cute, so we’re taking pictures of him all the time. She takes pictures on her phone, I take pictures on my phone, and we want to throw those together and put together a single gallery just for family members, not necessarily on Facebook or Insta.
We want to be like, okay, this is Leo playing in the snow, and here’s a bunch of photos for it. I didn’t look that deeply, but it didn’t seem like there was a very simple, concise way to do that. All the big dogs like Google and everybody have photo-sharing software that is a little bit platform-specific or it does too much. There’s just so much to do in there.
This is also a way for me to scratch my own itch, as developers love to do. It also seemed like a very good teaching platform because I was already thinking of putting a book together.
So the app is called Jam Shots, and all it’s going to enable people to do is upload easily from a mobile device, share that gallery, and collaboratively edit it. My wife and I can pop a bunch of photos into the app, I could share it with her, give her edit access really easily, and then we could just copy and paste the URL to family and they can see Leo playing in the snow.
That’s kind of where I saw room for teaching because when you think about it, there are a lot of pieces that it touches on that you won’t get in Next.js documentation or a Next.js tutorial. You won’t get it in a React tutorial, you won’t get it in a Prisma tutorial.
But in my book, you’ll be able to see, okay, here’s how we think of some basic database modeling. A user has many galleries and galleries have many photos. Here’s how the different parts of Next.js will interact to create and then retrieve that data. When you think about it, there’s the React UI that’s going to do the fetching and rendering. Then there’s the API endpoint in Next.js, which is going to do the fetching and rendering to the front end, but from Postgres through Prisma, and then also through the Cloudinary API.
There are parts that a typical tutorial is just not going to tell you. Like how do I manage the data that I have in my database mashing up with data in the Cloudinary API? There’s a little bit of relational thinking and a little bit of JavaScript thinking to do that in a clean way.
So that’s a long-winded way of saying that that’s how the app idea came about, and also this particular type of information I want to teach in the book.
00:20:59 - Anthony Campolo
Yeah, that’s great. I like that you’re including Cloudinary because we talk about the “A” in Jamstack, or what used to be the Jamstack acronym, that is, the APIs. That was a very big part of a Jamstack application, but it was always something that felt like bespoke knowledge because every API is going to be different.
It’s actually something that I’m kind of working on now at my company at Stetson, how do we normalize across all these APIs. So I’m working a lot with Cloudinary and that kind of stuff. I’m curious if there are other APIs you’re considering, or if you just want the photo one to keep it well scoped, or if you have lots of different ideas as you’re building this out. I’m curious if there are some other things that you’re like, oh, this would be cool, but then you reined it in.
00:21:52 - Mike Cavaliere
I’m sure there were. I have to think back. At first, when I was thinking of doing this book where I’m teaching people to build a SaaS, I was struggling with what the topic would be. All that came to my head was almost cliche at this point, like programming tutorial ideas. It was like the to-do app, the notes app. I was like, this sucks. Who wants to see another to-do list app?
Then I had this personal need for a photo app. It came to me that that was a lot more novel. I bounced it off a few other programmers, and they were like, oh, that sounds a lot better. There weren’t too many. I’m trying to think back. There were probably other API ideas that I had, but they were all revolving around photo stuff. I was looking at images and just plain old S3 for hosting the photos, and using a CDN. Cloudinary I liked because they had a free plan and they were fairly established.
Another thing that really appeals to me is I’m big into the indie hacker mentality and how there are many one-person SaaS startups out there. I like having the ability to teach people how to ship a SaaS with minimal investment because a lot of engineers want to do that. I love doing it. I love the idea of being able to ship a SaaS as an individual, or on a very small team, and not having to spend tons of money to ship an application that might make me some money. It might not, because a lot of SaaS don’t.
That’s where product learning comes in, which developers definitely have to pick up more in order to become profitable SaaS owners. I like not having that hurdle of having to pay tons of money for hosting costs, especially if I don’t know if the app is going to make money. That actually was what led to me using Cloudinary in this.
[00:23:40] You can do a lot with the free plan on Cloudinary. The database hosting I’m going to be doing in the book is going to be based on Heroku, which on the hobby plan is free. That also really appeals to me: here’s zero to launching, and ideally you don’t have to spend a whole lot in order to experiment a little bit.
I hope that answers your question. I didn’t have too many APIs in mind, but there are so many you can work with. I know Lee Robinson, for example, in one of his online courses, utilizes Firebase and I think the Twitter API. I think it’s his React 2025 course, which actually was what motivated me to ship a full SaaS because I saw he’s doing this great work and he’s shipping this course for free, in which he’s teaching people to ship a SaaS. I felt I had to bring my game up a little bit.
00:24:34 - Anthony Campolo
Oh yeah. Shout out to Lee. I think Lee’s work is really incredible. I want to reach out to him to get him on the show at some point.
00:24:41 - Mike Cavaliere
Oh, you should totally. He’d be a great one to have on the show.
00:24:44 - Christopher Burns
I’ve used Cloudinary a lot, but I used it a lot in my Gatsby days before I came to Next.js and Redwood. Something that I think is quickly worth going over is Next Image. Next Image is only currently supported on certain providers, isn’t it?
00:25:11 - Mike Cavaliere
Yes. Cloudinary is one of them. I forget who else, but it does support Cloudinary.
00:25:21 - Christopher Burns
The second reason is, obviously when we talk about Jam, we speak about the Goliath a lot. Next and Gatsby. If you had to pick which image component is better, Next’s image component or Gatsby’s image component, which one would it be today?
00:25:41 - Mike Cavaliere
That’s a great question. I honestly haven’t done so much work with Gatsby that I’m as familiar with that image component to really fairly give an answer. I do know that I love the Next Image component after working with it. I’ve worked on so many different front-end technologies. I’ve done work with jQuery and React proper, and I’ve done lazy loading in a number of different ways. Just having it there in a React component by default is phenomenal. So I’m very biased because I love it right now. If I do dig into Gatsby’s image component, I’ll let you know and then give you a fair comparison.
00:26:21 - Christopher Burns
The reason why I ask is because Gatsby for so long had an image component and Next didn’t. It was king. If you’re going to do anything image-based, you probably want to use Gatsby. Then Next.js came out with theirs. Was it in 10 or 11?
00:26:43 - Mike Cavaliere
I think it was in 10.
00:26:43 - Anthony Campolo
Yeah, it was 10. Ten?
00:26:45 - Christopher Burns
Yeah. Then Gatsby, papers get shuffled. Now what? Gatsby image is now 40% better. So it’s very much a really interesting question. This is not me criticizing the stack of your product. Whenever it comes to image-heavy websites, at the end of the day, images normally cost more than JavaScript sometimes.
So it’s this thing of how do you optimize them? How do you keep the website running fast? How do you keep it in line? It’s really, really hard. I’ve built an e-commerce website with Gatsby and the image stuff was one of the hardest things because it was built for people who are not savvy with uploading everything in JPEGs or whatever quality, making sure something is the same width and height, not stretched or too small. It’s a really big challenge even today.
00:27:52 - Mike Cavaliere
Yeah, absolutely. There are entire businesses built on it. That’s why you have Imgix and Cloudinary, right? Because they’re trying to help you with some of those problems as a service. Any helpers you can get with images, utilize them.
That’s part of what I like with Next.js image component too. I’ve worked a lot with WordPress in the past. What was cool about WordPress is they have utilities built in nowadays that will just render source sets for you. You upload an image, there’s a plugin for image optimization, plugins for CDNs that distribute them, and then there’s a WordPress renderer that just has the source sets and everything built in. With your hosting, you can set it up so you’re making sure that everything’s delivered in a good way.
One really great thing that the Next Image component has, and I’m guessing the Gatsby image component does too, is the source sets. You don’t have to do the calculation and thinking for that. When you hook it up with a good API like Cloudinary, the server side is going to deliver the optimal images too. I believe they do compression on their end too. If not, they definitely should. A user uploading an image into your app shouldn’t have to be thinking about file formats or whether they’re uploading the right size. They should just be able to tap and go.
The image world still has room for improvement, but there are a lot of tools out there to help you do images a lot more easily.
00:29:26 - Christopher Burns
Yeah. And I think images is one of these deep subjects because you could quite easily just say, well, I’m just going to put my images for the website in public and then just import them, not necessarily use generated images, just normal images. But actually you should put them on a CDN because they offer so many benefits that just importing them doesn’t have.
00:29:58 - Anthony Campolo
And how are you managing it now with Everfund? You said you’d use Cloudinary. Are you using Cloudinary for Everfund, or are you just kind of managing it with a Next Image component?
00:30:08 - Christopher Burns
We are using ImageKit. Yeah, ImageKit. We don’t actually use the Next.js Image component because I didn’t think ImageKit had it in yet, but I still need to do some more work to upgrade that and optimize that in the future. It’s all simply ImageKit. That’s what we use. I’ve used Cloudinary in the past. I couldn’t really ever tell a difference at the end of the day. They’re literally almost identical, even to the uploading widget, to the point you look at them and be like, is this some open source project that everybody is just using?
00:30:50 - Mike Cavaliere
It’s a conspiracy. They’ve all had a meeting of the minds and wrote the same code and just shipped it in.
00:30:56 - Anthony Campolo
Probably using the same CDN, which is owned by some company that uses a three-letter acronym to describe their service.
00:31:05 - Mike Cavaliere
Sounds about right. That stuff is mind-blowing. Remember, Heroku has been so great for so long, but I remember the day I realized that Heroku was built on Amazon. I was like, what?
00:31:17 - Anthony Campolo
You’re telling me it’s just EC2 all the way down. It’s just EC2 on EC2.
00:31:22 - [unclear speaker]
I mean, in the Matrix, man. It’s not the real world.
00:31:25 - Anthony Campolo
Yeah, we actually just sunset our Heroku tutorial support in Redwood. I shouldn’t necessarily say sunset because you can still do it, but Heroku has been the canonical database if you follow the Redwood tutorial for as long as Redwood’s been around. But we just switched to Railway.
If anyone is looking for some hot new Postgres database companies and you’re like, ah man, there’s not enough of these yet because there’s a lot of them now, Railway is one of many that’s basically giving you a Postgres database with a super nice UI. We’ve had Supabase on, and they’re another big popular one lately. Rob has also done a lot of work on Supabase examples with Next.
But you just went with Postgres. How exactly does the database stuff work in the book? Do you have them spin up some sort of hosted DB? Do you develop locally? What’s the database story for the book?
00:32:27 - Mike Cavaliere
Good questions, and some of that is still evolving. My original plan was, well, it’s eventually going to be both. For development, obviously they’re going to be developing on a local machine. I’ll make a couple of recommendations for setting up Postgres on a local machine. I’m on a Mac. Postgres.app is a great way to get started very quickly. You download it, you run a few commands to create the database and get permissions, and then you’re into Prisma land immediately.
On deployment, my plan was to show them a little bit about Heroku, but you just gave me a great option because Railway has a free plan. I might have to try that out and see if that’s an option. Either way, I’m going to try to give them an option to use a free hosting provider.
In Prisma, we’re going to be using the schema and the migrations feature, which is going to be production-ready soon. It’s considered an experimental feature, so it should be right around the corner.
00:33:27 - Anthony Campolo
We know far more about migrate than we ever wanted to. Let me tell you.
00:33:31 - [unclear speaker]
Oh, really? Tell me more.
00:33:33 - Anthony Campolo
Yeah, because Redwood is living the migrate transition. We’ve been using migrate for this entire year, all last year. Now they’re getting out of experimental mode into dev. It changed a bunch of commands. Every meetup talk I’ve ever done about Redwood is now broken if you go back and watch those because the database commands have changed. If you try to follow along with literally any Redwood video, you’re going to hit some issues with Prisma migrate. Fair warning to anyone out in the world listening to this right now.
00:34:06 - Christopher Burns
Last night I upgraded my Redwood project from 23 to 25, where migration got updated with a live production database, and I was sweating bullets all the way through it. I was like, please don’t lose my data. Please don’t lose my data. It’s so easy to read a command that says, “This may lose your data,” and you’re like, I don’t know what you’re doing behind the command, but by you putting that message, it really does scare you.
00:34:37 - Mike Cavaliere
It should, honestly. One thing about Prisma that I think is going to further the popularity of it as soon as that’s ready is a good ORM. The core thing you need the most is a good database structure managing tool.
I’m really spoiled because I did a lot of Ruby on Rails back in the day, and Ruby on Rails is so mature now that their migration system is elegant and stable and beautiful in a lot of ways. Prisma’s potential is outstanding because they’re making migrations declarative instead of imperative. Rather than saying, run this series of steps, you’re like, “You don’t have to do all that. Just tell me what you want the database to look like. I got you. I’m going to take care of it for you.”
The potential for it is phenomenal. They’re just working on getting out the kinks, which is hard to do really well. But they’re doing a great job at it. As soon as that’s a little more streamlined and a little more stable, it’s going to be a killer feature. It’s going to be really good.
I’m making a note of it in the book that this is just on the verge of getting out of the experimental phase. Using Prisma for a SaaS app right now, you’re running a little bit of risk. But we’re starting small. When you’re starting small and you’re aware of the risks for the long-term investment, which I think Prisma is, then it’s absolutely okay. You’re just being a little cautious with it.
As soon as they pull that out of the experimental phase, man, you at Redwood and me here working on this book, we’re all really excited.
00:36:16 - Anthony Campolo
Yeah, we’re totally bought in to Prisma. That’s why we like to joke about all the pain they put us through, but we’re entirely bought into Prisma. We think the work they’re doing is amazing.
I think the real big API changes have been made and it should be stable from here on out. So I think you’re getting in at a really, really good time to be writing a book about it because if you had written this book a month ago, then you would have been in trouble. I think you’re probably going to be in the clear from here.
00:36:51 - Mike Cavaliere
I have thought about, in the back of my head, consolidating all my database logic into a class or a module so that if any of the API changes, I just swap it out. But then I thought, how meta do I want to go? Because like you said before, you have to write a good amount of the app before you start teaching it. Otherwise, you’re going to rewrite a lot of that book when you change your mind or clean up your code.
I’ve thought about that, and that’s a really good way to program if you get the time for it. We’ll see how it goes. I’ve done it with a little bit of the API logic, but I don’t want to get too meta. Otherwise the book will never get written.
00:37:28 - Anthony Campolo
What other projects are you working on? Tech you’re excited about? Things you see as trends in industries? I want to open it up to anything that you think is cool and worth talking about.
00:37:40 - Mike Cavaliere
This is the main project that I’m working on for myself, other than just writing a lot of content. One piece of technology that’s in the book that I didn’t mention earlier is NextAuth. NextAuth is a great library for managing one-click sign-up and integration with any provider you can think of. They’ve got Google, Facebook, Slack, Discord, magic link sign-in using your email, all that’s handled for you.
00:38:08 - Anthony Campolo
I have a lunch and learn that you did that we’ll link to as well in the show notes.
00:38:12 - Mike Cavaliere
Oh great. Thank you. I’m going to be putting out a series of blog posts on the blog. We’re doing a little bit of redesign and redevelop on our website and our blog. Once that’s done, that should be coming sometime this month, I think. Actually, no, it’s almost the end of February. It’s probably March.
I have a series of three posts on NextAuth, just how easy it is to drop in one-click sign-up into a Next.js app with NextAuth. It’s a phenomenal technology that I’m really excited about. I don’t think enough people know about it. You ought to get them on the show too because that’s a great one.
00:38:48 - Anthony Campolo
Is it done by the Next team or is it a separate team? I had heard about it from a LogRocket article. I read the LogRocket blog, which is the best technical blog around. They’re really good, so I get to a lot of these libraries. Who’s the team behind NextAuth?
00:39:04 - Mike Cavaliere
That’s a great question. I think it’s individuals. I’ve tweeted with them, but I don’t think I ever looked up who they are.
00:39:11 - Anthony Campolo
Yeah, feel free to make that connection. We’d be happy to have them for sure. We’ve talked a lot about auth on the show and how we think of auth as being pretty much a requirement for these frameworks. If you don’t have some sort of good built-in auth solution like Redwood and Blitz both, that was one of their first priorities. As soon as they both got into 0.1 territory and they were like, okay, we have a thing that works at all, the next step was auth.
They figured that out by like 0.7 for Redwood and then Blitz. I know it was just a couple months after the project actually started. They both highly prioritize getting a built-in canonical auth solution into the libraries in a way that allowed them to plug and play different JWT solutions.
If you look at Redwood’s docs for auth, it’ll give you seven different providers, like you mentioned for NextAuth as well, because they’ve all kind of centralized on some sort of JWT token passing scheme. They all have different metadata that they associate with that. But yeah, that’s really, really cool stuff.
Have you looked at other auth solutions, or was that just the obvious, rose-to-the-top solution?
00:40:27 - Mike Cavaliere
I’ve done a little bit of manual auth and I didn’t look really hard because I found NextAuth and I really wanted to mess with it. It just seemed to check all the boxes that I needed.
I’ve seen demos on Amazon’s auth solution.
00:40:41 - Anthony Campolo
Cognito.
00:40:42 - Mike Cavaliere
Cognito, yes. Amplify simplifies that integration process. I’ve heard very good things about it. I’ve seen some demos of it. It looked great in Bison. I think we have a hand-rolled one, but I’m going to make the recommendation to put NextAuth or something similar in there just because it’s a team focusing explicitly on that.
I’ve also seen great things done with Auth0, but for Next.js itself, I imagine if I was going to integrate Auth0, I’d still have to do full-stack work for that. That’s the cool thing about NextAuth, it takes into consideration the framework, right? You’ve got a front end and a back end. Am I going to have to write a mechanism for those two to communicate, or are you going to do it for me? That’s what NextAuth does. I imagine Amplify and Cognito would do too.
I didn’t look too hard because I looked at this one solution and I really liked it. So as of right now, that’s what I’m using. I could certainly talk about tech for hours and hours, but you guys are doing great on the podcast. Keep it up. This is a great area of discussion that people are going to be talking about lots and lots more. Keep up the good work and thanks for having me.
00:41:54 - Christopher Burns
My last question would be if you think of Jam as an actual jam, what fruit would it be?
00:42:04 - [unclear speaker]
Raspberry.
00:42:06 - Mike Cavaliere
I’d have to say it’s the most canonical in my mind. I like different types of jam. Trust me. Strawberry is pretty great too.
00:42:16 - Christopher Burns
But all jam is good jam. I don’t think I dislike any jam.
00:42:21 - Anthony Campolo
Yeah, I just have to have a jam-off.
00:42:23 - Mike Cavaliere
Obviously you’d have to be a horrible person to dislike jam. I don’t know if I can even associate with them.
00:42:28 - Christopher Burns
I think you should rebuild it all to make a voting system to work out the best jam, the official mascot of the Jamstack.
00:42:39 - Mike Cavaliere
That sounds like a $1 million project, so I think I’m going to drop everything and just begin working on that. Thank you for that.
00:42:47 - [unclear speaker]
No problem. All right, where can people find you online?
00:42:49 - Anthony Campolo
What’s your Twitter handle, or just the best way for someone to get in contact with you?
00:42:54 - Mike Cavaliere
My Twitter handle is MCavalier. It’s spelled like my name, Cavalier. You can find me there. Or you can find me at cutintothejamstack.com and email me there. Or you can just Google my name, Mike Cavalier. MikeCavalier.com is my website too. I don’t update as much on there, but any of those ways is a good way to reach me.
00:43:13 - Anthony Campolo
Awesome. Thanks so much for being here. We really appreciate you. The whole Echo team, getting to know Chris Ball, he’s really been a huge supporter of us here in the FSJam community. Anyone else who wants to join, open invitation to the whole team. We think everything you’re all doing is super cool, so we’d love to get more people on to talk about some of the projects you guys are doing.
00:43:34 - Mike Cavaliere
Awesome. I’ll spread the word. Thanks so much, guys.
00:43:37 - Christopher Burns
Thank you.