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, 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.

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.

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.

And how you do that on 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 and Rails, or Laravel, the controller concept, it's 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.

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.

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.

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.

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.

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.

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.

That's awesome, I bet there are some other maintainers pretty jealous right now. So how did you get into blitz, did you have a bad time with an api and you were like I never want to do this again? So I touched on that a bit in the talk but I started web development using Ruby on Rails 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 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. 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. 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. So I think we've done pretty well at that. Last week one of the Blitz developers had been using Blitz for a couple months now and 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 mind blowing.

Alright 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 JavaScripts? 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, 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 integrated versus your own authentication somehow. So it's totally up to you, totally flexible.

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.

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.

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.