A Glimpse Into the Future of Fullstack Development with Blitz.js

Today, I'm going to talk about the future of full-stack web development with Bleeds.js. I will introduce you to what Bleeds currently is, and I will give you a glimpse into what is going to be in the future. My name is Aleksandra and I'm currently maintaining Bleeds, and previously I led a Hasura console team. You can find me on GitHub and Twitter, and you can also check out my personal website.

The agenda for today is to talk about the past, the current state, and the future of Bleeds. We'll go through the core concepts and features, and then I will explain what are our plans and what we are currently working on. Some of you might have already heard about Bleeds, or maybe you even used it in your projects. For those who didn't, Bleeds is a full-stack React framework. It was hugely inspired by Ruby on Rails, and built with a motivation to empower developers and give them the best possible experience for building full-stack and React applications. Bleeds is built on top of Next.js. Next is a framework mostly focused on the frontend, where Bleeds adds all the missing features and functionalities that turn it into a full-stack framework. It includes direct database access, middlewares, authentication with authorization. For the setDatabaseAccess, Bleeds is using Prisma, by default. It's a batteries-included framework, which means that all the boring things like Slint, Pretier, Husky, TypeScript, Jest, are already there configured for you. You can go straight to writing the business logic and shipping your products.

One of the core concepts is that Bleeds is monolithic. It means that you can reason about your application as a single entity. There's only one thing to develop, deploy, and think about. Now, let's talk about some of the core features. The most significant one is the zero API layer. If you're using React, it requires you to have REST or GraphQL API to connect to database or perform some business logic which is meant to be performed on the server. You need an API, even if it's not going to be used by third parties apart from your own application. Build times is also a source of complexity and sometimes it could be avoided. BLEEDS allows you to run server code directly from your frontend. How does it happen? So BLEEDS abstracts the API into a BUILD step. You can use the SERVER function in your frontend and BLEEDS will swap the import with an HTTP call at build time. The server functions are called BLEEDS resolvers and we have queries and mutations. However, they are just plain JavaScript functions, which will always only run on the server. Also, you can still add your own API if needed, and BLEEDS won't get in your way. Let's take a look at the architecture diagram.

At the top, we have client code and there's server code at the bottom. In particular, we have one query and one mutation at the bottom. In your application, you can have a server-side rendered and a client-side rendered page next to each other. With BLEEDS, they can use the same server code. In build time, the middle layer is generated and inserted for you.

The middle layer is this auto-generated JSON API on the diagram. Each query and mutation is exposed at a unique URL, which means that you can also call those URLs directly, for example, from a mobile application. Here we have a sample BLEEDS query, it's called GetProject. And let's take a look what happens here. So we use that to define the shape of the query parameters. Then we parse the input to make sure that it's what we want. Later, there is a call to the database, we use Prisma here. And with this call, we are trying to find the project with a given ID. At the end, the query returns the project that we were looking for in the database.

In a component, we pass it to a useQuery function imported from Blitz. It's built on top of React Query, which is a great library, providing caching, polling, great developer experience, and many, many more features. Now let's take a look at the mutation example. It's not much different from the previous function. We also define the shape of the input, we parse it, we connect to the database to create a new object, and at the end, we return the newly created project. In a React component, we pass this function to a useMutation and then we use it upon a form submit.

Another great thing about Blitz is that it has authentication and authorization out of the box. After creating a new application, you can sign up and log in instantly. All the code needed for creating new accounts for login logout is already there generated for you. There's also a Passport.js adapter, which allows you to add a third-party login.

Here we can take a look at the sign-up mutation provided for you in Blitz projects. This code is already there after you created a new Blitz application. So what do we have here? We hash the password with a secure password utility imported from Blitz. Then we create a new user in the database, we pass the mutation values and we pass the hashed password. As the next step, we create a new authenticated session. The CTX object is the second argument of Blitz resolvers and is provided by the session middleware and the session middleware is configured for you by default in your applications. In our queries and mutations, we also need to be able to restrict the access to the server code. For that, we can use, for example, this is one of the methods, we can use authorize function. So if user is not authenticated or if it's not authorized to access a resource, it will throw an error.

Blitz also comes with code scaffolding. You can use Blitz command line to generate models, resolvers and pages. For example, Blitz generate all project command, we create pages to list, add and edit new It will also create a new form component to create new projects. And finally, it will generate all the necessary queries and mutations. Then we have recipes, which were mostly inspired by Gatsby, and they provide us with an easy way to extend our applications. We have a bunch of recipes in Blitz, and they allow to, for example, add UI libraries, deployment logging tools, and a few more things.

So, another cool thing that Blitz introduced is type safe routes. Let's say you have a page called Products page. In a different page, you can import the routes object from Blitz, and then you can refer to the Products page by name instead of providing a string with an URL. So, if you want to get started with Blitz, you can install it globally, and then run Blitz new command. You will need to pass a name for your project, and then it will ask you a few questions. For example, whether you prefer JavaScript or TypeScript, what form library you want to use and what is your preferred package manager. Till now, I was mostly talking about the Blitz framework as it is now. But now, let me tell you about the future of Blitz Toolkit. At the end of the previous year, Brandon, the creator of Blitz, has announced the Blitz pivot. The plan is to move to a framework-agnostic toolkit that preserves all the developer experience that Blitz has and all the features that developers love about Blitz. But we want to bring it to not only Next.js users, but also Remix, Speltkit, Nuxt and so on.

This was a huge, huge decision, and it was a huge change for the Blitz community. As we were reading the feedback and we were going through what people were saying about the pivot, it only made us more sure that this is the right decision. The feedback was very, very positive. And most people said that this is the best direction for Blitz.

So Blitz is a community project and we value community over code, so you wouldn't be able to make this decision if it wasn't for this feedback, and if it wasn't for people telling us that this is the best choice. So you might be wondering why you even started thinking about it. So over 100,000 projects were created with Blitz, and we recently, a few months ago, passed the 10,000 GitHub stars milestone. Blitz got tons of positive feedback and people were saying that it made them super, super productive. However, as I mentioned before, this is based on top of Next.

What's more? So a few months ago, we forked the Next.js repository, which on the one hand, was a good decision because it allowed us to remove some custom compiler step. And it allowed us to hook directly into the Next code. On the other hand, it slowed us down as the migration to the fork was taking time. And we were catching up to Next.js. They have a great team and they make a tons of amazing things. So it's kind of difficult to stay up to date. The growth of Bleed has kind of stagnated and we are very much looking forward to improve that.

So let's talk about the pivot's objectives. We aim to preserve the developer experience as much as possible. We don't want to make any APA changes that we don't have to. And we don't want to change the existing features. Our main goal is to bring more people to Bleed or bring Bleed to more people. We want to enable developers to use some parts of Bleed, even if they don't want other parts or even if they don't use Next.js. Having said that, we want to decouple Bleed from any specific framework or runtime. We'd like to work with Deno, Cloud for Workers, and not just Node.js. Lastly, we want to ship more and more amazing features without focusing on maintaining Next.js. Let's compare it a little bit and explain how exactly the new Bleed will be different from the old one. You can think of the current Bleed as a bug with features like zero API, recipes, authentication, code gen, and it all stands on Next.js. While with the new toolkit, you can take those parts that you are interested at. You want a zero API but you don't want authentication? That's fine. Or maybe you don't want zero API but you like authentication that Bleed provides? That's also fine and possible.

And on top of that, the foundation can be a framework of your choice. So let's go over the toolkit features that we plan to have. So we believe that the core value that this currently has is the zero API data layer, the authentication with authorization, all the conventions that we have, the new app and code scaffolding. So the new toolkit is meant to have all those features as well, and we plan to add a few additional things like JWT authentication, and for example, more advanced data aware authorization. But that's not all, there's a plenty of other features that the new toolkit could support, such as websockets, background processing, email integration, and many many many more.

In fact, if you have any ideas, you can let us know after the talk. You probably wonder, what about all the current BLEEZ projects? As I mentioned, there are plenty of them. So the existing BLEEZ applications will continue to run and will fix any critical bugs that came up. We'll be doing releases when needed, and we'll have BLEEZ in some kind of maintenance mode for as long as we need. We are also working to make the new setup as close as possible to the current setup. For any changes required, we'll have a code mode that will automate some of those changes, if not all. So the effort on the user's part should be as minimal as possible. For the existing projects, we want to make the migration as seamless as possible, with the set code modes and the automation.

So, let's talk about the BLEEZ toolkit setup now. I will show you a bunch of code snippets. And you can think of them as some kind of work in progress to the code. They are not final. This is something that we were talking about, thinking about, something that we are evolving around. But it's more or less what we want to have in the end. So we are going to have a setupServer function, which returns a bunch of things. For example, a setupClient, a utility to initialize the client part of Bleeds. It also returns gcp, gcpAPI functions, which will be wrappers for the GetServerSideProps, GetStaticProps, and Next.js API handlers. It also returns a type, BleedsServer, which you can use to type. For example, you can use it to provide to the setupClient function. Also, the setupServer accepts a list of plugins. The first one in this example is AuthPlugin. It takes a configuration to set a cookie prefix and a storage float to handle the session database management. You could also pass a zeroAPIPlugin with its own configuration and possibly some other plugins like, for example, FileUploadPlugin. So on the client, we'll have the setupClient function, as I mentioned before. And here, we'll also pass all the plugins that we want to have on the client site.

It will return a bunch of client utilities like useQuery, useMutation, useSession, with Blitz higher order components to wrap your whole application, QueryClient to configure the react query, and so on. Here is a client plugin interface. So this is also more of a pseudocode, but it will have events, something that should happen on SessionCreate and SessionDestroy, so that other plugins could plug into the auth plugin. It will have middleware, so things that should happen before http request and after http request, exports, all the functions that will be exported from the plugin, like useQuery and useMutation will be exported from zeroAPIPlugin, or useSession will be exported from the auth plugin. It can also have withProvider, a higher-order component which will be used to wrap the application.

Now, let's look more closely into the zeroAPI layer and how it could work with the Blitz Toolkit. We have a bunch of goals for it. Firstly, we want it to be a standalone library which is runtime and framework agnostic. We will use HTTP GET for queries, because currently both queries and mutations use HTTP POST. We will want to support multiple resolvers in a single file. And what's most important, we want to preserve the current API as much as possible. Ideally, nothing should change in the way that you write resolvers.

So here's a sample resolver, which looks exactly the same as in the current Blitz framework. We will import it into a Blitz setup file and pass to the setup server function, specifically the zero-API configuration. And then in useQuery, we'll pass a string with the name of the resolver. However, that's only one proposition. We strongly consider keeping the magical imports so that you don't have to import the resolvers to the setup file and you'll be able to import them directly to the useQuery or useMutation functions. We think that we can do this with a custom Webpack plugin and that's something that we are currently looking into.

So what we are currently working on? The plugin system, as is the most crucial part, we want to do it good so that it doesn't block us in the future, and it won't stop us from adding additional framework support. We also want it to be easily expandable, so that people can write their own plugins. At the same time, we're extracting some code from Blitz for better understanding of how it all should work together. We also set up a new monorepo on the main branch in the Blitz repository.

Okay, takeaways from this talk. You can visit the blitzjs.com website to learn about Blitz, or you can also check out the repository in blitz-js.org and it's called blitz. We would love your feedback, so if you have any thoughts about the pivot or any of Blitz features, let us know. You can join the discussion in the Blitz repository, or you can reach out to me or Brandon via Twitter or email. Thank you a lot for joining. And if you want to reach out, don't hesitate, we can continue talking about Blitz. You can find me on Twitter as AlexandraSes. Thanks a lot.

Hey Alexandra. Hi. Hi. Hello everyone. So, Alexandra asked, have you used Blitz before? And 50% said no, yes, 32% and 18%, only 18% said haven't heard of it. So I have to say, this is a pretty good number, right? 32%... Yeah, this is a pretty good number, you know. So as 50% didn't use Blitz, that might talk might have been a good introduction to Blitz. So that's nice. So people weren't bored. But for those who did use Blitz, I hope that they liked the Pivot thing and that they will be using the new Blitz toolkit. And yeah, 80% haven't heard. I think that's a nice number, you know. Only 18%. That's good. That's good for Blitz. If we ask this question to the same audience again tomorrow, then it will be 50-50, of course. Yeah.

All right. We're gonna jump into some of the audience's questions. First question is from Populinga. Is the Blitz project still in beta? Yes. Yes. It's still in beta because Blitz was started initially like two years ago and Brandon, the creator of Blitz, was working on it with the community for a while. Then they released Alpha and a few months after Alpha, they released Beta. And the thing is that we then, like sometime after the Beta release, I joined and we were instead of using Next.js as a dependency, we forked Next.js. And, you know, we removed our custom compiler. We were moving the Blitz core code into Next.js. We wanted to have it all done before the stable release. And we also had some other features in mind to be completed before the official 1.0 release.

However, in the meantime, we decided to pivot for the reasons I mentioned in the talk. We wanted to bring Blitz to more people that use other frameworks, not only Next.js. So that's why the framework is in beta.

And is there an ETA on 1.0? We won't be working on the framework itself, like, we won't be, you know, focusing on that. We just shifted our focus 100% to the toolkit. Maybe not 100%, because we are still fixing bugs. We are still making releases of the framework, because you know, so many people are using it and we want to maintain it. If someone submits a PR, we also spend some time on reviewing it. But, yeah, like, regarding bigger things like the 1.0 release, we plan to have the toolkit as 1.0, as, you know, the new official stable Blitz. Yeah, that's what I mean. Sorry. Yeah, the ETA. So, we are targeting the end of March. Right now we have some things working. You can check out the main branch in Blitz repository. We have some work in progress. And yeah, we plan to finish it over the next few weeks. That's pretty exciting. Yeah, that's exciting. Five, six more weeks, end of March. Yeah, I better hurry and go back. Yeah, I will go, bye bye.

Next question is quite a good one. For people who want to start a new project tomorrow. Would you recommend choosing Blitz? Or should people kind of stay away until the Biffin is completed? So I would still recommend using Blitz because it's a framework used by many developers. And although it's not 1.0, it is kind of stable. And it gives you a lot of power as a full stack developer. And even though we are working on the toolkit, we want to make this transition really smooth. There will be code modes. We'll be working on them as well.

So when you actually have a Blitz project and we have the toolkit ready, there should be a command that converts the Blitz project to a Next.js with Blitz toolkit. And maybe there will be some configuration on your site, some manual steps. But we want to have them as limited as possible. We want to automatically cover almost everything for you with code mode and so on. Yeah, that's nice because else it's too dangerous or scary to choose Blitz now. So it's very good that you're putting in the work for this code mode. Thanks.

And what are some new features you will be adding to the Blitz framework? Or will you be adding any? Yeah, so we won't be adding new features to the Blitz framework because we want to focus as much as possible on the toolkit. However, we're still like for small things, we'll still accept PRs. So if there is like a small thing that would make the current Blitz better and it won't require like many hours, like hour-hours on review. And it's like just PR and we can ship it, then we still are adding those kind of things. We are not working actively on the framework's features. But possibly, the new toolkit will come with like new features out of the box, like in Blitz framework, we didn't have JWT authorization, authentication. But maybe we'll have it like from the first day in the toolkit. So you can expect those kind of things in the toolkit. Maybe, but this maybe is in five weeks, so I think we got a glimpse of the future here. Yeah, we did. Nice.

Next question from Hail of the Wood. Of all the things in the roadmap for Blitz toolkit, what are you most excited about working on? What I'm most excited about working on? So that's a nice question. So the most tricky part about the whole toolkit and something that we had to initially spend a lot of time figuring out is the whole plug-in system design, like how to make this new Blitz toolkit so that there are plug-ins and people can use, only like, you know, some of those plug-ins, like someone wants authentication from Blitz, but they don't want anything else or something else and how to make it good so that people can write their own plug-ins and so on. So that was like a challenge. And another challenge on top of that was how to make those plug-ins framework agnostic. So that was kind of exciting, like figuring this out. So like I initially spent some time like just setting up a Next.js, like simple Next.js application and like working on like a skeleton of how this plug-in system could work. And that was quite exciting because I could then see, oh, so I need this kind of thing because this authentication works this way and possibly I need plug-in to work this way because the Zero API works this way. And so that was challenging and exciting. Yeah, nice. Yeah, it's a good way of building what you need just being your own customer basically and you see it coming to life what you need. Yeah, nice.

Yeah, sometimes you have to experiment. Exactly, we have time for one quick question and answer. This from JSfire, Watch69. As a framework for a full stack developer, Blitz, yes, reminds me of Meteor. Yes. Were they inspiring for you? So, I'm not sure if that was an inspiration for Brandon initially. I know that like a huge inspiration was Ruby on Rails. And I think that, you know, like the idea was to like have something like Ruby on Rails in JavaScript world. So I think regarding this particular inspiration that would be the question to Brandon. I can ask him, you know, quickly after this stretch. And that, you know. If you can enter the Discord to JS Firewatch, then that would be awesome. Yep.