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

Hi, 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 it's 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 will 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 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 the 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 set database access, Bleeds is using Prisma by default. It's a batteries-included framework, which means that all the boring things like Slint, Prettier, Husky, TypeScript, Jest are already there configured for you. You can go straight to writing the business lodging 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 the database or perform some business lodging, 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. Sometimes it's 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 a 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 into 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 another application.

Here we have a sample based query, it's called getProject, and let's take a look at what happens here. So we use Zote 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 Bleeds. 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 the form Submit. Another great thing about Bleeds 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 Bleeds projects. This code is already there after you create a new Bleeds application. So what do we have here? We hash the password with a secure password utility imported from Bleeds. 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 Bleeds resolvers and it's 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. Bleeds also comes with code scaffolding. You can use Bleeds command line to generate models, resolvers, and pages. For example, Bleeds generate all project command will create pages to list, add, and edit new projects. 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 Bleeds, and they allow to, for example, add UI libraries, deployment setup, logging tools, and a few more things. So another cool thing that Bleeds 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 Bleeds, 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 Bleeds, you can install it globally and then run Bleeds 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 Bleeds framework as it is now, but now let me tell you about the future of Bleeds toolkit. At the end of the previous year, Brandon, the creator of Bleeds has announced the Bleeds pivot. The plan is to move to a framework agnostic toolkit that preserves all the developer experience that Bleeds has and all the features that developers love about Bleeds, but we want to bring it to not only Next.js users, but also Remix, Spaltkit, Nuxt, and so on. This was a huge, huge decision, and it was a huge change for the Bleeds community. As we were reading the feedback and we were going through what people were saying about 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 Bleeds. So Bleeds is a community project and we value community of our code, so we 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 Bleeds and we recently, a few months ago, passed the 10,000 GitHub stars milestone. Bleeds 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, 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 tons of amazing things, so it's kind of difficult to stay up to date. The growth of Bleeds 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 API changes that we don't have to, and we don't want to change the existing features. Our goal, the main goal, is to bring more people to Bleeds or bring Bleeds to more people. We want to enable developers to use some parts of Bleeds, even if they don't want other parts or even if they don't use Next.js. Having said that, we want to decouple Bleeds from any specific framework or runtime. We'd like to work with Dino, Cloudflare workers, and not just Node.js.

Lastly, we want to ship more and more amazing features without focusing on maintaining Next.js. So let's compare it a little bit and explain how exactly the new Bleeds will be different from the old one. You can think of the current Bleeds as a bug with features like zero API, recipes, authentication, code again, 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'd like authentication that this 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 Bleeds 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 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 Bleeds projects? As I mentioned, there are plenty of them. So the existing Bleeds applications will continue to run and we'll fix any critical bugs that come up. We'll be doing releases when needed. And we'll have Bleeds 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 Bleeds 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're 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 GCCP, GCP API functions, which will be wrappers for the getServerSiteProps, getStaticProps, and Next.js API handlers. And 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 zero API plugin 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 side. It will return a bunch of client utilities like UseQuery, UseMutation, UseSession, with Bleeds higher-order components to wrap your whole application. Our 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 AuthPlugin. 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, you know, UseQuery and UseMutation will be exported from zero API plugin, or UseSession will be exported from the AuthPlugin. 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 zero API layer and how it could work with the Bleeds 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'll use HTTP GET for queries, because currently both queries and mutations use HTTP POST. We 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 Bleeds framework. We'll import it into a Bleeds setup file and pass to the setup server function, specifically to 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 import so that you don't have to import the resolvers to the setup file, and you will 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 Bleeds for a better understanding of how it all should work together. We also set up a new Monorepo on the main branch in the Bleeds repository.

Okay, takeaways from this talk. You can visit the bleedsjs.com website to learn about Bleeds, or you can also check out the repository. It's in Bleeds-js organization and it's called Bleeds. We would love your feedback, so if you have any thoughts about the pivot or any of Bleeds features, let us know. You can join the discussion in the Bleeds 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 Bleeds. You can find me on Twitter, as alexandra says. Thanks a lot. Hey, Alexandra. Hi. Hello, everyone.

So, Alexandra asked, have you used Bleeds 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. So 50% didn't use Bleeds, that might have been a good introduction to Bleeds, so that's nice. So people weren't bored. But for those who did use Bleeds, I hope that they like the pivot thing and that they will be using the new Bleeds 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 Bleeds. If we ask this question to the same audience again tomorrow, then it will be 50-50, of course.

We're going to jump into some of the audience questions. First question is from Popilinga. Is the Bleeds project still in beta? Yes, yes. It's still in beta because Bleeds was started initially like two years ago, and Brandon, the creator of Bleeds, 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. And we were moving kind of like we were moving the Bleeds core code into Next.js. And we wanted to have it like 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.

However, in the meantime, we decided to pivot for the reasons I mentioned in the talk. We wanted to bring Bleeds 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? So we won't be working on the framework itself. We won't be focusing on that. We just shifted our focus like 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 the, you know, like the new official stable Bleeds. Yeah, that's what I meant, 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 Bleeds 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 you know, go back. Yeah, I will go. Bye bye.

Next question is quite a good one for people that want to start a new project tomorrow. Would you recommend choosing Bleeds or should people kind of stay away until the Bifid is completed? So I would still recommend using Bleeds because, you know, 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, you know, even though we are working on the toolkit, we want to make this transition like really smooth. So there will be code modes, we will be working on them as well. So, you know, when you actually have a Bleeds project and we have the toolkit ready, there should be a command that converts the Bleeds project to a Next.js with Bleeds toolkit.

And maybe there will be some configuration on your site, some manual steps, but you want to have them as limited as possible. We want to, you know, automatically cover almost everything for you with code modes and so on. Yeah, that's nice because else it's too dangerous or scary to choose Bleeds now. So it's very good that you're putting in the work for these code modes. Thanks.

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

Next question from Hail of the Wood. Of all the things in the roadmap for Bleeds toolkit, what are you most excited about working on? What I am most excited about working on? So that's a nice question. So, you know, like 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 Bleeds 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 Bleeds, 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 the 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 0 API works this way and so on. So that was challenging and exciting. Yeah. 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 we have to experiment. Exactly.

Yeah, sometimes we have to experiment. Exactly.

We have time for one quick question and answer. This is from JSFirewatch69. As a framework for full stack developer, Blitz.js reminds me of Meteor.js. 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 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 chat and let you know. If you can answer the Discord to JSFirewatch, then that would be awesome.

So that's all the time we have for the live Q&A. But if you want to continue discussing Blitz.js with Alexandra, you can do so in her speaker room over on Spatial Chat, where she will be going to in a minute. So Alexandra, thanks a lot for joining us. It's been a pleasure. Yeah, thank you. Thank you for having me. Bye-bye. Bye-bye.