Blitz.js Now in Beta (Batteries Included Framework Built on Next.js) | Hacker News Reader

Blitz.js Now in Beta (Batteries Included Framework Built on Next.js)

blitzjs.com

262 pointsflybayer78 comments

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.

Notifying the user isn't graceful.

"Hi, we can't handle any version skew so please interrupt what you are doing to click this button and reload the app."

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.

Yes, good idea!

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 :).

A framework of framework of frameworks. Good job JS community!

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

Isn't Rails a library of libraries of libraries?

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.

> because you lose stability and reliability

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 agree with you on that but JS still keeps surprising me :)

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?

Thanks!

Ha, thank you!

> Re: recipes

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).

Sweeet. I could actually see Blitz being really useful as an admin interface over an API, where the generated API drives web/mobile apps.

This sounds very cool but the code sample on the front page didn't have instant appeal for me.

Once I Googled a little and found out what it was doing it looked awesome, but it was very noisy if you don't know the components of Blitz.

Compare it to this code from early in the ActiveRecord guide:

"class Product <

    ApplicationRecord

end"

Thanks. Glad to see I'm not alone.

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.

Congrats on the beta!

TL;DR Give Blitz a try.

I've been developing my app with Blitz. It has been an extremely productive framework to work with.

The following are a few of the productivity boosts that I like:

1. It includes authentication plus there's a good library for authorization (blitz-guard) so auth is a breeze.

2. The generator is helpful when I started with Blitz, but use it less now.

3. The community is friendly and helpful. ex. Check out this post on skeleton loaders https://andreas.fyi/engineering/nextjs-auth-skeleton-loaders

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 tried it out today. It seemed like it didn't include eslint, and there's so much boilerplate code generated.

It definitely includes eslint!

Our boilerplate generation is currently optimized for folks building real production apps.

We'll be adding a minimal boilerplate option here at some point (PRs welcome!)

I love how similar this is to Rails, specifically the generate commands.

I'm going to enjoy playing with this! well done

Reminds of Meteor 2.0

https://blog.meteor.com/meteor-2-0-is-here-867b0ab4f8df

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).

Why not create a column in the user table named `jwt_id` which you store a random hex that is added to the JWT payload.

To logout the token just invalidate or change the `jwt_id`

well then we are back in the database, so basically it is a session again.

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...

https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-...

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.

Reminds me of Meteor 2.0 except built upon Next.js

Interesting to see where it go, +1 for a batteries included RoR like framework for JS/TS.

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.

We’re still in beta, yo! We’ll get there. :)

Currently I’m using an instance of Prisma studio in production as an admin interface for the database.

I think Prisma Studio definitely serves the purpose of a proper admin UI to quickly view and edit data!

Learn more: prisma.io/studio

Good stuff - keep at it, looks like a very solid offering.

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.

Blitz comes with a forms library -- react-final-form by default, but you can also use react hook form or formik

Forms used to be a big pain in React but React Hook Form is a huge improvement. Easy to implement and built in validation.

https://react-hook-form.com/

Amazing!! The idea to generate an API when compiling is very good.

The only thing that is holding me back is that as far as I understand Prisma doesn't support cascading deletes.

Meaning that if I have to delete a user, then I have to manually delete all his projects, comments, posts, etc... which is not nice.

You could just setup the CASCADE in the DB and it will handle cascading deletes. They have docs on it...

https://www.prisma.io/docs/guides/general-guides/database-wo...

Can a backend for Cloudflare Workers become available?

Workers does not support Node APIs (https://developers.cloudflare.com/workers/learning/how-worke...)

There is documentation of deploying a NextJS app (https://developers.cloudflare.com/pages/how-to/deploy-a-next...)

No. Blitz doesn't work in places that requires "next export"

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.

Currently you can’t deploy them separately, but that’s something we could probably add.

Does that mean ones only hope to scale would be to deploy on a bigger server (I know one can get pretty far just by that)

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).

That may be a good feature for teams as things progress.

Amazing how fast this is moving, congrats! Looking forward to seeing it being used more broadly.

Just saw that they have links to "Made with blitz" on their wiki in case anyone is interested: https://github.com/blitz-js/blitz/wiki#-made-with-blitz-incl...

Been dabbling with this framework back and forth. Excited to see it in a stable spot. Finally gonna build a medium sized project on it now.

> At build time, that function import is swapped out with an auto generated HTTP API.

This was surprising to me, I thought it would be focused on SSR.

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've been on the lookout for a sort of Node equivalent of Rails.

May I ask why particularly rails?

Rails is often regarded as the Get Shit Done framework.

In the spirit of Rails, does Blitz include a repl analogous to irb? Something that automatically loads in your models and maybe config?

It’s been a while since I’ve used Rails but that interactive environment was my favorite way to get familiar with activerecord models.

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.

It does have that aswell: https://blitzjs.com/docs/cli-console

Aha! Thanks

Now I’m certainly going to be trying Blitz.

I'm genuinely curious in what ways you feel Redwood is more in the spirit of Rails than Blitz? Maybe there's some things we can improve.

This is one of the things I'm most excited about for frontend development. Glad to see it's in beta!

Will have to give this more use on something beyond "Hello World" soon.

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!

Not sure how I missed that on mobile.

Then this is my dream framework

I feel the same way. The docs read like a wishlist of everything I've fantasized about in a framework over the last 5 years. Can't wait to try it out

The code samples are in typescript...

Blitz is a huge time saver for our team's productivity!

Awesome work! Love the stack.

How does this compare with Supabase?

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.

Makes sense, thanks for the reply and congrats on Beta

How does this compare with Sails, which also seems like a full stack MVC framework..

I'm not too well-versed in the JS world.

I hadn’t heard of Blitz until now but am loving the look of it. Congrats on the beta!

Reply on news.ycombinator.com