Blitz.js - The Fullstack React Framework

♪ 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, Mombax State Tree, and a host of other api services and libraries, managing multiple servers, multiple deployments, et cetera. 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 and 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 when I was working 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. You know, because 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. And 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. It would just work. And so I was like, wow, that's pretty awesome. Like, 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. You know, I mentioned that I was just frustrated with full stack web development with react. But throughout that entire time, there was one thing that constantly shone through the mess, and that was next.js. You know, 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 front end, so everything is fully typed end-to-end. All right, 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. All right, 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 serverless, all your server endpoints can be independently scalable as serverless functions. And 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. And number seven, community over code. OK, 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 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. And how you do that in a Blitz app is what we call queries and mutations. Now, this has nothing to do with graphql. We just use the same nomenclature. And they're just plain asynchronous javascript functions that always run on the server. If you're familiar with Ruby on Rails or Laravel, the controller concept, what is basically replaced by queries and mutations. Now, of course, you can always add an api to a Blitz app because there's zero restrictions that we give you. So we're 100% compatible with next.js. And in fact, we have less restrictions than next.js does. So you don't have to worry about Blitz getting in your way. All right, 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. OK, 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. And 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. So we include ESLint, Prettier, Jest, Husky, GitHooks, and a number of other things just already set up for you. Now the big thing that's really, 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. OK, let's get into some code. All right, 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 asynchronous function. And the first argument to that is the arguments to the mutation. And the second is a context parameter. And this context parameter is provided by middleware in 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 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. This db object is provided by prisma 2. And so you can see how nice it is just to create a user. So email, the 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 front end. 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 fifth 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 on submit hook. And so you just call it just a wait, just like a regular function there. And it just all works for you. It's super slick. All right, let's look at another one. This is a Git project query. And so you can see, again, we get some inputs, and then the context parameter. And the first thing we do in this case is called session.authorize. And this is going to ensure that the user is logged in. If it's not, it'll throw an error. And that error will propagate all the way to the front end. And it'll show either a login form if they're not logged in, or it'll 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 pitch. All right, so let's use this thing. And we'll 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 use query hook that you pass that query function we were just looking at. You pass it to use query. 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 apps 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. Use query is built on top of react query. And a react query provides a ton of awesome stuff that you get by default in here, like caching all your server data, caching validation, polling, all these sorts of things, really powerful features. And you just get it by default. OK, 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. All right, 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 should 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, or you just 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 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 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. So we'd love any type of donation or sponsorship that you can give us through GitHub. There's a button on our GitHub repo. And then secondly, the best place to get started here is this, the 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 any time later on Twitter, anything, just reach out. Happy to help answer questions. And I'd love for you to try out Blitz and then 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, we're 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 any more major changes planned. So hopefully around the end of the year, early next year, we'll be able to get to 1.0. We'll kind of see how it shakes out. It's hard to schedule open source, but we'll see. Yeah, that's right. 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 beside myself, Rudy and Dylan. And then I think we have about three level two maintainers now. And level two maintainers have ownership over a certain part of the code base and kind of help manage reviewing PRs and merging them. And 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 of people that have contributed to Blitz in some way with code, documentation, et cetera. And 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 kind of the first part of the day. And then when I get bored with that, I switch over and do Blitz stuff for the rest of the evening. 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 kind of very clearly, like here's 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 walk you through how to clone the repo, 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, okay, this is something that I could do. And a lot of times the good first issues are really easy, like just changing one word or something very simple. And a lot of times they'll get fixed within an hour of whenever we post them. So watch the repo and keep your eyes out for those. That's awesome. I bet there are some other maintainers pretty jealous right now. So how did you get into Blitz? Did you have, like, a bad time with an api and you were like, I never want to do this again? Sure. So I touched on that a bit in the talk, but, like, I started web development using Ruby on Rails, you know, back in 2014, I think, is when I started learning web programming because I was doing C and C++ before that. And so I learned Ruby on Rails, and, like, it was pretty easy to do full stack stuff. And then I moved on to react, and I loved that. But then we had that whole api layer that makes it a lot more complex than Ruby on Rails. And then finally I decided enough was enough. And we needed to have that same type of easy, simple, full stack experience that you get with Ruby on Rails or Laravel or Django and bring that to react. So did you miss it, Ruby on Rails? Yes and no. So there's a lot of things I liked about Ruby on Rails, especially how there's no api in there. But there's a lot of things I didn't like. It's kind of, I don't, like, I like javascript and typescript way better than Ruby. And so my goal is to take everything good about Rails, in my opinion, and then leave out everything that was bad. And so I think we've done pretty well at that. So just, I think it was last week, somebody, one of the Blitz developers has been using Blitz app for a couple months now, I think. And he said that already, or sorry, he said that he had been developing Ruby on Rails apps for 10 years professionally. And now after just a few months with Blitz, he's already 10 times more productive with Blitz than he ever was with Ruby on Rails. So that's kind of like mind blowing. That's awesome. Yeah. Cool. All right. So we have from Oakley in the chat, Is blitz.js suitable if you have a shared api that is consumed by multiple platforms, i.e. iOS, Android, native and javascript? Yeah, so I'm assuming you have like an existing api that you want to connect to and you can absolutely do that with Blitz. You can do it like you normally would with next.js, for example, like just connecting to the api from the client. Or the other way to do that is to use Blitz queries and mutations and talk to the api from the server and then use the Blitz api data layer to manage that. And by doing that, you can use the Blitz session management, which is very easy and all integrated versus like doing your own authentication somehow. So it's totally up to you. Totally flexible. That's nice. Flexibility is important. 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? Sure. So the kind of our motto or goal is to be the framework for the 99 percent of us that work at companies less than 100 employees. And so like Blitz is probably not going to be like you're not going to build the next like you couldn't you couldn't take out the core of Facebook and like swap in Blitz. Like it's just far too complex for something that massive. But you could totally start the next Facebook with Blitz and it'll definitely grow with you and like 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, you know, log in database, you're connecting to that is really great for that. And especially for like any for makers or any hackers, new startups is really great. Awesome. Do you like maybe not officially, but in your head have like like the good future of Blitz? Like what would like a 2.0 look like or a 5 or? Good question. The big thing that the really the only 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 the web and bring that to mobile to like react Native, for example. So today you can use Blitz with mobile apps. You can connect main, you can connect to the api, the generated api endpoints and use that. Normally, we have a few people that are working on doing that. But it's not a, you don't have that zero api experience. You're still doing the fetch calls or whatever you need to do from mobile. So the first thing we can do to that is generate an api client. That's relatively simple. We can do that for multiple different languages. So it makes it easy to have like a typed client and easily talk to the Blitz backend. And then even beyond that, I want to have a have a supported where you have like a mono repo where you have your, 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, 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. And so we want to bring that to mobile. So pretty sure that it's possible we can do it somehow. But that's definitely a bit, a bit out on the roadmap. But that would be like really awesome. So you have this, this entire like, you know, 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 is, the next.js team is pretty clear about like that they are solving the problems like where they're, the scope that they're at now, they want to stay at where it's relatively minimal. And they're, they're solving problems that pretty much like a universal kind of lower level things working on like, like an RFC for internationalization, RFC for like an image optimization component. So these are kind of lower level fundamental things, but like where Blitz at is a bit more opinionated. So we add more, we have the database layer, the, you know, the full stack data layer things. And so they're, they don't want to go with that, that far of 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, their perfect, you know, stack in the end. But then there's also other people that Blitz is good for that, you know, they don't want to spend like a week or two picking libraries and setting things up and hooking things together. They just want to get something built. Yeah, fair enough. Dennis wants to know, 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 it's, you just, Blitz, there's one dependency, you upgrade Blitz, and then you're good to go. And if there's any breaking changes right now, which there are occasionally, you just watch release notes and make that change. And then after we get to 1.0, we're going to implement a really stable predictable release cycle inspired by Ember. So something approximate, like how Ember does it is every six weeks there's a new stable release. And then there's also an LTS release that a new one's released every six months. And so the next release is in beta for six weeks. And so it's very predictable and unlikely to get bugs in like the final version. And breaking changes are handled really nicely with deprecations. So we're going to plan on doing that. And then we also have a thing called Blitz recipes, which I don't think I talked about in my talk. And that's a one command to install any type of third party code. So for example, you can do Blitz install tailwind, Blitz install chakra, Blitz install emotion. And we have a few of those, we're still building those out. And anyone's welcome to contribute your recipe for your favorite project. That's awesome. That's another really awesome thing. So where I was going with that is eventually we could have like Blitz install Blitz or something and it would like upgrade Blitz automatically for you. That's really cool. Well, 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. Thanks. Thank you.