In 1990 I was super excited to have my high school work experience application accepted to CSIRO in Macquarie Park, only to find when I turned up that I’d spend the whole boring week cataloging magnetic tape from these dull satellites Landsat 4 & 5. The only time my greybeard supervisor seemed remotely animated was when he started imagining what imagery 6 & 7 would send back.
How wrong I was; what this now greybeard wouldn’t give to rummage through that lab again.
Gabe here, one of the hatchet founders. I'm not very familiar with these runner so someone please correct me if I missed something.
These look like great projects to get something running quickly, but likely will experience many of the challenges Alexander mentioned under load. They look quite similar to our initial implementation using FOR UPDATE and maintaining direct connections from workers to PostgreSQL instead of a central orchestrator (a separate issue that deserves its own post).
One of the reasons for this decision to performantly support more complex scheduling requirements and durable execution patterns -- things like dynamic concurrency [0] or rate limits [1] which can be quite tricky to implement on a worker-pull model where there will likely be contention on these orchestration tables.
They also appear to be pure queues to run individual tasks in python only. We've been working hard on our py, ts, and go sdks
I'm excited to see how these projects approach these problems over time!
I've intentionally chosen simple over performance when the choice is there. Chancy still happily handles millions of jobs and workflows a day with dynamic concurrency and global rate limits, even in low-resource environments. But it would never scale horizontally to the same level you could achieve with RabbitMQ, and it's not meant for massive multi-tenant cloud hosting. It's just not the project's goal.
Chancy's aim is to be the low dependency, low infrastructure option that's "good enough" for the vast majority of projects. It has 1 required package dependency (the postgres driver) and 1 required infrastructure dependency (postgres) while bundling everything inside a single ASGI-embeddable process (no need for separate processes like flower or beat). It's used in many of my self-hosted projects, and in a couple of commercial projects to add ETL workflows, rate limiting, and observability to projects that were previously on Celery. Going from Celery to Chancy is typically just replacing your `delay()/apply_async()` with `push()` and swapping `@shared_task()` with `@job()`.
If you have hundreds of employees and need to run hundreds of millions of jobs a day, it's never going to be the right choice - go with something like Hatchet. Chancy's for teams of one to dozens that need a simple option while still getting things like global rate limits and workflows.
Yeah, this is a bugbear. FWIW my wife and I "share" keychain items by airdropping them to one another as required. It works, but nowhere near as nice as having a common record we can both maintain.
FastAPI has 50% as many issues open right now, as Flask has had in total (1.1K vs 2.3K), and ~500 open PRs currently while Flask has had ~2.2K PRs in total.
Yet, both repositories have closed the same amount of issues during the last month, but FastAPI only merged 2 PRs while Flask has merged 21.
Popularity probably plays into this a lot, but it's also just very clear that whoever is doing the management of Flask, is doing an excellent job! Kudos.
I personally have a PR ready to go which adds documentation for API Key Auth (missing page till now, very requested by community[1]), which has been ready since early May, stagnant for almost 3 months now[2], don't know how to bump without spamming.
It's unfortunate, because FastAPI is one of the best libraries I know of otherwise in terms of capabilities for time spent writing code. Nowadays, though, when recommending this lib at work, I need to add "but pray you don't hit a bug or missing docs, or you're on your own".
FastAPI has a lot of straight-up low-effort, borderline spammy questions. I think it's a community /communication thing. Somehow flask keeps the riff-raff down, or at least in the discussion and out of issues. So however they do that, FastApi needs to do as well.
On top of that it definitely is in need of more top-down organization, delegation, and coordination.
For this reason I wouldn't recommend FastAPI for anything serious. If it works, fine, but if you hit an edge case... prepare for a world of trouble. I wouldn't build my stack on top of it.
Lots of half-baked clones but remarkably few quality foss implementations. WeKan is… a mess. Taiga is complex & the frontend is CoffeeScript (!!). FocalBoard looks about the best of them, but it’s still missing many features and they’ve explicitly rejected calls for OAuth and/ or SAML because they want as a paid feature.
I’ve also tried many products to replace Trello and finally settled with Taiga. It doesn’t look complex, and the UI is great too. The only missing bits I find are native mobile apps.
Yup - huge fan 20yrs (!!) ago. Great community with plenty of players back then. I still log into my main character every couple of years just to check they’re still going.
