What is the status of this project?

[Roundaround]

I just came across this project and for the purposes of building Next.js apps for self-hosters this seemed like a great solution!...at first.

The last human activity on this project was accepting a PR for Next.js app router support and a few small bugfixes 8 months ago. The hosted service was shut down by Netlify 18 months ago and 90% of the docs are still written as if nothing ever happened. There are broken links everywhere, mentions of getting access tokens from the hosted service, very light documentation on self-hosting with no examples, and even the old service status page is still live, showing a wall of red!).

I understand having a day job and not being able to work on it full time, but 8 months of nothing, and docs being out of date for 18 months seems like the project is just outright abandoned...

It would really sadden me if the story here is "someone made something really cool and open source, then a big company swooped in and hired them to work on an internal fork instead, effectively killing the project".

[Skn0tt]

Hey Evan! Author of Quirrel here. Well, first of all, thanks for saying that you think Quirrel is really cool! That's always great to hear :D

I wouldn’t call Quirrel “abandoned”, but in maintenance mode instead. As you can see, there hasn’t been any feature development since the acquisition, but i’ve continued to do maintenance and solve any issues that existing customers had.

It would really sadden me if the story here is "someone made something really cool and open source, then a big company swooped in and hired them to work on an internal fork instead, effectively killing the project".

I think that's the cynic view of the story. I empathize with that - tend to be much of a cynic myself - but I think the story is different here! I think the story is "someone made something really cool and open source to extend big company's platform, then big company swooped in and hired them to work on integrating it even better into their platform, effectively making the project achieve its goal even better and superceding the project itself". It's OK for OSS projects to not be around forever, and Quirrel was useful in the time before platforms had Cron support. This means Quirrel's lifespan has come to an end, and it's in maintenance mode now. Let me elaborate:

Without a hosted version of Quirrel, I do think that the central value proposition doesn’t hold anymore. Quirrel was nice for having CronJobs + Queues on serverless platforms like Netlify or Vercel, where the traditional job queueing systems like BullMQ don’t work. After the acquisition, I helped build that functionality into the Netlify platform itself, and Vercel followed a couple months later. An integrated setup like that will always work better than hooking up a 3rd-party solution like Quirrel. On top of that, there’s new hosted offerings like Inngest, that do all of the advanced stuff that Quirrel did, plus more.

If you’re looking for a self-hosted solution, though, libraries like BullMQ are a much better fit. They don’t require another hosted service, and can be deployed inside your existing application server, massively simplifying operations. In the case of BullMQ, there’s even a professional services company associated with it, for the customers who value that.

For me, this means that Quirrel achieved the goal that I set out to solve: Make Cron Jobs available to users of Netlify and Vercel. I’ve achieved that, and it makes me proud. Now that it’s solved, I keep maintaining it for the existing customers, but I don’t do any feature development for the reasons outlined above.

[Roundaround]

Thanks for your quick and lengthy reply!

I just wanted to apologize for being a bit combative and cynical in my original post. It was late, I was tired (and a bit frustrated, in case you couldn't tell!), and I was noticing a pattern of "find a cool new project, get excited, find out the project is sunsetted" when trying to develop some internal tools on the Next.js stack, and I unfairly took it out on you and Netlify.

I understand the reasoning behind your decisions, though it doesn't make it any less sad. Quirrel's architecture of keeping the job handlers within the Next.js context was the biggest selling point to me. It's fair to say that the hosted Quirrel service only makes sense when combined with other serverless solutions like Vercel and Netlify, but a large percentage of users self host Next.js with locally-managed Node processes. This means the self-hosted Quirrel project can still offer value to a lot of people.

Either way, both Quirrel and BullMQ requires a separate process to coordinate task scheduling, but I appreciated the fact that the "Quirrel server" was a generic standalone server with no real application-specific logic. With BullMQ, I need to build out my workers and run them as separate Node/Bun/etc. service(s), which means none of the resources (db connection primarily) can be shared with the Next.js stack. I know that technically I could replicate Quirrel's architecture using BullMQ, but that would mean handling the encryption and authentication layer between the message queue and Next.js myself.

Probably the biggest hurdle with BullMQ is TypeScript. If using it without Bun, it falls on the developers to figure out the maze of tsconfig grossness that allows us to 1. run Next in development mode, 2. build and optimize the Next app, and 3. package the Next app alongside the workers in a single environment, i.e. a Docker image. I learned the hard way that without Bun to run .ts files directly and have them "just work", sharing a TypeScript environment between the Next.js dev environment and the BullMQ workers is surprisingly difficult, especially when file watching, environment variables, import aliases, and shared utilities all get involved.

At the end of the day I don't have an answer for this, and I don't expect you to have one either. It's entirely likely that I'm spending too much time on the little implementation details and not enough time on the products built on top of them. Really I just wanted to vent and complain that sometimes web development is moving too fast and things and things get abandoned too quickly for the latest and greatest shiny thing (insert reference to the "good ol' jQuery days" here), especially considering that not all of us have the luxury of hosting our web apps on external cloud solutions.

Regardless of the future of Quirrel, I just want you to know I think it's a great project. I'd hate to see it fall to the wayside but I suppose that's just how things go sometimes.

[Skn0tt]

Appreciate your reply, and the apology on the tone :D In Germany, we'd say "apology accepted". I very much empathise with the underlying concerns, though - projects being sunset is always hard to see, especially in the oh-so-hypecycle-driven world of JavaScript. A world where some people care more about their development experience than about user experience or (god forbid!) business outcomes. I'll stop myself here before this turns into too much of a cynics manifest, but if you're ever around Berlin let's rant over a beer :D

With BullMQ, I need to build out my workers and run them as separate Node/Bun/etc. service(s)

I don't think that's true. Have you tried putting the worker initialisation code into the startup part of a custom server, or into instrumentation.ts?

That would also solve all the TypeScript hurdles, since your Workers code will be part of the same entrypoint as the rest of your Next App.