Blitz is a hyper productive framework for building fullstack React apps. You'll learn why I created Blitz, it's advantages and disadvantages, how it makes you so productive, and for what cases you should consider using Blitz.
Blitz.js - The Fullstack React Framework
AI Generated Video Summary
Blitz is a framework for building full stack React apps with a monolithic architecture and no API layer. It uses Next.js and Prisma 2 and follows convention over configuration. Authentication and authorization are set up by default, and adding social login is easy. The Blitz community emphasizes inclusivity and welcomes contributions. The future of Blitz includes a stable release cycle and the vision of bringing the Zero API experience to mobile.
1. Introduction to Blitz and Full Stack React Apps
Hello, everyone! Today, I'm going to talk about Blitz and building full stack React apps. I wanted to love full stack web development again and be extremely productive. To achieve this, I knew I needed a monolithic architecture and no API layer. Initially, I thought server-side rendering was the solution, but I wanted something even easier. That's when I realized you could write server-side functions and import them directly into React components.
Hello, everyone, it's so exciting to kick off the second day of React Summit. We had awesome talks yesterday, and I'm excited to talk this morning about Blitz and building full stack React apps. So let's get into it.
I was building full stack React apps for a few years. And I happily put up with the complexity and struggle required to do so. And I did that because I loved building user interfaces with React more than any other way. But the honeymoon ended. And I became increasingly frustrated with rest, with GraphQL APIs, Momex State Tree and a host of other API services and libraries, managing multiple servers, managing multiple servers, multiple deployments, etc. Anything that got in the way of me building features slowly depleted my morale.
I really wanted to love full stack web development again. I wanted to be extremely productive again at building full stack apps. I wanted to focus on building features instead of mostly marshaling data all around the universe. So I decided enough was enough and I set out to build the best possible developer experience for full stack React apps. Well there there was two fundamental things that I had to have in place to achieve the developer experience that I wanted. Number one, it had to be monolithic. And a monolith means that there's only one thing. Everything is all together in one thing so there's only one thing to develop, there's only one thing to deploy, there's only one thing to reason about as you think about your entire architecture. And a monolith is just really awesome. And in my experience with Ruby on Rails, I came to really appreciate the benefits of a monolith. Secondly, is no API. The API layer in React Apps is the biggest source of complexity, headache, heartache, holes in the wall, Oh, whoa Brandon, that's too much, it slows you down more than you would think about. And I knew that I had to go somehow. Okay Brandon, that sounds great, but how are we going to do this? Well, does it mean we have to go back to 2004 and do server-side rendering? I thought so. And I was prepared to embrace that. Cause I wanted this developer experience, without the API, so bad, that I was willing to go down that route. And in fact, when I first announced that I was working on Blitz, the initial prototype was server-side rendered. But the early Blitz contributors and myself were trying to figure out what would the architecture of Blitz really look like. We were exploring all sorts of things, model-view-controller, basically everything under the sun. So one day, I was laying in a hammock in Thailand, thinking about this, and I asked myself, what would this look like if it was easy? So I thought about that for a bit, and I realized that if it was easy, you could write functions that run on the server and then import them directly into your React components and use them directly. So you could use them without doing fetch calls or API endpoints or HTTP or any of that.
2. Blitz Key Factors, Features, and Principles
It would just work. And so I was like, wow, that's pretty awesome. This could be a game changer. And it turns out it was. Now you know about the single biggest defining factor of what Blitz is. Next.js is a wonderful framework that is fast, flexible, performant, and provides a great developer experience. Prisma 2 is the modern way to access databases, with a nice schema, declarative migrations, and fully-typed database access. Blitz has three key factors: full-stack and monolithic, no API required, and convention over configuration. It also has seven main features and principles: scalability, no API required, convention over configuration, loose opinions, easy to start and scale, and stability.
It would just work. And so I was like, wow, that's pretty awesome. This could be a game changer. And it turns out it was.
Okay. So now you know about the single biggest defining factor of what Blitz is, so let's talk about the second two. I mentioned that I was just frustrated with full-stack web development in fact, but throughout that entire time there was one thing that constantly shone through the mess, and that was Next.js. Next is such a wonderful framework. It's so fast and flexible and performant and it's a nice developer experience. And so it was so clear that it was a perfect thing to build on top of and add all the other things that you need for full-stack web development.
Okay, so now we need a way to talk to the database. And back in February when I started Blitz, Prisma 2 was just coming out in beta, and it was just pretty obvious that this was going to be the modern way to access databases. And if you don't know about Prisma 2, it's awesome because you have a really nice schema that you can define and have declarative migrations from that schema. You generate a TypeScript client from that schema, and so you have fully-typed database access. And then in Blitz, those types can flow all the way down to your frontend. So everything is fully typed, end-to-end.
Alright, so those are the three key factors of what Blitz is. Let's talk about the seven main fundamental features and principles that define everything else we do. So, full-stack and monolithic, I touched on that. One thing I want to mention is that a modern monolith scales much better than, like, Ruby on Rails, for example. And that's because you can deploy Blitz to a serverless environment. Not just a server, you can do both. But if you deploy it serverless, all your server endpoints can be independently scalable as serverless functions. So the whole scaling thing with a monolith just sort of goes away. So that's really awesome. Secondly, API not required. Number three, convention over configuration. Number four, loose opinions compared to strong opinions that are hard to go against. Number five, easy to start, easy to scale. Number six, stability.
3. Blitz API Layer and Architecture
And number seven, community over code. Okay, so let's talk about this API layer a bit and get into how we actually do this and how it works. We abstract the API into a compile step. So as you're developing your app, like I mentioned, you don't do any API stuff, you just import the server functions into your front end and then at compile time we swap that out with an HTTP API. And so you do get client-side rendering, but without any of the API headache.
Alright, so let's look at an architecture diagram here to maybe give you a rough idea of how this all fits together. So along the top is client-side code, along the bottom is server-side code. And the purple boxes are pages, React pages. And so you can see that in a single app you can have a server-side rendered page and a client-side rendered page side by side. And they can use the same server code. So the green boxes at the bottom are a query and a mutation. And both of those pages use the same query. And then at build time, this middle layer is inserted automatically for you, which is a JSON HTTP API. So all your queries and mutations are exposed at a unique URL. And you can use that directly for mobile apps or third parties or anything else.
Okay. Let's talk about convention over configuration. This means by default, things just work. And it doesn't mean no configuration. It just means configuration is optional. So most of the boring stuff is completely done for you out of the box. And you especially see a lot of this a principle whenever you generate a new app. Because it has so much stuff set up for you, basically all the things that you would set up you would take the first week or so of a new project and set up all that's done.
4. Blitz Authentication and Authorization Setup
We include ESLint, Gear, Jest, Husky githooks, and more already set up for you. Authentication and authorization are set up by default in new apps, allowing you to immediately sign up and log in as a user. Adding social login is easy with the Passport.JS adapter.
So we include ESLint, Gear, Jest, Husky githooks, and a number of other things just already set up for you. Now the big thing that's really awesome is authentication and authorization is set up in new apps by default. So that means when you run Blitz new in your app name and generate a new app you can immediately sign up and log in as a user. And isn't that amazing? You don't have to ever do authentication stuff for so many projects because you get it out of the box with Blitz. And then if you want to add social login, we have a Passport.JS adapter that you can just drop in on a single file, and very easily add in GitHub authentication or any other type of thing that, anything there's a Passport.js adapter for.
5. Code: Sign Up Mutation and Git Project Query
This part covers a sign up mutation that runs on the server, using Zod for input validation and Prisma 2 for database operations. It also explains how to use this function in a sign up form and the simplicity of the process. Another topic discussed is the git project query.
Okay, let's get into some code. Alright, so this is a sign up mutation that always runs on the server. And basically this same thing is what you'll get in a new app by default. This will be generated for you. So, you can see we export a default async function. And the first argument to that is the argument to the mutation. And the second is a context parameter. And this context parameter is provided by middleware and Blitz. And so by default you have one middleware configured, which is session middleware. And that's built in session management from Blitz.
Ok, and so inside this mutation, the first thing we're going to do is validate the input. And we use a library called Zod that's really awesome for both runtime validation and TypeScript types. So you're guaranteed that after this line, email and password are both strings, and the password is has a minimum length. Ok, and then we're going to hash the password and then we're going to create a user in the database. And this db object is provided by Prisma 2. And so you can see how nice it is just to create a user. So email, a password, and you get that user back. And then secondly, the last thing we do before returning is to create a new session, which is how you log in. And you can set the user ID, roles, anything else you need in there to use on the frontend. Ok, so fairly simple.
Now, how do we use this? Well, you import this direct function into your component. And so here is the sign up form. And you can see we import, it's on the 5th line I believe, we import that function we were just looking at. And we pass it to the use mutation hook inside the component. And then we can just use that mutation thing inside the own submit hook. And so you just call it a wait just like a regular function there. And it just all works for you. So super slick. Alright, let's look at another one. This is a git project query.
6. User Authentication, Community, and Contributions
In this part, we discuss how to ensure user authentication and authorization in Blitz. We also cover the use of the useQuery hook, which simplifies the process of fetching data. Getting started with Blitz is as easy as installing it globally as a CLI and running Blitz new to generate your app. We emphasize the importance of community and treating every person with dignity and worth. We invite contributions in the form of code, documentation, tutorials, and more. Donations and sponsorships are also appreciated.
So you can see again we get some inputs and then the contex parameter. And the first thing we do in this case is call session.authorized And this is going to ensure that the user is logged in. If it's not it will throw an error. And that error will propagate all the way to the front end and it will show either a login form if they're not logged in or it will show it on an authorized page if they don't meet the required rule. And of course you can customize that whatever you want. But that's the default setup. So we find the project and if it's not we don't get the project and we throw a not found error and again that propagates to the front end and shows a 404 page.
Alright, so let's use this thing We simply import this function over into your component. And inside this project component the first thing we do is get the parameter from the route. So this is project ideas. A dynamic parameter that you get from the url and then we have a usequery hook that you pass that query function we were just looking at, you pass it to usequery and then the second parameter to that is the argument so where id is equal to the id of this route and then you get that back and you just render it. Now one thing to note here is we have concurrent mode enabled in Blitz by default and so you're using suspense which is really awesome. So you can see in this component we don't have this entire if else dance of if loading show the loading if error show the error, if something else show something whatever. It's just very simple so it's really cool and then in the page component toward the bottom half of the screen you can see we have the suspense component and the fallback for the error and so it's a really nice API. Usequery is built on top of reactquery and reactquery provides a ton of awesome stuff that you get by default in here caching all your server data, caching and validation, polling, all these sorts of things, really powerful features and you just get it by default.
Okay, so how do you get started with Blitz? Well it's pretty hard there's only two commands and first thing is install Blitz globally as a CLI and then secondly is run Blitz new and pass it the name of your app and that's it. And it'll just generate your app for you, install your dependencies and so forth, and then like I mentioned you can immediately sign up and log in as a user and it's awesome.
Alright, let's talk about community over code, so this is one of our foundational principles. People are far more important than anything else and these are principles that we hold dearly in the Blitz community, but it's also principles that we as a tech community at large really embrace and live by. Secondly, we treat every person with dignity and worth regardless of who they are, what their beliefs, they, every person is worthy of dignity and worth. We're all in this together, we all want to be productive, we all want to have fun in our jobs and we're all more similar than we are different, so we can and should solve problems together. We have an entire page in our documentation linked here that details how the Blitz community operates, we'll go through pretty much everything and so you can get a good idea like if you want to be involved in the Blitz community or not, you know, want to see how things operate, that's a good place to do so.
OK, now let's talk about how you can contribute to Blitz. So we need your help, we love all the help we can get, we have a bunch of features in our GitHub that are ready to work on but they're just sitting there waiting for somebody to work on them. I'm working mostly full-time on Blitz and then doing consulting on the side. So far, I'm doing the, I'm contributing by far the most, but we'd love anyone else to help in their free time as much as they can. We appreciate any type of contribution, whether it's code, documentation, improving documentation, tutorials, videos, blog posts, anything you can think of. Secondly, donations and sponsorships, it's my goal to work full-time on Blitz without having to do consulting on the side and then beyond that, I would love to pay other people to work on Blitz too, full-time. I would love any type of donation or sponsorship that you can give us through GitHub. There's a button on our GitHub repo.
Blitz Documentation and Community
The best place to get started with Blitz is the blitzjs.com documentation. Follow Flybear and Blitzjs on Twitter for more updates. Feel free to reach out with any questions or to share your experience with Blitz. The current plan is to switch to beta status in the next week or two, with the goal of reaching version 1.0 by the end of the year or early next year. The Blitz community is made up of core team members, maintainers, and a large number of contributors. Maintaining Blitz involves spending around 30 hours per week on average, with consulting work on the side. A typical day includes answering questions on Blitz Slack and working on Blitz development.
And then, secondly, the best place to get started here is this blitzjs.com documentation, which is linked here. So this concludes the end of my presentation. Blitzjs.com is the best place to go to get started there, you can follow me at Flybear on Twitter and Blitzjs on Twitter as well. And so I would love to answer your questions now and anytime later on Twitter anything just reach out happy to help answer questions and I would love for you to try out Blitz and let me know how it goes. Thank you so much.
Amazing, welcome. Thank you so much for your talk. I'm going to jump right in with some questions. First of all, congrats on Blitz, it looks like it's going great. When is it going to be 1.0? So we are currently discussing right now. We're currently in alpha status, but we're discussing switching to beta status probably within a week or two. So we're getting close. So now that we're basically almost in beta status or focused on smoothing out rough edges fixing bugs, adding more tests and all of those sort of things to get to 1.0. So there's not anymore major changes planned. So hopefully around the end of the year, early next year, we'll be 1.0 we'll kind of see how it shakes out. It's hard to schedule open source, but we'll see.
You talked a little bit about this, about the community, but could you tell us a little more about who's involved and how you're managing it? Sure. So there's two other core team members besides myself Rudy and Dylan. And then I think we have about three level two maintainers now, and a level two maintainers have ownership over a certain part of the code base and kind of help manage reviewing PRs and merging them. Then there's about eight or so level one maintainers that just help us community, answering questions and so forth. And then there's a whole host of other contributors. I think we're over 120 now total people that have contributed to Blitz in some way with code, documentation, etc. So it's a great community. We all have a lot of fun and so anyone is welcome to come and help contribute.
That's really awesome. You're maintaining this full time, I think you mentioned. What is life as a maintainer like in open source? Sure. So right now, I'm spending about 30 hours per week on average on Blitz and then another 20 or 25 per week doing consulting on the side to support myself. So how a typical day looks like. I wake up, I look at Blitz Slack and answer questions, check on a few things and then I do consulting work to get me through the first part of the day and then when I get bored of that, I switch over and do Blitz stuff for the rest of the evening.
Blitz Resources, API Compatibility, and Future
That's awesome. Some of the audience wants to know whether you or your community have any good resources for someone who maybe hasn't contributed to open-source before and wants to get started? We have a How to Contribute page on our documentation and we try to spell it out very clearly, like first things first we have a link out to Kent C. Dodd's egghead video on how to get started with open-source. So that's the best place to get started and then we kind of walk you through how to clone the blitz repo and then what type of things you can work on. We have a bunch of issues that are tagged ready to work on and then we also tag them good first issue and good second issue and so those are good places to see like, ok this is something that I can do and a lot of times the good first issues are really easy like just changing one word or something very simple a lot of times it will get fixed within an hour of whenever we post them so just watch the repo and keep your eyes out for those.
I don't know if you get this question a lot but it's a classic. Is there anything Blitz is not suitable for and when would you not use it? So kind of our motto or goal is to be the framework for the 99% of us that work at companies less than 100 employees. So Blitz is probably not going to be, you're not going to build the next like you couldn't take out the core Facebook and swap in Blitz. It's just far too complex for something that massive but you can totally start the next Facebook with Blitz and it will definitely grow with you and you'll end up needing to spin up other services around that. But it's really great for prototyping right now and then we'll also have a lot of people that are building production SaaS applications. So any type of application where you need to have some login, a database and you're connecting to that is really great for that. And especially for like for makers, for indie hackers new startups, it's really great.
Do you maybe not officially, but in your head have the good future of Blitz? Like what would like a 2.0 look like or a 5? Good question.
Blitz Future and Updates
Blitz is great for prototyping and building production SaaS applications. The vision is to bring the Zero API experience to mobile, allowing for a seamless multi-client app. Next.js focuses on lower level universal solutions, while Blitz is more opinionated with a database layer. Updates in Blitz are handled by upgrading the Blitz dependency.
But it's really great for prototyping right now and then we'll also have a lot of people that are building production SaaS applications. So any type of application where you need to have some login, a database and you're connecting to that is really great for that. And especially for like for makers, for indie hackers new startups, it's really great.
The big thing that really the main thing that I have a vision for that we're not even really close to yet is to have the same Zero API experience like we have right now with Web and bring that to mobile to React Native, for example. Today you can use Blitz with mobile apps. You can connect to the generated API endpoints and use that normally. We have a few people that are working on doing that. You don't have that Zero API experience. You're still doing the calls or whatever you need to do from mobile.
The first thing we can do to that is generate an API client and that's relatively simple. We can do that for multiple different languages so it makes it easy to have a typed client and easily talk to the Blitz backend. Then even beyond that, I want to have a supported where you have a monorepo where you have your normal Blitz web app there and then also React Native app in the same repo and then you can import your Blitz queries and mutations directly into your React Native code and then we would swap that out at compile time to be the same type of API client like we do with the web. So we want to bring that to mobile. So I'm pretty sure that is possible, we can do that somehow, but that's definitely a bit out on the road map but that would be really awesome so you have this entire multi-client app, web app, mobile app, without dealing with REST or GraphQL or any of it. Blitz everywhere. I mean, that's the spirit, right?
Metin from the chat wants to know, have you ever had a moment where you considered just adding some of these features to Next.js since that's also open source? So Next.js team is pretty clear about that they are solving the problems, the scope that they're at now, they want to stay at, where it's relatively minimal and they're solving problems that pretty much are universal kind of lower level things working on RFC for internationalization, RFC for an image optimization component. So these are kind of lower level fundamental things but where Blitz is a bit more opinionated. So we have the database layer, the full stack data layer things. So they don't want to go with that for opinions. So I think it works out good because there's a lot of people that want that lower level and they want to bring all their own opinions and craft their perfect stack in the end. But then there's also other people that Blitz is good for that they don't want to spend a week or two picking libraries and setting things up and hooking things together. They just want to get something built. Fair enough.
Dennis wants to know, I'm a bit curious about how updates of Blitz itself might be handled in the project using Blitz. Like if at some point some underlying library is going to be changed. Right now, Blitz, there's one dependency you upgrade Blitz and then you're good to go. You can do some editing changes right now, which there are occasionally. You just watch release notes and make that change.
Blitz Editing Changes, Release Cycle, and Recipes
You can make editing changes now and watch the release notes for updates. After reaching 1.0, a stable and predictable release cycle inspired by Ember will be implemented. Blitz Recipes allow for easy installation of third-party code, and there are plans to enable automatic upgrades with 'blitz install blitz'. Thank you, Brandon, for joining us.
You can do some editing changes right now, which there are occasionally. You just watch release notes and make that change. Then after we get to 1.0, we're going to implement a really stable, predictable release cycle inspired by Ember. How Ember does it, every six weeks there's a new stable release. Then there's also an LTS release that a new one's released every six months. The next release is in beta for six weeks. That's stable and unlikely to get bugs in the final version. And breaking changes are handled nicely with deprecations. We're going to plan on doing that.
We also have a thing called Blitz Recipes, which I don't think I talked about in my talk. That's a one command to install any type of third-party code. You can do blitz install TEOWIN, blitz install Chakra, blitz install Emotion. We have a few of those, we're still building those out. That's another really awesome thing. Where I was going with that is eventually we could have blitz install blitz. And it would upgrade blitz automatically for you. That's really cool.
We are out of time, Brandon, but thank you so much for stopping by. You can all go find Brandon in the Discourse or later in the rooms.