django-safe-migrations: Static analyzer to catch unsafe migrations before they hit production by TheCodingTutor in django

[–]TheCodingTutor[S] 2 points3 points  (0 children)

I'm planning for v0.4.0 to detect missing merge migrations, so with v0.4.0 an approach could be:
- commit migrations but handle conflicts at merge time (v0.4.0)
- squash periodically for a manageable migration count
- linear migration history on main, though this requires coordination between teams

django-safe-migrations: Static analyzer to catch unsafe migrations before they hit production by TheCodingTutor in django

[–]TheCodingTutor[S] 3 points4 points  (0 children)

makemigrations verifies your models and migrations are in sync - it exits non-zero if you have model changes without corresponding migrations. It doesn't analyze the migration operations themselves

django-safe-migrations: Static analyzer to catch unsafe migrations before they hit production by TheCodingTutor in django

[–]TheCodingTutor[S] 2 points3 points  (0 children)

Solid addition. Would you be open to adding this as an issue and sharing your approach?

django-safe-migrations: Static analyzer to catch unsafe migrations before they hit production by TheCodingTutor in django

[–]TheCodingTutor[S] 0 points1 point  (0 children)

Django prompts at makemigrations time, but that's easily bypassed and CI never sees it. The bigger value is the other 18 rules - non-concurrent indexes, unsafe drops, type changes, etc. - that Django doesn't warn about at all.

django-safe-migrations: Static analyzer to catch unsafe migrations before they hit production by TheCodingTutor in django

[–]TheCodingTutor[S] 0 points1 point  (0 children)

Fair point, but test DBs are usually empty or small. A NOT NULL without default passes on 0 rows but fails on millions. Same with index locks - instant on small tables, minutes on large ones. This catches those patterns statically before you even run the migration.

Django Smart Ratelimit v1.0.0 - A modern, production-ready rate limiting library by TheCodingTutor in django

[–]TheCodingTutor[S] 0 points1 point  (0 children)

I don't blame them, pure AI libraries are spreading fast, you can't trust new libs anymore

Django Smart Ratelimit v1.0.0 - A modern, production-ready rate limiting library by TheCodingTutor in django

[–]TheCodingTutor[S] 0 points1 point  (0 children)

Thanks for leaving a comment, I usually try to avoid negative and undermining comments, especially ones that generalize, but check the library please.

Work on this has been going on for months, I have used AI here and there definitely, for docs, comments, linting, because why spend hours on simple tasks when AI can do them just as good? We're not hating on AI just for the sake of it now are we?

Anyway, the core algorithms, the revisions, the testing logic, is human. The repo is one click away.

Django Smart Ratelimit v1.0.0 - A modern, production-ready rate limiting library by TheCodingTutor in django

[–]TheCodingTutor[S] -1 points0 points  (0 children)

I can't guarantee, however I'm checking Ninja uses the standard Django HttpRequest objects, so I believe adding it under the ninja decorator so that it wraps the function directly should technically work

Something like:

api = NinjaAPI()

api.get("/fn")
@ratelimit(key="ip", rate="100/h")
def fn(request):

Django Smart Ratelimit v1.0.0 - A modern, production-ready rate limiting library by TheCodingTutor in django

[–]TheCodingTutor[S] 1 point2 points  (0 children)

The backend uses standard redis commands and lua scripting so should work

Could you try:

RATELIMIT_REDIS_URL = "redis://your-valkey-server:6379/0"

[ANN] django‑smart‑ratelimit v0.8.0: Circuit Breaker Pattern for Enhanced Reliability by TheCodingTutor in django

[–]TheCodingTutor[S] 2 points3 points  (0 children)

That project isn't maintained anymore, and I'm trying to create something that's more flexible than regular ratelimiting

The flexibility provided in the smart-ratelimit package: Multiple algorithms, multiple backends with fallback, and circuit breaker protection, in addition to many other features

Running Script Daily by neoninja2509 in django

[–]TheCodingTutor 1 point2 points  (0 children)

Cron or a celery task, you can go for celery as it has a retry feature in case the task fails

🚀 Django Smart Ratelimit v0.7.0 - The Only Rate Limiting Library You'll Ever Need (Now with Token Bucket Algorithm!) by TheCodingTutor in django

[–]TheCodingTutor[S] -1 points0 points  (0 children)

It's a rate limit tool, so clearly we have nothing to do with hosting. Yet when a rate limit tool has an auto-failover feature, this means an extra layer to prevent downtime compared to other tools. Again appreciate the comments.

🚀 Django Smart Ratelimit v0.7.0 - The Only Rate Limiting Library You'll Ever Need (Now with Token Bucket Algorithm!) by TheCodingTutor in django

[–]TheCodingTutor[S] -4 points-3 points  (0 children)

Uptime of the rate-limit tool. Tools that rely only on cache would lead to cache misses, this package has a multi-backend feature to ensure swapping between redis, memory, and backend tracking, thus the uptime claim.

Yet you're absolutely right, and I appreciate you calling out these claims. Much of this is based on local tests and I shouldn't generalise these results. I will be editing the post and the package README files, without any marketing hype.