As you know, everything has tradeoffs. So what are the tradeoffs of Blitz?
Every framework has a certain level of lock-in. If you build your app with React, it's very locked into React.
Blitz's level of lock-in is one level higher than Next.js. A Blitz codebase is not a lot different than a Next.js codebase. But it is enough different that it wouldn't be super simple to "eject" to plain Next.js. For example, you'll probably use the Blitz authentication which is unique to Blitz. But switching to Next Auth would give you a comparable experience with Next.js.
The Blitz zero-API data layer is unique to Blitz. So if switching to Next.js, you'd have to manage your own API code (which you would have to do if you started with Next.js, so you haven't lost anything). However, all your backend query and mutation logic can be directly ported.
If you want to be on the bleeding edge of Next.js releases, know that Blitz will be slightly behind but not far. Usually we update Blitz within a week or less of a new Next.js release.
But if you use yarn, you can use the resolutions field in package.json
to upgrade next.js before we do.
Some folks say, "you'll eventually need GraphQL so you should start with it". While we believe most apps won't grow large enough to warrant GraphQL, the question of an API for multiple clients is an excellent point.
We fully acknowledge that many web apps will need a mobile app sooner or later. And we want to make this integration as simple as possible!
That said, you can add a GraphQL server to your Blitz app for other clients. This can be an excellent choice and some folks are doing this.
Currently, as of Feb 17, 2021:
blitz routes commandWhat we plan to do going forward:
Currently Blitz is fairly minimal on backend architecture, especially compared to something like Nest.js or AdonisJs. However, that doesn't mean you can't use those patterns in Blitz, it means you have to set it up yourself. In fact you can use Nest.js in your Blitz app if you need.
But we are very interested in bringing more advanced backend architectures to Blitz by default or via simple opt-in. We have an ongoing discussion that we'd love you to chime in on if you have ideas.
This is a tradeoff of Node.js in general. Node.js is single threaded which means if you are doing heavy backend processing you may notice that all web requests begin to suffer. The solution to this is spawning background processing off into other processes.
Running multiple background processes isn't super difficult, but we want to add docs and APIs that make this as simple as possible.
This isn't a problem when deployed to some serverless platforms, such as Vercel, because these platforms only allow a given Node.js process to serve one request at a time anyway. However, note that deployment to Vercel is not recommended for other reasons.