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 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 front end 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 loging 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 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. REST 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 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 a mobile application. Here we have a sample base query. It's called get project and let's take a look what happens here. So we use Zot to define the shape of the query parameters. Then we parse the input to make sure that it's what we want. Later, there's 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 use query 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 use mutation, 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 signup 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 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. 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 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 Bleeds. So Bleeds 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 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 like to work with
deno,
cloud Fireworkers, 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 like
authentication that Bleeds 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 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 will 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 users' 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, gcpApi functions, which will be wrappers for the getServerSideProps, getStaticProps, and next.jsApiHandlers. 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. So 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 0APIPlugin 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. Your query client 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 useQuery and useMutation will be exported from 0APIPlugin, 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 0API 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 will use HTTP GET for queries, because currently both queries and mutations use HTTP POST. We'll 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 setupServer function, specifically to the 0API 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 it's 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 AlexandraSes. Thanks a lot. Hey, Alexandra. Hi. Hi. Hello, everyone. So, Alexandra asked, have you used Bleeds before? And 50% said no. Yes, it's 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 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 are also, you know, 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. Yeah. All right. 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, we, instead of using
next.js as a dependency, we forked
next.js. And 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 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 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 100% to the toolkit. Maybe not 100%, because we are still fixing bugs. We are still making releases of the framework. Because still 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, regarding bigger things, like the 1.0 release, we plan to have the toolkit as 1.0, as 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. So... Yeah, yeah. I better hurry. And you know, go back to work. Yeah, well, go, bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye. Bye bye.
