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...
For further actions, you may consider blocking this person and/or reporting abuse
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).
I don't know to be honest, a framework that was built on top of another is not really a good thing in my opinion.
You mentioned in other comments that "every app should start as a monolith" is not really my thing. If you start as a monolith in a startup and it starts to grow insanely you won't have the time to refactor everything and you end up with a mess no one wants to touch. Been there, done that. :)
Also, I think learning a new framework is more time-consuming than using an already established framework or library in an early stage of a product.
Nowadays everyone tries to support or design the structure to be scaleable and to be honest with an experienced team, it's not time-consuming at all. I would not spend much time to learn yet another framework just because I can quickly prototype an MVP, which no other person will understand and it won't scale in the long run. I like to give myself the opportunity to not shot myself in the knee a few months later. If you follow good design patterns, that matters the most and will save you some headaches. Libraries or frameworks will come and go..
What already established framework or libraries do you use to build a new app?
I really fail to see the point in just adding another abstraction layer on top of an already tried&tested framework such as NextJS and selling it as a completely new framework.. plus the monolithic approach doesn't sell too well to corporates in the age of cloud scaling and microservices.. sure, startups might give it a try to get to speed ASAP to secure some funding rounds to survive, but i doubt Blitz is here to stay in the long run.. just my 2 cents, would love to be proved wrong..
Thanks for writing this article. At this point, I don't really think we need or care for a new framework. They all look and perform the same. Just a few KBs and milliseconds of difference. Blitz must be nice but I'd never know because I'll never give it a try.
It is based on NextJS, but with a custom server: blitzjs.com/docs/what-is-nextjs
Yep. And we are now in transition to be a fork of Next.js.
More details here: github.com/blitz-js/blitz/discussi...
Yeah, seems like one of the best modern fullstack tools out there, two thumbs up !))
should i try
After a week with blitz I freakin love it. I know there might be some concerns with like "Hey only X people use this", so I'm really hoping blitz explodes in popularity like it deserves to.