I've been tinkering with redwood.js for the last couple of months. I quite like it and it definitely speeds things up, compared to rolling out everything yourself. But since this is alpha-grade, there have been a lot of breaking changes -- which I totally understand, but it's been PITA to work on upgrades vs my side project. To the point: how does the upgrade situation looks like with Blitz.js? What are the plans for breaking changes now that's in a beta? Also, what would be the biggest differences between redwood & blitz (besides blitz being based on next)?
Lastly, thank you for working on this project/problem, definitely a lot of potential here. I've also seen that you really care about the community around the project, which is awesome!
We expect only minimal breaking changes to Blitz from here on. 1.0 is expected in April.
The biggest difference between Blitz and Redwood is that Redwood makes the API layer easier with conventions and APIs, whereas Blitz abstracts away the entire thing into a compile step. So working with Redwood requires working with APIs like normal. But with Blitz you can almost forget an API is even there.
"But with Blitz you can almost forget an API is even there."
How does it work for clients using an old version of the app? I.e. if I change the db schema and update it for new clients, what will happen to older clients?
It works the same as any other fullstack web app (possibility for discrepancies). We'll add a hook/API that allows you to easily detect if a new version is deployed and handle this gracefully by e.g. notifying the user.
I'd also like to go even further and add some type of detection to the build that would notify you of potential issues.
makes sense. could also explore versioned routing, where you detect multiple versions based on filename (e.g. *_v1), folder name, or some export naming convention.
Thanks, 1.0 being just around the corner definitely makes me more interested!
As for the redwood vs blitz, I think I get what you're getting at but still not fully grok what _exactly_ it means/looks like (and what are the tradeoffs). I'll experiment with it, so I can develop the intuition myself :).
I actually like this. Id rather grab something of the shelf that has reusable react components for a quick beta than a framework has no usable components for future work
Library of libraries is ok. By product of DRY principle and actually not all bad.
Frameworks built upon frameworks upon frameworks is bad, because you lose stability and reliability, because you depend on libraries and frameworks. Better choose a good framework and spend time on it.
I respectfully disagree with this. Next.js is extremely stable and reliable, so no issue there.
Now without Blitz you would be cobbling together libraries on your own. What do you think will be more stable and reliable, your own homegrown thing or Blitz which has a sizable and growing community that's always making it better?
I have been a tad skeptical about how Blitz.js would accomplish "batteries-included" elegantly, but 5 min into reading the (very thorough) docs and it seems like a fantastic amount of abstraction to work with. You're a genius flybayer!
2 questions:
1. How the docs read right now, I'm cautious about the "recipes" concept. It's not clear why I'd need to use a recipe to install Tailwind instead of installing Tailwind via NPM. I'd love the docs to explain what "coupling," if any, occurs with Blitz <> a recipe's dependencies, so I can better understand what I'm opting into by choosing the framework.
2. Is there a roadmap for API-only implementation, like Rails? If I want to use some of my Blitz endpoints from another client is that possible?
You don't have to use recipes. Recipes simply package a number of manual steps into a single automated command. Recipes let you install a library without looking up the install docs.
Recipes are roughly "install dependencies + codemods". So for example the `chakra-ui` recipe installs the needed dependencies and adds the theme provider to your app root.
There's currently zero coupling with recipes. The end result is exactly the same as if you did everything manually.
> Re: API-only
Currently you can do that. You can use the API routes (which give you direct access to Node req, res objects. And don't add any pages (or just a few, as you want).
The one thing that was holding me back from going forward with Blitz is the rapid amount of changes, so this is very exciting. I'm using NextJS with NextAuth and Prisma right now, but I want it more integrated with more of a server aspect to host. Blitz is such a great idea.
4. The integration with Prisma is buttery smooth. In your UI code you call a function that has the database access. Blitz converts the function calls into API calls and runs your database code on the server. When Prisma is not enough you can drop to `db.$queryRaw` to write SQL directly.
5. Personally, I dislike fiddling with 800 libraries to get a project up and running. Blitz includes Jest, Prettier, and everything else you need so on so that you're productive from day 1.
I've tinkered with this in side projects and it's really a joy to work with. The setup for a basic CRUD app w/ GraphQL and Auth/plugins/CSS frameworks takes ~1minute, and the generated code is pretty extensible.
Is there a possibility to scale Blitz.js based applications? It seems as if there is some stateful behaviour to achieve the deep integration of logic between back- and frontend. Would scaling be possible with sticky sessions?
Currently sessions are database-backed, but that can still scale a lot, especially if you use Redis. However we do plan to add JWT-based auth at some point.
Then you get to scale the jwt token black list... (which is more of a headache because you still need to keep application wide state, than a headache to actually scale).
Right. I've yet to see any combination of easy/sane setup for jwt (beyond the fact that it's somewhat standard, although less standard than basic auth).
You might set the jwt to expire in 15 minutes, for a 5-10 minute session allowing for clock drift - and just eschew the black list.
But now you need a longer lived "refresh token" and a service endpoint that handles that, along with a black list.
It is "simpler" in the sense that: your app have two separate auth/clients - one is very simple - gets a jwt token and renews every ten minutes - the rest of your app simply uses the jwt.
On your server side, you can have a dedicated/simple service that only renews jwts given a refresh token (checks refresh token blacklist) - and your other apps blindly trusts the jwt (checks signature and the short timestamp).
You've now reimplented half of kerberos - along with "pass the hash" - and at least you can reason about the trade-offs you've made...
I agree with the points made, but want to make a case for JWTs for all service landscapes based on message queues, kafka or asynchronous communication. There the statelessness really shines.
Just tried it my my team, it looks promising. You can literally make the full stack app in 5 minutes using Blitz. It supports SQLite, PostgreSQL an MySQL out of the box.
This is pretty cool but the thing that all JS frameworks seems to miss out is an admin area. Why?
This is one of the main reasons I'll continue to pick Django as a back-end. Django + DRF does pretty much everything you would ever need from a framework with the added bonus of a fully working and customizable admin straight out the box.
Also forms. Django forms and admin packages make it very productive and appealing. I have yet to see a JS framework pull it off, because if they did, I'm sure it would be a huge hit.
Been using in hobby projects for a bit now, absolutely fantastic framework, especially the data handling. It also gives you a few goodies by default that Next.js doesn't.
What does the `Zero-API` data layer abstraction imply? Asking because I want to understand if the frontend and backend can be deployed on different web servers.
Blitz.js basically "compiles" down to Next.js, which can be deployed fully using serverless functions, which basically means infinite scalability (for the application, the database is another point).
This sounds very interesting to me as my team has had some real struggles figuring out how to deal with things like authentication in Next.js. In one case, we've rolled our own oauth with a completely separate express api. In another, we still haven't quite decided. I've been on the lookout for a sort of Node equivalent of Rails.
I actually think that RedwoodJS is more in spirit of Rails than Blitz and it does include a lot of boilerplate generation. But yeah, Blitz does have a CLI as well:
https://blitzjs.com/docs/cli-overview
Thanks. I’m referring more to a REPL environment for executing inline javascript against your project rather than a CLI of prebaked commands.
So something like creating an instance of an existing model definition and trying out its methods instead of CLI for running a database migration or generating a stubbed model definition.
Does blitz have typescript support? I’ve looked everywhere on the site and there’s no mention which is a bad sign. It’s too hard to build large apps with vanilla JavaScript
It's on the bottom of their front page...
First Class Typescript Support
Blitz is built with Typescript and the Blitz data layer is fully end-to-end typesafe. All types are completely static without needing a separate type generation process!
There's a bit of overlap with Supabase because they are positioned as "open-source firebase". But you can just use Supabase as the DB provider for your Blitz app.
In general, I'm way more in favor of owning your entire stack, like Ruby on Rails and Laravel vs relying on a third-party service for the core of your app.
Lastly, thank you for working on this project/problem, definitely a lot of potential here. I've also seen that you really care about the community around the project, which is awesome!