Blitz.js and Fullstack React with Brandon Bayer

Episode Description

Brandon Bayer introduces Blitz.js, a full-stack React framework inspired by Ruby on Rails that eliminates the need to manually build API layers.

Episode Summary

In this episode of the FSJam podcast, Brandon Bayer, creator of Blitz.js, joins hosts Anthony Campolo and Christopher Burns to discuss how Blitz bridges the gap between the simplicity of Ruby on Rails and the power of React. Brandon traces his journey from embedded C/C++ through Rails and into the React ecosystem, explaining how frustration with stitching together separate frontends, backends, and API layers led him to build Blitz on top of Next.js and Prisma. The conversation centers on Blitz's "zero API" approach, where server-side functions are imported directly into components and compiled into RPC calls, eliminating the need to manually construct REST or GraphQL endpoints. The hosts explore how React Query handles client-side caching, how Blitz's self-hosted authentication system draws on SuperTokens' security expertise, and the trade-offs between serverless and traditional server deployments. Brandon also shares his community-first development philosophy, revealing that he built an engaged contributor base before the framework even had a GitHub repo. The episode closes with a look ahead to Blitz's upcoming beta, a planned 1.0 release, and ambitious future features like zero-API React Native integration and generated client libraries for multi-platform support.

Chapters

00:00:00 - Introducing Brandon Bayer and the Vision Behind Blitz

The episode opens with hosts Christopher Burns and Anthony Campolo welcoming Brandon Bayer, known online as "Fly Bear," who created Blitz.js. The hosts note that while the podcast has focused heavily on RedwoodJS, they want to spotlight other frameworks in the full-stack JavaScript space, including Blitz and Bison.

Anthony shares that he explored both Blitz and Redwood early on and chose to focus on Redwood, but has followed Blitz's progress closely. The conversation establishes a key distinction: while the podcast groups these frameworks under the "full-stack Jamstack" label, Brandon has always positioned Blitz as a "full-stack React framework," reflecting his preference for integrated, monolithic developer experiences over distributed service architectures.

00:02:25 - From Ruby on Rails to React and the API Problem

Brandon explains his programming background, starting with C/C++ and embedded Linux before discovering Ruby on Rails, which he loved for its simplicity—no separate API layer, direct database access from views, and a streamlined workflow for adding features. He describes how the desire for richer user interfaces led him to React, whose mental model clicked for him, but brought the pain of maintaining separate frontend and backend codebases connected by REST or GraphQL APIs.

The hosts discuss how jQuery's imperative DOM manipulation created spaghetti code that React's one-way data flow resolved, and why simply using React as a frontend to a Rails backend still required building an API. Brandon highlights TypeScript as another major draw, contrasting its static type checking with Ruby's dynamic "magic," noting that after using TypeScript, returning to untyped languages feels disorienting.

00:08:43 - The Zero-API Layer and React Query

Brandon introduces Blitz's signature feature: the zero-API data layer. Developers write server-side functions, import them directly into React components, and pass them to hooks like useQuery or useMutation. At compile time, those imports are swapped for lightweight RPC clients that handle network calls automatically, so developers never build REST or GraphQL endpoints manually.

The discussion turns to React Query, which Blitz uses for client-side data caching. Brandon explains how it manages cache revalidation, automatic refetching when users return to a tab, polling, and optimistic updates—all without being tied to any specific API protocol. Christopher asks whether Blitz's abstraction covers most use cases, and Brandon confirms it handles the vast majority, with raw API endpoints needed only for edge cases like file uploads or webhooks.

00:13:39 - Building on Next.js and Deployment Options

Anthony raises the relationship between Blitz and Next.js, noting that concepts like server-side rendering and static generation can be confusing for newcomers. Brandon explains how Blitz extends Next.js's page and API route conventions by adding queries and mutations folders, where exported functions become network-callable endpoints. This builds naturally on the mental model Next.js already establishes.

The conversation shifts to deployment, comparing Render's simple YAML-based setup for databases and servers with Vercel's serverless model. Brandon notes that while his personal preference is Vercel for its automatic scaling, the database setup requires extra steps like connection pooling. He also shares a creative use of Caddy as a reverse proxy to deploy Prisma Studio in production with basic authentication, giving non-technical collaborators direct database access.

00:20:00 - Serverless Dreams and Authentication Philosophy

Brandon discusses the trade-offs between server and serverless deployment, emphasizing that serverless is production-ready but the surrounding ecosystem for databases, queuing, and background processing still lacks a unified, easy platform experience for full-stack apps. The hosts briefly joke about the complexity of assembling serverless pieces from different providers.

The conversation then moves to authentication. Unlike Redwood's approach of integrating third-party auth providers, Blitz ships with self-hosted session management inspired by SuperTokens. Brandon breaks down the difference between session management and authentication, explains the Passport.js adapter for social logins, and highlights the benefits of a fully integrated auth system—including the ability to develop and test locally without internet access or third-party webhook configurations.

00:27:12 - Community Building and the Blitz Job Board

Brandon reveals that he built a community before the framework, sharing how a viral tweet in February announcing the Rails-for-React concept attracted 40 to 60 volunteers before a GitHub repo even existed. Many of those early contributors remained active, reflecting his community-first philosophy. The hosts ask about the framework's name and branding, learning that "Blitz" was Brandon's choice from the start, inspired just a week before announcement during a conversation with a Rails developer friend.

The discussion highlights the Blitz job board, which emerged after Brandon discovered companies already hiring Blitz developers on platforms like Upwork. A community member built the board, and jobs channel activity in Slack shows steady demand. Brandon notes that Blitz attracts a wide range of developers, from React beginners to experienced Rails and Laravel developers, and expresses his dream of making full-stack development accessible enough for newcomers to build and deploy complete applications from scratch.

00:31:36 - Multi-Client Support and the React Native Vision

Christopher asks about Blitz's plans for supporting clients beyond the web, given that Redwood's GraphQL API already enables multi-client usage. Brandon outlines a phased approach: first, generating client libraries in multiple languages from the auto-generated API, similar to how Firebase provides callable SDKs, and then achieving a true zero-API experience with React Native by using compile-time import swapping within a unified monorepo.

The hosts express excitement at the idea of importing server queries directly into React Native code without thinking about API calls. Brandon acknowledges this hasn't been prototyped yet but expresses confidence in the approach. The conversation also touches on the isomorphic domain layer concept proposed by team member Rudy Yardley, which targets offline-first functionality—a harder problem Brandon sees as an ideal candidate for framework-level solutions.

00:36:19 - Key Contributors, Consulting, and Real-World Usage

Brandon highlights Simon, a level-two maintainer who built SuperJSON for automatic serialization and is developing Quirrel, a background processing and queue service for Next.js and Blitz apps. The hosts note Quirrel is also adding Redwood support, creating interesting cross-framework dynamics. Brandon shares that he converted a client's Frankenstein app—combining Rails, Hasura, and Next.js—to Blitz, which surfaced real-world bugs and improvement opportunities.

As a consultant, Brandon works with clients both by recommending Blitz and by fielding inbound requests from teams already wanting to use it. This dual experience of building the framework and shipping production apps with it provides valuable feedback loops that drive practical improvements.

00:39:14 - Roadmap to 1.0 and Release Strategy

Brandon shares near-term plans: an official beta announcement within weeks, followed by a 1.0 release targeting around February. After 1.0, the focus will shift to mobile integration and React Native support. The hosts ask about release management, and Brandon describes plans to adopt an Ember-inspired release cycle with predictable six-week beta periods, long-term support releases every six months, and a deprecation-first approach to breaking changes.

The episode wraps with an invitation for Brandon to return for a Christmas special alongside representatives from Redwood and Bison. The hosts announce new distribution experiments, including short clips on social media platforms and audio releases on YouTube, encouraging listeners to review the podcast and share feedback. The conversation closes on an optimistic note about the growing full-stack JavaScript ecosystem.

Transcript

00:00:00 - Anthony Campolo

Don't start the podcast before the podcast. This is the goods right here.

00:00:13 - Christopher Burns

Welcome back, jammers, to episode six of the FSJam podcast. This week, we will be speaking to Brandon from Blitz.js. So far, we've spoken a lot to everybody at RedwoodJS and why we love them and they love talking to us. There are other sides to this community that we want to focus on as a podcast. One of them is Blitz, and the other one is Bison, and anyone else making a new solution that would fall into FSJam.

So let's get to it. Brandon, why don't we start by talking a bit about yourself? What's your Twitter username, how can people get in contact with you, and what is Blitz?

00:00:59 - Brandon Bayer

Sure. I'm Brandon. I am Fly Bear on the interwebs. So that's "Fly" and then my last name, which is BAIER, and that's because I'm a pilot. So Fly Bear on Twitter, GitHub, etc., and I'm the creator of Blitz. I'm excited to be here and talk about it.

00:01:17 - Anthony Campolo

Super succinct, and he even has a good story for it. I like that. We're really excited to have you on. We have talked about Blitz frequently throughout the course of this podcast, so it's great to have you here to talk to you about it instead of just about it.

It's been really cool for me. I actually first started learning Blitz back when I started learning Redwood, and I ended up realizing that to have the type of impact I wanted to have on one or the other, I kind of had to do one or the other. So I ended up going more deeply into Redwood. But I've had an eye on what you've been doing this whole time, and I have a lot of respect for what you do in terms of how you think about community building. You do talks like a madman, like me. So I really love that.

I think to start off here, we should say that we have lumped these three frameworks, Redwood, Bison, and Blitz, into the FSJam category. But you've never really categorized Blitz as full-stack Jamstack. You said it was a full-stack React framework. I talked about this on our very first episode. That was what I first got into: this idea of how do we build a full-stack React application?

00:02:25 - Brandon Bayer

Yeah. I've never been a huge fan of Jamstack. I'm not necessarily against the ideas. Earlier on, a few years ago, I think I was kind of headed more in that direction toward outsourcing everything to as many different services as possible. But after actually doing that, I realized that it's quite a pain in the butt to stitch together everything.

If you're using Auth0 for authentication, it's difficult to run locally. There are a lot of challenges there with all the integration stuff. I really wanted something more like Rails. Ruby on Rails was how I got into web development. Before that, I was doing C and C++ and embedded Linux, and then I learned Ruby on Rails. That was my introduction to web programming, and I loved it. But then eventually I tried to do more complex stuff in the UI on the website, and it was hard. So I kind of started learning Ember, and I didn't really get anywhere with that.

I started learning React, and then it was like, bam, it clicked in my head. I think React has a very clear mental model that matches how I think about stuff. I was on the React bandwagon for a while and then used various things for the server, like Ruby on Rails for the API, Hasura for the API. I became increasingly frustrated with having to set up that separate backend and the frontend and messing with the API, and I really wanted some way, somehow, for someone else to make a solution so that I would not have to worry about that and just go back to a simpler Ruby on Rails-type developer experience.

00:03:54 - Christopher Burns

Just for people like me who have never really touched Ruby on Rails, how would you describe that experience as simply as possible without going too deep?

00:04:02 - Brandon Bayer

Well, the big thing—if you know about React and Jamstack and APIs—with Ruby on Rails, there's no API. Okay? So you can literally access your database from your UI template if you want to. Typically, you have a controller layer there that talks to the database.

00:04:19 - Anthony Campolo

And that's with ActiveRecord. That is happening.

00:04:22 - Brandon Bayer

Yeah, there's ActiveRecord and the controllers and then the view templates. But everything's server rendered. It's very simple to add a field somewhere. You add it in your database and you add it to your view. You don't have to add it to your API server and then to your client to fetch it. It's much simpler.

00:04:41 - Christopher Burns

Do you think Ruby on Rails is the past and things like Blitz.js the future, even though it borrows a lot of the same concepts?

00:04:49 - Brandon Bayer

How spicy should I be?

00:04:51 - Christopher Burns

It's up to you.

00:04:52 - Brandon Bayer

I don't think Ruby on Rails is dead. It's dead for me, but it's definitely not dead. There's still tons of people that love it, and there's new people learning it all the time. There are people productive with it, and that's more power to them. Stay there. But there is this kind of middle ground between people who love React and people that have been doing React apps for a while and are kind of starting, or have been going, back to Rails because they're like, this is just too complicated. I need something simpler.

And then there's other people that are still in Rails, but they're like, oh, I really wish I could do more powerful stuff, like with React. And Blitz is kind of that middle ground for people who want the Rails experience but with React.

00:05:32 - Anthony Campolo

Yeah, this really resonates. I feel like almost every person at this point who's been on the podcast has told a version of this story. Monarch and Tom, both of them were like, yeah, started on Rails, it was awesome, and then you get into all this modern frontend stuff. With Tom, he was also like, yeah, he really liked React as a paradigm for what it's supposed to do, which is the view layer, not the whole application.

It's interesting because we're all coming at it from different angles. You are a bootcamp student also, I think, as I am, and you're coming at it from having come out of bootcamp and now been working for many, many years. Whereas I'm someone who's kind of still in the thick of it. I think we also saw the pain with the Jamstack, and that's why there's the full-stack Jamstack. The stack wasn't quite working the way people really wanted it to be, and full-stack Jamstack is kind of the ideal of where we want Jamstack to be, because we also feel that same pain.

00:06:28 - Christopher Burns

I have a question that I don't think we've answered, even with Tom and Monarch. Every time people have moved from Ruby to things like React, they say, oh, it's because we want React. But what was React replacing? The Rails application? jQuery? So, okay, the main reason was to really get jQuery out the window.

00:06:52 - Anthony Campolo

Yeah, because with jQuery it was imperative. So you would just be manipulating the DOM directly, and you end up with all this spaghetti code. React, because of the one-way data flow, fixes that. And that's why you would see things like, "Your view is a function of state." Yeah. So that was kind of the idea.

00:07:13 - Christopher Burns

Yeah. So I have a problem with my user interface. I want to upgrade my user interfaces. Now I go down React, and then it starts getting very messy very fast.

00:07:24 - Anthony Campolo

So why can't you just use React as the frontend to a Rails app? What's the challenge there?

00:07:30 - Brandon Bayer

You can, but you have to build the API, either a REST API or a GraphQL API. And you can do that, but it's just work that I don't want to do. The other thing that was also a big thing for me is TypeScript and a fully typed language. With Ruby, there's no types and there's just magic galore. You never know what's going to happen and if it's going to work. You have to run every single thing to make a change. Run it, see if it works. There's no static type checking to give you guidance as you're coding. And after using TypeScript, going back to Ruby feels like you're totally lost in the middle of nowhere.

00:08:06 - Anthony Campolo

The more time I spend with TypeScript, yeah, the harder and harder it becomes to go back to writing JavaScript.

00:08:12 - Christopher Burns

I built a quick project to test something in Redwood the other day. I built my Redwood project with TypeScript, but I was literally just doing it with JavaScript. I was like, I can't click the files. Just let me click the files to go through them and let me click to see the declarations and the types and that. You just get so lost so easily without it. To me, it's like as soon as you go everything as a full project, 100% TypeScript, it's just worlds better. It's just unbearable not to use it.

00:08:43 - Anthony Campolo

So you're having issues with the API. And when I hear you talk about Blitz, the no-API layer tends to be one of the main features. So can you kind of talk about what you mean by that?

00:08:55 - Brandon Bayer

We abstract the API layer into a compile step. So we call it "zero API," in quotes. It's like serverless still has servers, but zero API still has an API. There is an API. It does do fetching from the client and so forth. But that API is abstracted into a compile step.

When you're developing your application, you don't have to think about the API. You're not building a REST API or a GraphQL API. You're not adding API endpoints. You're not using fetch or any type of client. You're just, from a developer perspective, writing functions that run on the server, importing that function directly into your component, and passing it to a useMutation hook or a useQuery hook. It's just ready to go. That function import at compile time is swapped out for a small RPC client that makes the API call over the network.

00:09:44 - Anthony Campolo

Could we talk about what React Query is doing here? Because I know you're using that for the client. I don't know a ton about React Query. I know it's compared to Apollo Client, but it's not exactly the same because it's not just GraphQL. It can do all sorts of things. So I'd be curious to hear a brief description of what React Query is and how it fits into your stack.

00:10:06 - Brandon Bayer

Anytime you have a client that's making API calls and you get data from the server to the client, you very quickly want to be able to cache that data. Let's say you navigate a page and then you go back to the page. You don't want to wait for the data to be fetched from the network. You want it to be there instantly. Apollo Client does that. It has a cache management system. React Query does this, but it's API agnostic, so it doesn't require GraphQL or REST or anything. It's just a very simple kind of building block for caching server data.

So we use that. It manages the caching and then cache revalidation. It does really nice things like if you leave the window and come back, it'll automatically refetch the latest data from the server. You can turn that off if you need. It also has polling ability and the ability to modify the cache for optimistic updates. So it's a really powerful tool for managing all of that cached server state.

00:11:05 - Christopher Burns

So I think this brings us on to a really interesting subject where all the frameworks are trying to achieve the same point, but differently. With Redwood, a lot of people get confused because they don't understand the blocks that it's built on top of, like Apollo connecting the API to the frontend. But would you say Blitz.js is more standalone where you don't need to worry about React Query? Or do you know how these things connect because the framework is abstracting it?

00:11:34 - Brandon Bayer

Yeah, I think the answer is yes. We get very few questions about React Query or like how it's working. The Blitz magic is very minimal, which is one thing I really like about it. I think Rails does too much magic. But with Blitz, this API layer is auto-generated. It sounds like it's magical. It's hard to understand, but really you can think about it as just calling a function over the network. That's all it's doing. And so we abstract just that pipe over the network, if you will. There's no other magic there, really.

If you return something on the server, the exact same thing comes out on the client, and then vice versa. If you call a function on the client, whatever's in there goes over the wire to the server. We handle the serialization and everything, so everything is perfectly passed through.

00:12:22 - Christopher Burns

Do you find that it covers 99% of all situations? Many people don't need to go above and beyond. The default solution is good enough 99% of the time.

00:12:35 - Brandon Bayer

Yeah, maybe not quite that high, but pretty high. One thing right now, if you're doing file uploads and you're going through the server, you need to stand up a raw API endpoint. Things like that. Or webhooks. You would have an API endpoint. But if you're just sending data back and forth from the frontend, then yeah, the Blitz queries and mutations pretty much cover everything you need.

00:12:56 - Christopher Burns

Do you want to say something on that?

00:12:57 - Anthony Campolo

Yeah, I want to go back to what we were just talking about, about the different layers, because when I was first learning Blitz and Redwood, the first thing that really helped me learn them together was seeing the Prisma crossover. Once I saw that, when you're actually using Prisma and you're not using the Blitz or the Redwood type of commands, the same thing was happening in both of them. I was like, okay, this is neither of these projects.

I ended up being confused around Next.js because I didn't know anything about Next.js. In terms of server-side rendering versus static generation, that whole thing, you get all that in Blitz, and I didn't understand what you were getting from Next and what you weren't.

00:13:39 - Brandon Bayer

Yeah. That's something I can relate to.

00:13:42 - Anthony Campolo

It's great because Next.js is becoming such a lingua franca in React. People love Next because Next is awesome.

00:13:49 - Brandon Bayer

Yeah, I think Next.js, in the same way that React fits a lot of our mental models, Next.js does the same thing at a higher level. So it's not just at the component level of rendering the UI, but it's at the page level, whether it's going to be a server-side rendered page or a static page, and then the routing and also the API routes.

We basically take that paradigm a step further with queries and mutations. In Next.js, for a page you export a default component in a pages folder, and that's a page. For an API route, you export a default function from an API route, and that's your API handler. With Blitz you have queries and mutations, and you export a default function that's in a queries folder or a mutations folder. It's turned into a live query that you can run over the network.

00:14:42 - Anthony Campolo

Aren't those functions your API then?

00:14:44 - Brandon Bayer

Yeah, yeah.

00:14:45 - Anthony Campolo

Essentially, you're writing a tiny, tiny API.

00:14:48 - Brandon Bayer

You're writing server logic. The same way in Rails you have to write server logic. You have your controllers. The API to me is what an HTTP API is. You have to manage all the details of getting the data from the server to the client. In Blitz you don't, that's handled for you, but you still have to do your own business logic on both ends.

00:15:08 - Christopher Burns

In this case, so Blitz is built on top of Next.js. Say I start working on a Next.js application, really bare bones. I build a UI to what I understand, as soon as I need to start tapping into a server, that's where you start seeing the limits of Next. And that's where Blitz then takes it a step further.

00:15:28 - Brandon Bayer

Yeah, and I don't know if I would go so far as to say limits, but just lack of structure. Anything is possible. We built Blitz on top of Next.

00:15:37 - Christopher Burns

So I remember when I booted up a Next.js project. It had an API folder, and I deleted it because I didn't need an API with Next.js, but I'm pretty sure it was literally a serverless API folder.

00:15:50 - Anthony Campolo

Isn't a prominent deploy target for Blitz.js Render, right? Can you talk a little bit about why Render fits Blitz well?

00:15:59 - Brandon Bayer

The main thing right now is it's super easy to host a database and the server on Render. So you have a single YAML file and you can define your database in there and your server and connect them together. It's super fast to deploy.

My personal preference for deployment is still Vercel for Blitz, and then hosting the database, probably on DigitalOcean, and using their connection pool. But it's more difficult because you have to have a connection pool to deploy to Vercel. The benefit is that it's serverless and all your API endpoints and everything are serverless functions, so it just scales automatically. You don't have to worry about it rebooting. You don't have to worry about all that sort of stuff.

00:16:40 - Anthony Campolo

We're all about that in Redwood. That's like the whole deal.

00:16:43 - Christopher Burns

One of the most interesting things that I guess you could explain, there's kind of two sides to Next.js in a server layer. There's an API, and then there's the internal Next.js server, to what I understand, that does the ISR on a server. I'm not quite sure because I've built something with ISR, but I've never really figured out how it worked.

00:17:08 - Brandon Bayer

Next does have some of its own internal APIs that it generates and uses at the framework level.

00:17:17 - Christopher Burns

Right. Okay. Yeah. Got you.

00:17:20 - Brandon Bayer

Like as a user, you don't really need to know about it.

00:17:23 - Christopher Burns

Okay. So the ISR, or what they call it these days, and the SSR and all that, that's Next.js internal APIs.

00:17:32 - Anthony Campolo

I think, combined with their integration with Vercel, is what really makes a lot of that possible.

00:17:38 - Christopher Burns

Yeah, I think so. I don't know, is this something that you probably know? If you took a Blitz application away from Vercel, put it on Render, are you actually losing functionality? Because to what I understood about Next was a lot of the functionality came because you deployed it on Vercel.

00:17:56 - Brandon Bayer

No, you actually don't lose any functionality. The Vercel team is very diligent about any features that they add. They make sure the features work everywhere. For example, their new image component, when you deploy to Vercel it uses imgix, the image service. But whenever you run blitz start, they have code in there that uses some npm library that does that for you without using a third-party service. Then you have a config option. You can opt in to a third-party service and use imgix if you want. The only thing that you don't have is whether it's server or serverless.

00:18:31 - Christopher Burns

And it's interesting that you bring up DigitalOcean because I've actually hosted my Redwood app in serverful mode. So I've hosted it on Ubuntu, PM2, behind Nginx. And I saw that you recommended people running Caddy as a proxy layer. Any reasons why?

00:18:52 - Brandon Bayer

The Caddy thing was only for running Prisma Studio in production. Prisma Studio gives you this nice UI, and in development you just run Prisma Studio and you can access your database. But I wanted this same functionality in production. So for a client of mine, I deployed Prisma Studio to Render behind a Caddy reverse proxy that adds HTTP basic authentication because Prisma Studio doesn't have any authentication. So now I have Prisma Studio running at a URL that my client can log in and access their role data.

00:19:26 - Christopher Burns

I will say that's a really good idea. I want to do it myself because every time I have a business co-founder and he's like, oh, this data needs tweaking, I'm like, oh, I need to run this command, boot it up, tweak it. I just want to host it somewhere and be like, here, just tweak it yourself.

00:19:42 - Brandon Bayer

There's a link on the Blitz wiki on how to do that.

00:19:45 - Anthony Campolo

That's really cool. You guys have a wiki, by the way?

00:19:48 - Brandon Bayer

It's on GitHub.

00:19:49 - Anthony Campolo

I don't see that very often. Usually you have the awesome, like an awesome Blitz repo. But you guys have the wiki, right? I think that's cool.

00:19:57 - Brandon Bayer

An awesome Blitz repo, too.

00:19:58 - Anthony Campolo

Nice. You got both. Yeah.

00:20:00 - Christopher Burns

So what's the difference between hosting Blitz in serverful mode or serverless to you?

00:20:06 - Brandon Bayer

How much DevOps do you want to do when you're deploying your own server? You have to make sure it's up, that it's actually running. You have to make sure it has enough memory, all these sorts of things. With serverless, you can pretty much deploy and forget it.

00:20:19 - Christopher Burns

Do you find that serverless is not quite ready for production in your eyes, as a feature set, or sometimes a bit slow, not quite as good as running an actual server yet?

00:20:30 - Brandon Bayer

Serverless is definitely ready for production. What is difficult currently is integrations and setting up things. For example, setting up the database, you have to go to a whole different service to set up a database. You have to add a connection pool, and there's a bunch of steps and a bunch of things that can go wrong. But once you get it set up and working, it's pretty good.

I would love to have Vercel. They call themselves this deployment platform, or serverless for frontend teams, something like that. We need a thing like Vercel for full-stack apps that help you do the database side, serverless, queuing, background processing, all of that.

00:21:07 - Christopher Burns

I think DigitalOcean is actually working on it. I don't know if it's serverless, but they have this Git-based way of uploading your code and it just...

00:21:16 - Brandon Bayer

Yeah. That's similar to Render. But what I want is serverless. Doing server is fairly easy with Render, with Heroku, and now DigitalOcean. But we need that really easy experience with serverless.

00:21:29 - Anthony Campolo

You would need Netlify to buy FaunaDB.

00:21:32 - Brandon Bayer

It wouldn't have to be that far. It can just be at an integration level, but the platform just makes it really easy.

00:21:39 - Anthony Campolo

I joke because I mess around a lot with FaunaDB and these kinds of frameworks. I agree with you. Getting the serverless dream is so enticing, but you start trying to bash these pieces together and you're like, oh my God.

00:21:52 - Christopher Burns

So let's go on to authentication. My first question, and it's probably really stupid to ask, if there's no API, how is it secure? How is it not going to be hacked if I don't control that?

00:22:08 - Brandon Bayer

Well, there is an API. You just don't have to build it yourself. Whether you have an API or not, you still have to do authentication to make sure that the bad guys don't get your data.

00:22:17 - Christopher Burns

Yeah. And so authentication is done through third-party clients. What's your current client list?

00:22:25 - Brandon Bayer

That's actually not correct. By default, authentication is self-hosted.

00:22:29 - Christopher Burns

Self-hosted. Okay.

00:22:31 - Anthony Campolo

You provide a bunch of different versions, so you have Authn and Authz set up by default with sign in, log in, and log out. Then you can also do session management, and you can bring in stuff like Passport. So you're providing a ton of different functionality in terms of different ways to do authentication.

00:22:49 - Brandon Bayer

Yeah. So let me try to break it down here, real simple. Session management is how you track that the same person is making multiple requests to your database. How you authenticate them is a different thing. It's how you verify that they are who they are, not just that they're the same person from request to request.

We have session management built into Blitz.js. You can use that built-in session management with username and password, which we have by default. You can also use it with third-party login like Twitter or GitHub or social login. We have a Passport.js adapter that makes it really easy to plug in any Passport strategy into our session management system and use that third party for authentication. But then you still use the internal session management, which is really great for the full-stack nature. It's all nicely integrated. We'll probably add other adapters in the future.

00:23:44 - Anthony Campolo

Yeah, I saw this thing called SuperTokens. I'd never heard of this before. This is like an open source JWT thing.

00:23:50 - Brandon Bayer

SuperTokens is a company. I think it's one of the most secure authentication systems on the planet right now, probably, or at least widely available. The CTO of SuperTokens is Rishabh Poddar, and he is the brains behind our session management. The session management is based off of SuperTokens. It doesn't use SuperTokens directly, but it takes their lessons and learnings and how they do that, and we bring that into Blitz.

Right now we only have opaque tokens that are stored in the database. This is similar to how Ruby on Rails does authentication. You take a token, you stick it in the database. When a new request comes in, you look it up in the database to see if it's there and valid, and then if so, you're good to go. We're also going to add a more advanced session management that uses JWT that will have short-lived access tokens, plus long-lived refresh tokens for maximum security and performance.

00:24:43 - Christopher Burns

That's amazing to hear because I find security is one of those things that a lot of people, they're doing things by themselves. They're very generalist. Security is one of those things where you're like, am I going to get hacked? The more trust you can put in the framework, the framework is doing these things for you. The easier time you can spend on doing other things.

The reason I say that is, for example, the way Redwood has gone, Redwood is putting that auth trust into other companies like Auth0, Magic, Supabase. But it seems you've gone the other way, where you're saying trust the framework, the framework being the key factor into this security. What do you think the benefits are? One of them that I can see straight off the top of my head is monetary. You're not paying a third-party company to obviously keep your users' data.

00:25:35 - Brandon Bayer

Yeah, for sure. The other huge benefit is the ability to run it locally and everything works. You don't have to have internet access to test it locally. You don't have to set up webhooks and ngrok and stuff like that.

The other thing is that since we have our own full-stack authentication system, everything works together really nice. Because whenever you're doing server-side rendering and APIs, there are a lot of different places where you need things like cookies, and we can make that a better experience when it's all integrated.

00:26:04 - Anthony Campolo

Yeah, because you're already buying into the whole integrated monolith idea. So it wouldn't make sense to just say, oh, this one thing we should actually pull out. If you can get it all baked in, then that's what's going to ensure it's going to be done correctly.

00:26:20 - Brandon Bayer

Yep.

00:26:21 - Anthony Campolo

So did you already have the idea of what you wanted beforehand, or did you look at a bunch of different solutions and suss them out? Or is this something that you just knew because you've done a lot of this in the past?

00:26:35 - Brandon Bayer

Well, after I started Blitz, I was looking around. There's Passport, but it's kind of old, and it's like, oh, I'm not sure about this. Somehow, I think a friend told me about SuperTokens, and I looked it up and I was like, well, this looks really nice. Really secure and so forth. I reached out to them and they're like, oh yeah, we'll help you. I'm very thankful to them.

00:26:58 - Anthony Campolo

That's cool. Yeah. I remember when you were building it, it seemed like a massive task.

00:27:01 - Brandon Bayer

Yeah, it took a while.

00:27:03 - Christopher Burns

I've never actually looked up SuperTokens before, but they literally say we're the alternative to Auth0 and obviously AWS Cognito. Neato.

00:27:12 - Anthony Campolo

For that thing everyone likes. So let's get into some of the Blitz community. You've really put a lot of emphasis on community building in Blitz and putting community first.

00:27:23 - Brandon Bayer

Basically what I did was I built a community before the framework. When I tweeted out the initial tweet back in February that said, hey, I'm building this Ruby on Rails equivalent for React apps, I didn't even have a GitHub repo or anything. I just had a couple hundred lines of prototype code on my computer. But the tweet basically went viral in the tech world, so a lot of people got really excited.

One of my things in that announcement was, I need people to help me. Just let me know if you're interested. I got somewhere between 40 and 60 people responding, interested in helping. And a decent chunk of those have stuck around since the very beginning. Community has always been first from the very beginning.

00:28:07 - Christopher Burns

Was the name Blitz a community decision or was that your own?

00:28:12 - Brandon Bayer

No, I named it myself before I announced it, and I'm not quite sure. I can't really remember how exactly I got it, but I think everybody likes it pretty well.

00:28:21 - Christopher Burns

And a funny question was, what was that prototype called, if you can remember?

00:28:27 - Brandon Bayer

It was called Blitz.

00:28:28 - Christopher Burns

It was called Blitz.

00:28:29 - Brandon Bayer

Okay. So I started the prototype one week before I announced it. It was a very quick process from when I decided, hey, I'm going to do this thing because I was on a phone call with a friend, a Ruby on Rails developer, and we were going back and forth about the trade-offs between Ruby on Rails and React apps and this whole API thing. I was like, you know what, I think we can build this right now with Next.js and Prisma. It was like a week later when I announced that I was working on it.

00:28:53 - Anthony Campolo

A good framework needs a good origin story.

00:28:56 - Christopher Burns

And then my second question, why purple?

00:28:59 - Brandon Bayer

I don't know, I like purple. To me it signifies kind of royalty and splendor and majesty.

00:29:05 - Anthony Campolo

And why orange, Chris?

00:29:07 - Christopher Burns

Why orange? I just love asking people. Why colors? Because it literally is, I like that color. It wasn't Facebook or Twitter or Snapchat's color, so who cares? That's why I went for the multicolored logo on my startup. It's just got five colors in it. It's like, oh, we'll go with any of those colors.

00:29:27 - Anthony Campolo

You had put out this Blitz job board. This is something that I haven't really seen a lot of other meta frameworks of this size really pushing for, getting out and getting jobs in this type of stuff. So I think this is really great, and I'm kind of curious how you're thinking about this.

00:29:43 - Brandon Bayer

Sure. It was a few months ago now. I found a couple Blitz job postings in the wild on Upwork or something, and my mind was blown. I was like, what? There's already people hiring Blitz developers. That's a signal that we've made some level of success.

Then someone in the community was like, hey, I'll build a job board. So they built a job board, and there we go. We also have a jobs channel in Slack. Every so often we have a new Blitz job come up. It's pretty cool.

00:30:11 - Anthony Campolo

And so what are the jobs for? Like what types of projects, what types of companies?

00:30:16 - Brandon Bayer

Well, they're mostly building brand-new apps from scratch using Blitz.

00:30:20 - Anthony Campolo

So dashboard stuff?

00:30:22 - Brandon Bayer

Yeah, I think so.

00:30:23 - Christopher Burns

You're talking about jobs, and when someone comes to Blitz, do you think they tend to be beginners in React and these kinds of things, or more intermediate or more advanced? And what kind of jobs are looking for which range of developers as well?

00:30:37 - Brandon Bayer

I think it's a pretty wide mix of people who come to Blitz. There are definitely people whose first time using React is with Blitz, which is cool. And then there are also people that are very experienced. There's people coming from Ruby on Rails, people coming from Laravel. So it's a pretty wide mix.

The jobs specifically, I don't recall exactly what they were looking for. It's probably more mid-range, but I don't recall.

00:31:00 - Christopher Burns

I think it's amazing that some people's first time using things like React is with Blitz. That first time, they're then going to go, what's it like without Blitz? They're going to go, oh my gosh, I'm going back to Blitz. I'm using this forever.

00:31:17 - Brandon Bayer

Yeah. My dream is that Blitz makes it easy for people to come in and learn full-stack development, being able to build an entire thing and deploy their entire app from scratch, which is what got me excited with Ruby on Rails in the beginning.

00:31:32 - Anthony Campolo

Yeah, that perfectly describes what got me into this as well.

00:31:36 - Christopher Burns

One of the big things that I wonder with Blitz, obviously Redwood makes it quite public that they have a GraphQL API and that you can use it for other clients. Does Blitz have any plans to go into other clients like React Native, and how will that be handled if you already have a thought?

00:31:56 - Brandon Bayer

Definitely. The first step that we will do after 1.0 is to generate client libraries. Oh, let me back up. The auto-generated API today, you can use it directly from a mobile app. You just kind of have to add in your own API endpoints and stuff, and it might be a little tricky to keep it in sync if you're making changes.

But we can add a command that will generate a client library in any language. That will make it easy to just call those API endpoints from another app. That's one step.

00:32:26 - Christopher Burns

Okay. In terms of a client, you mean client like Prisma, too? So a callable library.

00:32:33 - Brandon Bayer

Yeah, maybe like how Firebase has a client library that you can run on the client. Similar.

00:32:38 - Christopher Burns

Just to give it perspective, because I know it's such a hot topic of why should you pick Redwood or Blitz. People go, well, I could need to add an app one day. You are thinking about that, and this is a direction you will go in. And with something like Redwood, you go, well, you'd use Apollo Client to communicate with it. You're going to handle the communication between both clients.

00:33:02 - Brandon Bayer

Yeah. So the first step is just generating a client that you can use, and we can do that in multiple languages. Then we can go a step further with any JavaScript-based apps like React Native. I'm pretty sure, I haven't prototyped it yet, but I'm pretty confident I can make it happen to have the same zero-API experience with a React Native app.

So you have your Blitz app in the same repo, you have your React Native app, and then if you want to call a function like a query, you simply import that query into your React Native code. Then we have some way at compile time to swap that React Native code out with an API call.

So this is a step beyond the manual client library. That is like the separate thing you kind of have to think about and use. This really unifies it into one massive monolith where you don't have to think about any APIs anywhere, and you just import server code anywhere you want, and it just works.

00:33:58 - Christopher Burns

That's kind of blowing my mind, if that can happen. I've worked on both React Native apps and React apps, and if that can be done, I'd be like, mind blown.

00:34:06 - Brandon Bayer

I'm pretty confident it can be.

00:34:09 - Christopher Burns

Obviously you've not tried it yet, but do you think you will be going with Expo as a base or a custom React Native base?

00:34:17 - Brandon Bayer

That's a good question. Ideally, it would work with both.

00:34:19 - Christopher Burns

Yeah. If you don't know what Expo is, it is a client that sits on top of the React Native code. It gives really cool features out of the box, like quick reload, scan a QR code to instantly open the app. A lot of default modules, so like the standard date picker from iOS and Android, it will automatically include that so you don't have to do it.

But obviously, React Native is forever changing and changing a lot faster than React, so all the answers still aren't there for everybody on how we're going to include it in FSJam. I think it's going to be really, really cool when we start seeing multi-client support, because that's when people will look at it again. I believe it's like, oh, it's no good if it can just do my website. Well, no, actually it can do your website, your app, and anything else you're going to include.

00:35:12 - Brandon Bayer

Yep.

00:35:12 - Anthony Campolo

Curious what we're talking about here. Does this relate to the isomorphic domain layer, or is that a different idea? That's a different idea. Okay, cool. That's a very long post by Rudy Yardley, who's another member of the team. It's epic, definitely put a lot of work into it, and it's a really fascinating idea. So that's a different... would that be a different way of solving a similar issue, or does this totally have nothing to do with it at all?

00:35:37 - Brandon Bayer

The idea with that is the ability to have offline apps. Okay. So with offline, there's offline-second, offline-first, and so on. Many apps need, at some point, some type of offline functionality, and it's really difficult. Those type of things that are really difficult are the ideal candidates for a framework to do the hard work to solve, and then everybody can benefit.

So that's basically what we're doing with Blitz in the API layer. We're making that easy. It'd be amazing to be able to do that with offline and somehow make that work. That's an even higher level, like a harder thing, and so that could be who knows. That could take a while. But yeah, that's an interesting post about some ideas on how that could happen.

00:36:19 - Christopher Burns

Do you remember when Create React App had a service worker by default, and if you did something wrong, it would break your client?

00:36:26 - Brandon Bayer

Yep.

00:36:27 - Anthony Campolo

Yeah, I remember that too.

00:36:28 - Christopher Burns

Yeah, I do remember that. Good times. Talk to us about some of your key members and what they're building with Blitz.js.

00:36:37 - Brandon Bayer

So Simon is a level-two maintainer, and he built our custom serialization library called SuperJSON that we use so that dates and everything else in JavaScript are automatically serialized and deserialized. Then he's building a startup called Quirrel that is background processing, async processing, and queues for Next.js and for Blitz.

So how it works is his service manages the queues and things, and then it calls back to your app to actually handle the processing. You can define your handlers, your queue handlers, in your code, and then you import those handlers basically anywhere else in your app and you can add to that queue. So it's pretty slick.

00:37:17 - Christopher Burns

And have you found that as Simon was building Quirrel, that a lot of feedback has come back on how to make Blitz better?

00:37:27 - Brandon Bayer

No, not much. Well, a little bit, but not too much. His core app, I'm not sure if it's Blitz, because it's entirely backend.

00:37:35 - Anthony Campolo

Repeater.dev is like the version of this in Redwood. And it's also built with Redwood, but it's a real app.

00:37:42 - Christopher Burns

Yeah, but Quirrel is adding support for Redwood, so it's going to be interesting to see both of them just fight it out in the background.

00:37:50 - Brandon Bayer

One question with Repeater is, does Repeater handle the processing or does it call back to your app?

00:37:55 - Christopher Burns

I think it just calls back to your app, and then your app will reprocess whatever you need to process.

00:38:00 - Brandon Bayer

Actually, back in September, I converted one of my client apps from Rails to Blitz. It was kind of a Frankenstein app. It had Rails and Hasura and Next.js all together. So now it's mostly Blitz. Ruby on Rails is still running the migrations. Just a few things I need to switch off of there to be fully Blitz.

But in that process I definitely was like, oh, this needs fixing, this needs fixing, this needs improvement. That definitely helped some things.

00:38:29 - Christopher Burns

Because it's that thing, as we brought up quickly with Repeater, it's one thing to build the framework, but then it's a totally different thing to use it and actually build something with it. You are a consultant, so people can pay you for advice and some code. When you get new clients, do you try to say you should use Blitz, or are they coming to you and saying, I want to use Blitz, here's some money?

00:38:55 - Brandon Bayer

Both.

00:38:57 - Christopher Burns

Both.

00:38:58 - Brandon Bayer

I did start on a brand-new Blitz project back on September 2nd, and then it kind of got stalled out. There were other clients I talked to that were fine for me to use Blitz. That one didn't pan out either. But I'm still busy on this other app, so that's awesome.

00:39:14 - Anthony Campolo

Okay, cool. So kind of closing out here, why don't you just tell us a little bit about what you're really excited for in terms of the future of Blitz? What's coming up in the near term?

00:39:24 - Brandon Bayer

The near term, I'm excited to get the official beta announcement out very soon, hopefully within a couple of weeks. Then working towards 1.0, which is mainly fixing up all the bugs and kind of UX improvements and edge cases. So wrap that up and probably February around there, maybe, hopefully have a 1.0 launch. That'll be really exciting. Then I can focus more on these future things like the mobile app, React Native integration, and so forth.

00:39:52 - Christopher Burns

We've not brought it up, but I know you're keeping a real tight release strategy with, is it, LTS support as well?

00:40:01 - Brandon Bayer

Right now we aren't.

00:40:02 - Christopher Burns

You're not.

00:40:02 - Brandon Bayer

But once we get to 1.0, I'm planning to institute some type of release schedule like Ember. It's a very predictable release cycle. How Ember does it: every new stable release is in beta for six weeks. So it gives it a certain amount of time to work out any issues before it goes stable.

Then there's also a long-term release every six months, a new one to focus on stability. There are all these standard processes to make sure that there are minimal bugs at each stage.

00:40:31 - Christopher Burns

And the other thing that I think I remember you speaking about in your Prisma 2 Day talk, that we'll obviously link in the description, was that you're trying to keep breaking changes to a minimum.

00:40:44 - Brandon Bayer

How Ember handles breaking changes is they deprecate changes in a minor release. And then in a major release they'll remove the deprecations. It's always very clear. There's strict semver, etc.

00:40:57 - Christopher Burns

To the end users, if you update your Blitz app, it's not going to be like, right, that no longer works. It's going to be, that's no longer going to work in the next version.

00:41:08 - Brandon Bayer

Yeah. And Next.js basically never has any breaking changes. We'll probably not go that far. We'll probably have some breaking changes, or potentially sometimes the best improvements require that.

00:41:21 - Anthony Campolo

Yeah, we've had a couple of breaking changes for things like we used to have our forms in the web folder and then we abstracted it out. So that kind of broke some stuff. As long as you can clearly communicate it and just give the steps of what it's going to take to fix, then especially with where most of these apps are at this stage, it shouldn't be that hard to fix. You just got to give guidance.

00:41:44 - Brandon Bayer

Yep.

00:41:45 - Christopher Burns

Awesome. It's been a really good episode. I'm sure we would love to have you back on again, but you're going to be back on soon for our Christmas special. Our Christmas special that's going to have David Price from Redwood, Brandon Bayer from Blitz, and Chris Ball from Bison. If you have any questions, tweet them at us and I'm sure we'll get around to them. What do you think about that, Brandon?

00:42:11 - Brandon Bayer

That sounds awesome. It'll be fun.

00:42:13 - Christopher Burns

It's going to be really fun, and I'll try to talk the least.

00:42:17 - Anthony Campolo

Yeah. Thanks a lot for being here, Brandon. Like I said at the beginning, I got a ton of respect for your work, and I'm really excited to see where Blitz is going in the future.

00:42:26 - Brandon Bayer

Cool. Thanks for having me.

00:42:28 - Christopher Burns

Thank you to Brandon for being on this episode. We really appreciate it.

We have some good news. We're now experimenting with two other channels. We're experimenting with clips on Twitter, so short clips. If your backlog of podcasts is getting big, we're going to try and keep you up to date on Twitter, Facebook, and Instagram with the quick best bits of every episode.

The other channel is now YouTube. We are now releasing the podcast on YouTube. It's not video form, it's just audio. So people who are at desktops or have YouTube Premium will be able to give it a listen. We're really trying to make it accessible to wherever you are.

If you have any comments or tips, please get in touch with us. And lastly, if you like this podcast, please review us on Google, Apple, anywhere that you get this podcast, and also tweet us because we really love to hear what you say. That's all from me, and we'll speak to you next week.