It can seem like every few weeks there's another new game-changer when it comes to JS frameworks, but Blitz.js boasts some powerful features that just might make it your new go-to.
We here at Codesphere have taken a look at what Blitz.js is, how it works and why it stands out from its peers, but the big takeaway for us is that it completely eliminates the need to connect an API to your application. With Blitz.js, gone are the days of REST or GraphQL API calls, and you can also say goodbye to building authentication and authorization.
If you want to check out a demo for BlitzJS, you can open this example app in Codesphere.
So let's dive right in!
What is Blitz.js
In short, Blitz.js is a Ruby on Rails-inspired full-stack framework for react apps, built on top of Next.js. It's 'full-stack because of its ability to talk to the database - Blitz's "Zero-API data layer" allows you to send and receive data to the front end so there is no need to connect an API.
It also comes with a bunch of CLI tooling built-in for code scaffolding, as well as Prisma 2 for DB migrations and access.
What is a 'Zero-API data layer'?
Blitz.js is 'Ruby on Rails inspired' and, as you may know, there is no API used with Ruby on Rails. You can access your DB directly from your view templates, you don't have to worry about multiple deployments for front end and back end, it's an all-in-one monolith.
Blitz is also built for React apps and, as you may know, React is great for building user interfaces but comes with the cost of having an API layer. This is where Blitz's Zero-API data layer comes in - it abstracts the API into a compile step, which allows you to write functions that run on the server, these are called Blitz queries and mutations but you can think of them as a control from Ruby on Rails.
The queries can be imported into your components and passed directly into, say, a hook for example. No GraphQL or REST API, no data fetching, you don't have to use REDUX and given that Blitz hooks are built with React Query, this all comes together to create a super smooth and powerful end to end data layer. Again, with no need to connect an API and make calls, awesome.
Hooked yet?
As I mentioned, Blitz uses React Query, which is great because React Query usually gives you all sorts of access to the cache. Blitz, however, also exposes utilities to the user so you can also access and modify the cache yourself.
Error handling is another beautifully handled feature in Blitz. Blitz.js basically extends the "try…catch" model of error handling but across the full-stack, meaning you can throw an error in your server code and then catch it in your client-side code with a React error boundary. So let's say you throw an error inside your query because an item is not found, well with Blitz you can have an error boundary in your app that will catch the error all the way from the server and render your 404 page. This is set up as the default for Blitz and pretty nice to have!
(image from the Error Handling Blitz.js documentation)
Sign me up! Or log me in…
One of the most important but most frustrating parts of making a new full-stack app can be authentication and authorization. Well thankfully, new Blitz apps come with authentication set up by default. Straight out of the box you can sign up as a new user and login right away with no setup needed.
We mentioned earlier that Blitz.js comes with Prisma 2 as default. Blitz is database agnostic so you could remove it and it would still work just fine, but we don't recommend doing that because Prisma allows you to do some cool things like defining your schema declaratively to migrate your DB or use the DB client. Which is all written in typescript, so if you are using it then you have fully typed DB access based on your DB scheme, which is great.
Blitz also has Prettier for formatting, Jest for testing, ESLint for lining, and Husky for githooks, all customizable in settings but shipping as standard.
Formed an opinion yet?
Blitz.js is loosely opinionated, the file structure of a standard project is flexible and allows for a lot of freedom in terms of styling and form. The Zero-API data layer is a strong opinion but that's how you get your full-stack DB access so that's a fair trade.
There are also Recipes that let you install styling libraries with one command. Flexible and freeing!
Is Blitz the right framework for your app?
Probably. Blitz seems to lend itself well to SaaS applications, but its powerful out-of-the-box toolset makes it a strong contender for any project. It's built on Next.js so naturally, it can do everything Next can but it's packed with a bunch of extra features that make it all the more versatile. The future holds web and mobile apps without any API…what a time to be a coder.
Dive in and check it out. Predictably, it's even easy to install. There are some great tutorials in the Blitz.js documentation on their website to help you get into it, you'll be a pro in a flash.
Thanks for reading!
Happy coding from your good friends at Codesphere, the next-generation cloud provider!
Top comments (33)
Just wanted to mention you can in Nextjs also access your db from your conponents.
Not like in Blitz. In Next you have to use getServerSideProps or getStaticProps (those also work in Blitz) which isn't actually "in your component".
In Blitz, you can use queries and mutations from anywhere in your tree, not just the top level page hooks mentioned above.
Here's more details on the differences: blitzjs.com/docs/why-blitz
I mean sure blitz needs to have a bit more if its a framework built on top Nextjs. But in general in nextjs it works in the root components.
Very nice article. Not my cup of tea, zero API layer and monolith approach can really be a problem.
We believe most apps should start as a monolith. In the early days of an app, fast development speed and getting users is way more important than having a perfectly, infinitely scalable architecture from day 1.
That said, Blitz already greatly improves on monoliths like Rails because Blitz can be ran serverless where each API endpoint is its own serverless function. So it's already serverless ready!
And over time we will be making Blitz more powerful, flexible, and well suited for enterprise environments and more complex backend architectures.
To clarify, there is an API, it's just abstracted into a compile step. So there's some magic there, but it's very minimal and easily inspected.
Most apps should not start as a monolith. However the first time a senior engineer is attempting to grok microservice design patterns, definitely they should go that route of decomposing monolith into microservices. Training wheels aren't needed forever unless they're doing a poor job implementing those patterns, training/selling their teammates on it, or failing to convince their bosses on the efficacy of microservice architecture.
If that's the case, monolith away: let the team balloon around that beast, increase the cost of technical debt, increase the ramp-up time for new engineers, slow down & formalize those release cycles & code freezes, and let's party like it's 2011!!
Microservices is a pattern to solving a particular problem. It's not the hammer for every nail.
I think the title is a bit misleading which is inviting some unwarranted criticism. Blitz.js is not a framework comparable to Next js, Gatsby or Svelte kit. It is sort of a starter kit for SAAS apps so it is not meant to replace these frameworks. It is meant to quickly scaffold a SAAS web app with batteries included.
Regarding the monolith vs microservice architecture, microservices are not inherently better than monolith. When finding product market fit, we need a monolith architecture to rapidly make sweeping changes to codebase which would be extremely difficult with a microservice based architecture.
And this is what Martin Fowler has said about the topic.
"1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2) Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. ."
martinfowler.com/bliki/MonolithFir...
Blitz is not a starter kit. Blitz is a full-on framework meant to replace Nextjs, Gatsby, etc. Blitz is a fork of Nextjs that adds many fullstack power features and has a much more open governance structure than nextjs. For the foreseeable future (as long as the blitz community wants) we are merging in all new nextjs releases.
I don't see how can it replace application level frameworks like Sveltekit or Next.js since Blitz comes with a lot of decisions baked in and a lot of features some apps might not need and require customized functionality which would be easier to build with application which is not monolith.
Not accurate. One of our foundational principles is "loose opinions". We have recommendations for most people, but it's easy to ignore. There's almost no decisions we have baked in.
You can say this about anything, including Javascript itself. Not a great argument my friend :)
Blitz is literally way better that you are imagining :)
How can something be monolith and have loose opinions/coupling between subsystems? Both of them cannot be true simultaneously.
Yeah, it is not a good argument, that is why I didn't make it :) . I made this comment within the context of a monolith framework. If it contains many features, necessarily there must be tight coupling between subsystems at some layer to provide a more cohesive experience. I think this is actually a tradeoff we need to make.
Secondly you kind of misquoted me probably by mistake, this is my full comment which makes more sense given statement that comes after and.
Probably, but I am not a fan of React, this is the primary reason for me not using it, its not your fault though. I think React is a sane choice for a lot of people due to its vast ecosystem.
The fact that this article promotes having a monolithic app as against API is problematic. Where does blitz stand in the future of micro services and severless architecture? How do you integrate it with a headless CMS?
We believe most apps should start as a monolith. In the early days of an app, fast development speed and getting users is way more important than having a perfectly, infinitely scalable architecture from day 1.
That said, Blitz already greatly improves on monoliths like Rails because Blitz can be ran serverless where each API endpoint is its own serverless function. So it's already serverless ready!
And over time we will be making Blitz more powerful, flexible, and well suited for enterprise environments and more complex backend architectures.
To clarify, there is an API, it's just abstracted into a compile step. So there's some magic there, but it's very minimal and easily inspected.
And you can integrate with a headless CMS in exactly the same way as any other React or Nextjs app.
I've been following Blitz since I watched it on Prisma day 2020, glad that it has come so far. Personally I find it really cool to quickly prototype apps and get things out there without worrying about setting up db, css-in-js stuff etc
Only issue I have is that it's another framework on top of already a "meta-framework" on top of React, so two layers of abstraction make it quite tightly coupled but that's not the issue Blitz team is trying to solve (I think)
But overall, it's a really cool project!
Thanks Karan!
We are transitioning into a fork of nextjs, so it'll no longer be three frameworks deep :)
More details here: github.com/blitz-js/blitz/discussi...
Nice!
I released a SaaS starter for blitz 1upblitz.com
I’ve made 2 SaaS products with blitz and it’s safe to say blitz is the most productive framework.
I don't get why people worried over monolithic architecture for early stage startups. Do you really want to implement all kinds of enterprise application architectural patterns for an idea that you would like to ship to market as fast as possible? I really don't want to create a seperate Node.js server and do all of the configurations for different environment. Why do I need that seperate REST layer if I only have one FE to communicate and what I do is basically a CRUD app? I think it really depends what you are trying to achieve but I will definitely give it a go to this framework. I have some side projects in my mind and I want to ship them as fast as possible, I don't really care about scalability at this point.
You lost me and (probably) others at "Ruby on rails inspired..."
It’s what sold me.
What about rails makes you uninterested in blitz?
I haven't tried blitz, but I love the idea of a batteries included framework for Javascript. Coming from a rails background, even just the niceties of a framework having backend preferences( database, ORM, testing libraries etc...) could be a huge win for productivity.
I've always liked Javascript more than Ruby, but I also like Rails more than _____. <-- left blank intentionally
A framework on top of Next.js itself? And we're already so far away from the metal as it is :) I can't see a real advantage to adopting Blitz.js yet, but I'll keep an eye on its progress.
As for "microservice vs monolith", Next.js after version 9 (and really the whole serverless movement / JAMstack in general) really obviates the whole debate in my experience. And with Next.js 11, Atlas/DynamoDB/Firebase/Headless CMS, and Vercel/AWS Lambda/Azure Functions, whatever remaining delineation between the two evaporates. Modern Next.js apps can be deployed as a "monolith" (e.g. npx next start) or as a series of managed microservices (e.g. npx next start with custom server) or as unmanaged serverless functions in the cloud (e.g. npx vercel) with little cognitive overhead.
Then again, maybe it's because of my prior experience with FastCGI Process Managers; I'm used to building backends (both monolith and distributed) that handle each request as a short-lived isolated process with any shared/persistent state pulled from some database (hello, PHP).