Ben:
I'm really excited to introduce Brandon Bayer. Brandon is the creator of Blitz.js. How are you doing Brandon?

Brandon Bayer:
Good, how are you?

Ben:
I'm well, and Brian Neville-O'Neill is here too. I want to jump right in. Brandon, for folks who aren't familiar, could you give a quick overview? What is Blitz.js?

Brandon Bayer:
Sure, so Blitz is a full-stack framework for React apps. So it is built on top of Next.js as the foundation for all of the React part of it. And then we add a "zero API data layer" that gives you this full stack and the ability to send and receive data from the frontend. And then we also have a number of CLI tooling and things built in for code scaffolding, and we have Prisma 2 in there by default for database migrations and access.

Ben:
Got it. So is the idea that you could build any full-stack application in Blitz or is there a particular area of development that you're focusing on?

Brandon Bayer:
Yeah, it could be used for pretty much anything. I think a bit more towards the target market is SaaS applications. So agencies, freelancers, consultants, various companies that are building software that serve as applications from scratch. It's a really good framework for that.

Ben:
You mentioned a number of words in your description, React.js, Next.js. So obviously very popular best in class tools there, Prisma as well. So Blitz, it sounds like is incorporating a bunch of best in class tools for each part of the application stack and then building, correct me if I'm wrong, but basically building a lot of the glue and the tooling around all these disparate tools. So could you talk in a bit more depth about the specific areas you're building that is unique to Blitz?

Brandon Bayer:
So by far, the biggest thing is our zero API data layer. And to give a bit of context, I started doing web development with Ruby on Rails, and with Ruby on Rails there's no API, right? You can basically access your database directly in your view templates. And so it's, it's very simple, you don't have to worry about multiple different deployments frontend, backend. It was just all one monolith. I started there and then went on and learned React and fell in love with React. And I love how you can build user interfaces with it, but it comes with this cost and this complexity of having an API layer, because you have to have some way to get the data from your backend to your frontend. I embraced that for a few years, like "Oh, this is fine because I like React so much," but eventually it wore me down and I was like, "There's got to be a better way."

Brandon Bayer:
So I ended up coming up with this thing, which we call the zero API data layer and basically it abstracts the API into a compile step. And so it allows you to write functions that run on the server. So we call them Blitz queries and mutations. And you could also think of them as like a controller from Ruby on Rails. And so you import that function directly into your components, and you can just use it there, you pass it to a hook or whatever, and you use it directly. So there's no REST API or no GraphQL API, no data fetching. You don't want to have to use Redux. And our hooks are built on React Query, which gives you caching and cache and validation, polling, refetching. And so was a really nice end-to-end data layer that's super easy to use. And in fact, for a while, whenever I was using it I would keep being like, "Wow, this is so easy. How can it be this easy?" And I've got used to it now, but it's pretty awesome.

Ben:
That's great to hear that it's built on React Query, because one of the questions I was going to ask is basically how do you handle all of the messy aspects of building API layer code, things like error handling and retry logic? So could you dig in a bit there? How do you access the features of React Query with this model where the actual React Query code, it sounds like it's being written automatically at compile time, and not something the programmer actually interacts with?

Brandon Bayer:
The React Query code in part of the library is not some of the generated code, but we simply wrapped the React Query hooks with our own hooks. And so we hooked into the cache layer a bit and add in our access points and React Query is great because it gives us all sorts of access directly to the cache. And then we expose utilities to you too, so that you can also directly access and modify the cache. One thing you mentioned was error handling, and that's a really awesome feature that we have in Blitz that I've never seen anywhere else. And it basically extends the try-catch model of error handling all the way in the full stack. And so you can throw an error in your server code and then catch it in your client side code with a React error boundary.

Brandon Bayer:
And so it just works, right? So, if you're using a query and inside that query, you throw an error because they're not authorized or the item isn't found, for example, then you can have an error boundary in your app at the top level or somewhere else. And it'll literally catch that error all the way from the server. And then you can say, "If this error is an instance of authentication error render a login screen," or if it's an instance of not found error then render a 404 page. And so that set up by the default is pretty sweet.

Ben:
And one of the other tricky aspects of building an API layer is authentication and security. So tell me a bit about the approach Blitz takes to helping avoid those annoyances of building a full stack application.

Brandon Bayer:
Definitely, it's one of the, most important, but also one of the... can be most frustrating parts. So I'm happy to tell you that new Blitz apps come with authentication set out by default. So when you run Blitz new and generate a new app, straight out of the box you can create a user, you can sign up as an account and then log in and log out. It's just there. So you don't even have to set it up. Now how that works is we built a custom session management library, that's based on the principles of SuperTokens, which is a authentication start-up, and we have opaque tokens that are stored in the database. So there's a more traditional authentication approach like Ruby on Rails uses. And then we're also be adding a JWT session management option. So an advanced option for people who need extra extreme security and also scalability.

Ben:
So take me through the components of a modern full stack application all the way from the lowest level, be it the database, through the server code API layer, all the way up to the frontend with querying state management view layer. You mentioned a few of the tools that Blitz integrates, be it React for view layer and Prisma for database layer, but could you tell me a bit more about each aspect of the stack? What are the tools that either Blitz allows you to bring in or the opinions you have on which tool you should be using?

Brandon Bayer:
So the main thing is Prisma, Prisma 2 comes by default. Blitz is database agnostic so you can remove Prisma and it'll work fine, but we think Prisma is great so we give it to you by default and that's used for database migration. So you can define your schema declaratively, and then run Prisma migrate and it'll migrate your database, and then you can also use that migrations and production. And then also it gives you the database client, so you can call db.User.FindMany, or FindFirst, or update, delete, et cetera. And that's all fully written in TypeScript. And so if you're using TypeScript, then you have fully typed database access based on your database schema, which is super awesome. We also have a lot of the other tooling things that most people use, like Jest for testing, Prettier for formatting your code, ESLint for linting your code, and we have Husky, which is for git hook. So whenever you run git commit, it'll automatically run the linter for you and then git push it'll run some tests. And then, yeah that's all in your control. You can customize that, but that comes by default.

Ben:
And how do you balance being opinionated in certain areas of the stack? For example, correct me if I'm wrong, but I imagine it would be hard to remove Next.js from a Blitz app, because that's a core dependency, but it sounds like in other areas of the stack, the developer can choose which tool they want to bring in. How do you balance being opinionated in certain areas versus choosing the areas where you want to allow developers to bring in their tool of choice?

Brandon Bayer:
It's a bit of a difficult problem, but one of our foundational principles is loose opinions, which I don't know if I've really heard anywhere. Most people's like strong opinions, loosely held or something, but I call it loose opinions because we have opinions, but most of them are loose, they're not enforced. In fact, they're easy to change. So one issue I had with Ruby on Rails is it is difficult to go outside the bounds of what Ruby on Rails wants you to do, but with Blitz it's much more flexible. So our file structure, there's nothing really magical in a file structure besides certain folders like queries and mutations than pages, but you can organize your files however. You can go beyond or outside of what the Blitz recommendation is for file structure.

Brandon Bayer:
And then the main strong opinions is the zero API data layer. That's really the main thing. It's like, this is how you do your full stack database access, but when it comes to form, styling, et cetera, most of that, we just leave to you and we're coming up with nice ways to get you up and running with those. So when you create a new app, we ask you which form library do you want. And then we have recipes that allow you to install styling libraries with one command. So Blitz install Tailwind, Blitz install Chakra, Blitz install Material-UI, and that will integrate and set up. It could be two to 10 steps for each framework, depending on what they're doing, adding the providers, but you get that in one command.

Ben:
And so taking a step back, you mentioned Rails was one of your inspirations for building Blitz, and there's some other prior art here I guess, there's, I would say older because they maybe have been around for 15 or 20 years, like Rails and Django, and then there's some more recent full stack frameworks. I mean, one that comes to mind is Meteor. So I'm curious if you're familiar with Meteor, how does the approach you're taking with Blitz compare to what the Meteor team built? And I guess you started recently 2020 or so versus Meteor starting a number of years ago. What has starting now allowed you to do that Meteor didn't have available at the time?

Brandon Bayer:
I've never used Meteor, so can't offer a lot of a smart answers to this, but I've heard the Meteor team talk and they're now Apollo. So they pivoted from Meteor to Apollo. And I think in a lot of ways, they were early and what they're trying to do with the end-to-end data layer they couldn't really fulfill their vision and GraphQL better fulfills that vision. So that's why they pivoted there. And another thing that comes to mind is that wasn't built on React, which I think now it does use React. But my understanding is that Blitz is just a lot more flexible. Meteor, I think, required Mongo as your database, and so as much more restrictive and prescriptive than Blitz is.

Ben:
Yeah. That was my understanding as well is that Meteor made the choice to be very, very prescriptive and there are advantages there, I mean, I think for a larger teams it can often be helpful to have a framework that's very prescriptive, and there's one right way to do things. But with the pace of innovation in the world of frontend over the past few years, there's just so many new tools coming out, and if you're not somewhat modular it can be hard to keep up with the pace of innovation. I believe that was part of what led to Meteor being a bit less popular is the rise of React, and these other tools that they didn't allow to integrate in a Meteor app until more recently. And so looking at the future and your roadmap for Blitz over the next year or so, like what are you most excited about things that are going to come to Blitz in the future?

Brandon Bayer:
Well, the first thing is getting to 1.0. We're transitioning to beta right now. Should have an official beta announcement relatively soon, and it might be early January at this point, but then getting to 1.0, hopefully a couple of months after that. And then beyond that, the big thing that I'm excited about is making integration with mobile apps really nice. So that's a common question is, well, there's no GraphQL API, how do I do a mobile app? I mean, you can add a GraphQL API to Blitz and use that. Because sometimes your needs are totally different for your mobile app versus your web app, and sometimes that's fine. And then we can also add ability to generate client libraries. So take the Blitz queries and mutations and run a command and it'll generate say a JavaScript, or maybe even other languages, a library that lets you just easily call functions like git orders, git users, or whatever your functions are.

Brandon Bayer:
And then beyond that, the real dream is to have the same experience with web as with mobile. So have your React native code in your Blitz app, like a monorepo one monolith and then import your Blitz queries or mutations directly into your mobile app code, your React native code. And then we would have it compile stuff to turn that into a runtime API call too. And so if we can accomplish that, which I'm pretty sure I can, then that will be a really awesome experience because you can have web and mobile apps without any API, no REST and no GraphQL. And that would just be like an incredible experience.

Ben:
I saw in GitHub you really start to build a community around Blitz. You started the project, but now there're many hundreds of contributors, and I'm curious like how have you approached building community and encouraging folks to contribute to the project?

Brandon Bayer:
Just one slight correction. We're only at like 170 contributors, not many hundreds.

Ben:
Okay well-

Brandon Bayer:
We many thousands of... We do have stars, we're almost to 6,000 GitHub stars. But to answer your question, when I first announced that I was working on Blitz back in February 2020, I didn't have a GitHub repo, or anything. I had a video clip of my prototype, but I was like, "Hey, I'm building this Ruby on Rails equivalent," and it went viral. But one of the things I asked in that thread was "I need help to build this, so if you're interested..." I got a form for people to fill out, and there was I forget something between 40 and 60 people responded that they was interested in helping in some way.

Brandon Bayer:
And so that was like the initial community. So the designer designed the logos, designed the new website we're working on. She came through that and just said, "Hey, I want to help." And a lot of the other early contributors are still around today helping in various ways. And I've been very intentional from the beginning in like what I want the community to look like. That it would be very open, warm, welcome, friendly, and so it's worked out pretty well so far.

Brian Neville-O'Neill:
In preparation for this interview, I was going back through the old Reddit threads, and the React subreddit. And I noticed that there was a pretty big difference between how the people in that subreddit reacted say in February than say April. And one of the, I don't know if they were criticisms, but one of the criticisms I guess, was exactly that. It seems like a marketing ploy or at the very least you've got our email addresses, I don't have a GitHub to look at. Would you do that again? Because I was like, "That's actually sort of cool, maybe we can do that."

Brandon Bayer:
Yeah. I mean, that worked great for me. I mean, if it would have fallen flat, if nobody was interested, I probably wouldn't have worked on it, but it was a very clear signal that a lot of people were like, "Yeah, I'm really interested in this." And so it gave me the motivation to actually go make it happen.

Brian Neville-O'Neill:
Yeah, because then a couple of months later, I don't remember what the title of the thread was, but whatever the one in April was, there was really no criticism or at least no questioning. Everyone got it a lot quicker.

Brandon Bayer:
That was probably the alpha launch whenever they actually start using somewhat.

Brian Neville-O'Neill:
Yeah. Again, in prep for the interview I was looking at what all the initial reaction was. And I wonder if you have a stock answer to like, "Why do I need an SPA when I could just use Rail in the first place?" What do you usually tell people when that comes up?

Brandon Bayer:
Well, the best answer I think is a testimony from one of the people that's been using Blitz for many months now. And he said that he was a professional Rails developer for 10 years. And in just a few months after using Blitz, he's 10 times more productive with Blitz than he ever was with Rails. So it's crazy but then there's other people are saying like, yeah, it's many times more productive than whatever they were doing before. So if you want to use React and the power that it gives you for building user interfaces, then Blitz is amazing. If you love Ruby and ERB and that stuff then yeah stay with Rails. But there's a large middle ground of people who are, they really would rather use React, but they want the productivity of Rails, then Blitz is the answer for this group of people.

Ben:
Is there a getting started story for existing apps? If I already have a full-stack application that is not built from the ground up on Blitz, can I start using Blitz on part of the application, or is there a way to bring Blitz into the whole thing?

Brandon Bayer:
Depending on what your app is built with currently. I mean, you can migrate it just like you would, anything else piece by piece. If it's built on Next.js, then it's very easy because you can basically take all your Next.js code and just pop it in a Blitz app or like vice versa. I don't think we have a doc page on this quite yet, but we will get one, but basically you just swap out, change the Next dependency for Blitz, and change next.config.js to blitz.config.js and use `blitz start` and it should basically work.

Ben:
And how would you advise someone who's really excited about Blitz, but slightly skeptical to adopt it in a corporate setting? Given it's so new what would you say to someone who's a bit worried, but really excited about the project?

Brandon Bayer:
I would say give it a try, spend a few days, see what you can build, and it might be fast enough that you're like, "Wow, this is amazing. Let's just do it anyways." So like I said, we're transitioning into beta phase right now. So there's not really any major changes or any major bugs that I'm aware of. There's some edge cases and stuff, but most people don't run into those. Also, we have a list on our Wiki, on our GitHub repo and the Wiki there we have a list of production Blitz apps. So apps that are running in production today and it's quite a sizeable list that's definitely not all of them. I know that there's more and some of the source code is available there too that you can check out. I'm running Blitz and production personally, and it works great. So once you're running in production, it's mainly Next.js code. The foundation has already been proven for four years now, right ? Next.js, so that's a huge thing that we have going for us and stability out of the gate.

Ben:
And taking a step back Brandon I'm curious, how did you get into the world of frontend? And I'm just curious to learn a bit about your career.

Brandon Bayer:
I've ended up quite a bit different from where I started. I started with an electrical engineering degree from Wright State here in Ohio. And in the process of that, I took a software class on C and I was like, "Wow, this is amazing." So then I got an intern as a software engineer doing embedded C programming microcontrollers in construction lasers. Did that for about five years, and then moved on to embedded Linux with C++, and eventually got my hands on JavaScript. And then I took a online bootcamp and learned Ruby on Rails, and that's how I got into web development and HTML and CSS and JavaScript. And that gave me all the foundations that I needed to know about just how the web works. And then from there I basically taught myself React and so forth, and then the rest is history.

Ben:
Wow. So you really worked your way up the stack from all the way at the bottom up.

Brandon Bayer:
Yep.

Brian Neville-O'Neill:
Is electrical engineering at the bottom of the stack? I didn't know that.

Brandon Bayer:
Yeah basically, I mean, that's how you're making the circuit boards that run your computer.

Brian Neville-O'Neill:
I guess that's a strong point. Now it seems like it's a good time of year to ask what is it that you're looking forward to next year in front end? Maybe not Blitz related, but certainly if there was something that you were like absolutely. But generally out there, what is it that you're looking forward to?

Brandon Bayer:
That's a good question. I haven't thought about that too much. One thing that I would love to see is easier offline functionality in apps, where it's either part of your application is offline or maybe the entire thing, so it's more like offline first. And that's something that's very difficult and I've tried to do some in the past. That's something that potentially Blitz could solve. Other than that, I'm pretty happy with where we are with like Tailwind for styling, I love that, React Query for the core client side data pitching stuff, but it'll be exciting to see what else comes. This year brought Blitz so what's next year going to bring? Hopefully not a replacement for Blitz.

Brandon Bayer:
If you want to contribute to Blitz in any way, we would love to have your contribution, love to have you in the community. We have a pretty active Slack community. There's almost a thousand people on there now, and so we're very friendly helping each other work on stuff. On our website, blitzjs.com, we have a doc page on how to contribute, and we start at the very basics. If you've never contributed to open source before we have a few steps, watch a video on how to do pull request and how to use GitHub. And then we have links to issues that are ready to work on. So we have a bunch of issues that are labeled, ready to work on, and those are available for anyone to come along and pick up. We also label issues good first issue and good second issue. So if you're wanting to get started that you can take a look at those.

Brian Neville-O'Neill:
Well, Brandon it's been a pleasure having you on the show. We really appreciate your time and telling us about Blitz and why you would use it all the time instead of Rails, and to what you're looking forward to next year.

Brandon Bayer:
You're welcome. Thanks for having me on. It's been an honor.

Brian Neville-O'Neill:
Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me, even though that's not a popular option. It's brian@logrocket.