bull VS Blitz

To implement the solution with a queue, I used a package called 'Bull' (https://github.com/OptimalBits/bull). It's a library that helps with distributed job control, providing some very useful solutions for this type of work, such as background job processing, queues with priorities (FIFO, LIFO, and others), among other features. 'Bull' uses Redis for queue storage, so if your application crashes for any reason, once it's back online, it will continue executing the processes that are in the queue. In our case, we'll use the FIFO (First in, first out) queue solution, meaning priority based on arrival order.

We use bull-js for our distributed queue and event-driven library.

I'm using the excellent Redis based Bull.js as a job queue on Kubernetes.

For Job Queue, NestJs provides a package named @nestjs/bull as an abstraction/wrapper on top of Bull, a popular, well-supported, high-performance Node. js-based Queue system implementation.

I'm working on a large ETL project that involves handling queues for file integration. Currently, we are using Redis with Bull (https://www.npmjs.com/package/bull) for this purpose. However, to streamline our architecture and address security concerns, we are considering migrating the queue to PostgreSQL.

BullMQ is a pretty solid choice: https://github.com/taskforcesh/bullmq It's the successor of Bull: https://github.com/OptimalBits/bull

For Node specifically, things like Streams, understanding the asynchronous model completely, and the event loop. Also, queues tend to get used a lot in Node, so understanding the basic concepts behind that and how to use something like bull would be useful.

To do this properly, you need to put the task into queue, so if there are 1000 simultaneous uploads it won't kill your server but will be processed one by one. For the queue, see bull. Image hostings like AWS have some functionality for processing on their side, as an option.

This is a memory intensive process though and Heroku is OOM'ing with R14 errors. For this they recommend migrating intensive work like this to a Background Job via Redis, implemented in Bull and Throng

Blitz is also an open-source project that allows users to access the code and allows to contribute. Their community has generated a lot of impact as well, and has grown rapidly over time since the creation in 2020:

Not yet, I actually just whipped it up quickly last week after I was browsing the Notion subreddit and it reminded me of myspace.

These are the tools I used:

* BlitzJS (https://github.com/blitz-js/blitz)

Maybe you could help/join this project? https://github.com/blitz-js/blitz

Hello, I'm the creator of Blitz.js (first announced 2.5 years ago)

Today the Blitz.js 2.0 pivot to a modular Next.js toolkit reached Beta status [1]

Previously Blitz abstracted Next.js, but Blitz 2.0 is now a modular toolkit that plugs into any new or existing Next.js app. Blitz picks up where Next.js leaves off, providing libraries and conventions for shipping and scaling small to large apps.

When I first created Blitz, my aim was to have an all-in-one fullstack framework for Javascript like Ruby on Rails. But that proved to be too difficult. I've decided that achieving an all-in-one framework for JS like Rails is too difficult unless you have a ton of funding and don't have to make meaningful money.

The difference with JS is that client-side frameworks like React have an incredible amount of complexity. Trying to manage all of that and all the other fullstack framework stuff like API layers, auth, file uploads, etc is too large of scope.

So now Blitz is no longer trying to do it all and is focusing on all the non-frontend functionality you need to ship web apps.

Going forward, we want to be the most trusted technical resource for rapidly building and scaling full-stack TypeScript apps.

[1] https://github.com/blitz-js/blitz/releases/tag/v2.0.0-beta.1