A proposal to sponsor improvements

[laurentS]

slowapi has passed the 2^10 (1024) stars mark (1361 as I write this), over 4k public repositories are using it, and who knows how many private ones.

I have been maintaining the package on my spare time since the beginning, and while I wrote it to "scratch my own itch", I have not actually been using it myself for a while now (as in, several years).

There have been a number of requests for various features and improvements, many of which appear to come from companies, most probably making money with the library (or more exactly, probably enforcing limits on their customers' paid plans, given the recurring ask about the ability to link a limit to the request object). Some requests have been polite and nice, others not so much.

I have added a lot of people to this repo (as per #58) over time: 16 were invited, 13 accepted the invite (and it looks like I forgot to invite another 8 people who submitted PRs, my apologies, that invite is still ready for you if you want it 😅). There have been a few bits of help, but nobody has stepped up to take over the job of maintainer.

Given that I also don't want this repo to become abandonware because the package clearly is useful, I can see 2 ways forward:

1. one or two people come forward and take over the maintenance of the package. We can arrange to move the repo under an org or something, and I can get out of the picture. This hasn't happened yet, but I'm putting the offer on the table just in case. Preferably, I think it would make sense for someone who's already contributed to take over.
2. I could work on an overhaul of the package with the following purposes:

• switch to a dependency injection structure instead of the current decorator approach. This would allow using values computed at request time instead of at app start up time, including the most requested feature. See #13 for some context.
• go fully async. Right now the code that checks limits is blocking on each request. Though I have not quantified this, I expect the performance impact to be non-negligible.
• improve the release process so that community contributions can be pushed to pypi with very little effort, hoping that all the people in this repo can help each other out with minimal effort.

I cannot do this for free however, and this is where you come in. This post is essentially offering you to throw a bit of money at me to improve this library that you use everyday.

Looking at https://pypistats.org/packages/slowapi it is pretty obvious that pulls from pypi are overwhelmingly happening during weekdays, which tends to confirm the idea that people use this package at work.

Let's discuss this on this issue, and hopefully find a way to make this work for everyone.

[conceptofmind]

Would it make sense to set up GitHub sponsors for this project? That way, people can donate to you for maintenance.

[Rested]

improve the release process so that community contributions can be pushed to pypi with very little effort

@laurentS i think this is the main issue for me with helping out in maintenance as reviewing a PR is a fairly discrete activity which i can be tempted to do in free time, but to see it to completion with a release branch and it making it to pypi makes it feel like it could drag out and occupy some mind space for a while which would be painful for both yourself (checking if the release make sense, whats in it, finding time to do it etc) and the approving maintainer (seeing it to completion), and contributor (if it takes a long time to make it to upstream maybe just pointing to a fork is better).

Think @conceptofmind suggestion is a good shout.

WDYT about a pypi org which you can add other maintainers to but keep it under your gh name with sponsors open?

[No767]

I actually implemented a fully async version, but only for my own personal needs. I'm totally down to help

[laurentS]

@No767 this is really cool! Would you be willing to open a PR here with your changes? I'm going to try to get back into maintaining this project better than I have recently, but having more maintainers onboard would be great!

[No767]

@laurentS I definitely will once I have the time to do so

[No767]

This probably might need to be moved into a separate thread, but as this codebase is slightly outdated from modern tooling, I would like to get a foundation set for that.

1. Proper modern tooling The goal of this rationale is to modernize our tooling and make it easier for long-term maintenance. Thus, we can utilize uv both for an increased developer performance and for packaging (as uv's backend build has now been considered stable). With uv, we can make the release process extremely easy, and reduce the amount of tooling that would be necessary. In addition, ruff should be also utilized to replace both black and isort, and pyright should be used instead as pyright is the industry standard for type checking these days (it's also used under the hood with pylance on VSC).

2. Going full async I've actually already rewritten this in a private project separately, but it heavily modifies the existing code. What I would suggest is to rewrite the core of the logic to use async calls, but within the decorator, the existing logic for detecting whether it would be async or sync can be left in place. If the endpoint is in fact sync, then we can just send it to it's own thread through loop.run_in_executor so we are not blocking the event loop.

3. Dependency injection structure As noted before, the idea of rewriting the system to use a dependency injection structure would be nice. I do want to keep the current decorator structure for now to not break existing code, but slowly move away from it and use a dependency injection structure instead.

4. Moving this to an org I like this idea, as this gives control over how operations are managed and allows for smooth maintainer handoff. This would be nice tbh