Tradeoffs

As you know, everything has tradeoffs. So what are the tradeoffs of Blitz?

Framework Lock-in

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.

Next.js Upgrades

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.

Multi-Client API

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:

• You can directly access the auto-generated API endpoints and you can use them in any mobile app (we currently have a few people doing this)
• You can see all generated endpoints in your app using blitz routes command
• You can see the RPC specification for the endpoints here: RPC Specification

What we plan to do going forward:

1. First step, add docs and tools for making it easier to manually use the generated API endpoints. See https://github.com/blitz-js/blitz/discussions/1907 and https://github.com/blitz-js/blitz/issues/745
2. Next, add ability to generate a JS/TS client library as a nice way to use the generated endpoints from an app
3. Next, add some sort of first-class react-native support where you can import blitz queries/mutations directly into your react-native code and have it magically work exactly like it does today with your web app. After the 1.0 release, this will be Brandon's main focus for the year.

Advanced Backend Architecture

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.

Single Threaded

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.