Django Ninja vs DRF: Is the Boilerplate Argument Dead?

A while back I was working on a document management feature. Users could create documents, but naturally they should only be able to edit or delete their own. Managers, on the other hand, needed broader access so they could edit any document within their department. And then there were reports that had to be publicly readable by anyone, even without logging in. Django’s built-in permissions work well when things are global, like saying “managers can edit all documents”. But the moment you step into real-world rules like “this user can only edit their own documents” or “this specific person can access this one record”, you end up writing custom checks everywhere. It quickly becomes repetitive and a bit fragile. I kept running into the same problems, so I wanted something cleaner and reusable for: - Per-object permissions for individual records - Automatic ownership rules (users managing their own content) - Public access for specific endpoints without authentication - DRF action mapping so permissions are consistent across endpoints - Permission caching to avoid unnecessary database hits on every request Yes, django-guardian exists – but it's heavy and requires extra wiring for DRF. I wanted something lighter, DRF‑native, and drop‑dead simple. That is what led me to build django-user-permissions, a lightweight package that plugs into Django REST Framework. It gives you a simple mixin for viewsets, a way to attach permissions directly to objects, and a few controls for ownership and public access. The idea was not to build another heavy role system, but to fill in the gaps Django leaves at the object level. If you have ever had to implement “edit only your own posts” or “share a single private document with someone”, you probably know how quickly this logic spreads across a codebase. This is just my attempt to keep that part of Django a bit more manageable. 📦 PyPI: [https://lnkd.in/gR63kZdB) 💻 GitHub: https://lnkd.in/geSY5Mfj pip install django-user-permissions #Django #DRF #Python #OpenSource #Permissions

I kept writing Django APIs… but something felt off. The code was working. Responses were coming. But if someone asked me: 👉 “What actually happens when a request hits your API?” …I didn’t have a clear answer. That bothered me. So I went back to basics. Not tutorials. Not copying code. Just understanding one simple flow: User → request → view → model → database → response And suddenly, things started clicking: Patient.objects.all() is not just a line of code… it’s a query hitting the database and returning structured data. request is not just a parameter… it’s literally everything the user is sending to your backend. GET, POST, PUT, DELETE are not just methods… they define how your system behaves. The biggest realization? 👉 I was focusing on “how to write code” 👉 instead of “how things actually work” Now I approach backend differently: I don’t start with code. I start with flow. And that small shift is making a huge difference. Still learning. But now it feels real. #Django #BackendDevelopment #Python #LearningInPublic #SoftwareEngineering #BuildInPublic

This Django + Celery bug has silently corrupted data in more production apps than you think. And most engineers don't even know they're hitting it. Here's the scenario. User registers. You fire a Celery task to send a welcome email. task = send_welcome_email.delay(user.pk) Looks fine. Works in dev. Works in staging. Then in production — random users never get their email. No errors. No exceptions. Task succeeds. Email just... doesn't send. The bug? Your Celery task ran before Django committed the transaction to the database. The task woke up, queried User.objects.get(pk=user.pk) — and the user didn't exist yet. This is the classic Django + Celery race condition. It's been silently wrecking production apps for years. The old fix was ugly: transaction.on_commit(lambda: send_welcome_email.delay(user.pk)) It worked. But it was boilerplate you had to remember everywhere. Celery 5.4 shipped a proper fix — .delay_on_commit(): send_welcome_email.delay_on_commit(user.pk) One method. Zero boilerplate. Task only fires after the DB transaction commits. Race condition gone. I hit this on a large-scale project handling thousands of user signups. Switched every task trigger to .delay_on_commit() and the ghost failures disappeared overnight. If you're using Celery with Django and still calling .delay() directly in views — check your logs. You might be losing tasks you don't know about. Drop a comment if this has burned you before. I know I'm not the only one. 👇 #Django #Celery #Python #BackendEngineering #DjangoTips #WebDevelopment #BuildingInPublic #SoftwareEngineering

FastAPI vs Django: Which Wins in 2026? The best framework isn’t the one with the most features—it’s the one that solves your specific bottleneck. If you’re choosing for your next project, here’s a breakdown: Why the industry is shifting to FastAPI - Performance: Built on Starlette and Pydantic, it’s one of the fastest Python - - frameworks. Ideal for high-concurrency or I/O-bound tasks. - Developer velocity: Automatic OpenAPI (Swagger) docs and Python type hints reduce time spent on documentation. - Modern stack: Designed for microservices, AI/ML deployments, and modern frontends like React or Next.js. Why Django isn’t going anywhere - Batteries included: Comes with admin panel, authentication, and ORM out of the box. - Security: Built-in protection against common web vulnerabilities. - Stability: Strong structure for large-scale monoliths and enterprise applications. The verdict Use FastAPI if you want a high-performance engine for modern APIs or microservices. Use Django if you need a fully equipped framework for complex, data-heavy applications. Which side are you on? Are we moving toward a “FastAPI-first” world, or does Django’s ecosystem still reign supreme? #Python #WebDevelopment #FastAPI #Django #SoftwareEngineering #Backend #CodingTips

I once spent three days trying to optimize a high-concurrency data pipeline in Django, only to realize I was fighting the framework’s architecture, not the problem. Last week, on a client project involving real-time sensor data, we hit a wall where Django’s ORM and sync nature couldn't keep up with the throughput requirements. The lesson? Pick your Python weapon based on the job, not just what you know best. Django is unbeatable for complex admin panels, strict schema management, and rapid prototyping. It gives you the "batteries included" safety net that lets you ship features instead of building boilerplate. FastAPI, on the other hand, is for when you need to squeeze out every drop of performance. Its asynchronous nature is a massive win for I/O-bound tasks and heavy WebSocket integration. If you’re building a CRUD-heavy enterprise dashboard, stick with Django. If you’re building a high-scale microservice that needs to handle thousands of concurrent requests, move to FastAPI. Don't force a monolith into a microservice’s shoes. What’s the one project where you swapped backends midway because the first choice didn't scale? #Python #SoftwareEngineering #Django #FastAPI #SystemDesign

If you’ve ever built APIs in Django REST Framework, you know the pain of writing multiple views for the same model — list, detail, create, update, delete. Messy, repetitive, and error-prone. That’s where ViewSets come in. With just a few lines of code, you get all CRUD endpoints automatically, clean URL routing, and a scalable request flow. In my latest Medium article, I break down: What ViewSets are and why they matter How to secure your APIs with get_queryset() Performance boosts using prefetch_related Query parameter filtering with filter_backends Custom endpoints with @action (like cancel or recent orders) Common mistakes to avoid (permissions, redundant filtering, lost prefetch) This isn’t just about making APIs that “work” — it’s about building APIs that are secure, efficient, and production-ready. 👉 Read the full guide here: https://lnkd.in/diM6UCiZ #Django #RESTAPI #Python #BackendDevelopment #SoftwareEngineering #APIs

🎭 #The_"#Translator_Who_Tries_Too_Hard": #Understanding #SerializerMethodField: Ever built a Django API and realized your database model is a bit… boring? You have a first_name and a last_name, but your frontend developer is begging for a full_name or a is_vibe_check_passed field that doesn't actually exist in your SQL table. Enter the SerializerMethodField. In the world of Django Rest Framework (DRF), this field is like that one friend who refuses to just repeat what they heard and instead adds their own "flavour" to the story. 🛠️ How it Works When you define a field as a SerializerMethodField(), you are telling Django: "Hey, don't look for this in the database. I’m going to write a custom function to calculate this on the fly." 👨🍳 The Recipe Define the field: Add it to your serializer class. The "Get" Magic: Create a method named get_<field_name>. The Logic: Do your math, string concatenation, or soul-searching inside that method. Python class UserSerializer(serializers.ModelSerializer): days_since_joined = serializers.SerializerMethodField() class Meta: model = User fields = ['username', 'days_since_joined'] def get_days_since_joined(self, obj): # 'obj' is the actual model instance return (timezone.now() - obj.date_joined).days ⚠️ The Catch (Read: Why your Senior Dev is frowning) While powerful, SerializerMethodField is read-only. You can't POST data back to it. Also, if you use it to run heavy database queries for every single item in a list of 1,000 objects, your API performance will disappear faster than free pizza in a tech office. 🍕💨 TL;DR: Use it when you need to transform raw data into something useful for the frontend, but use it sparingly to keep those response times snappy! 🚀 #Django #Python #WebDevelopment #DRF #BackendTips #CodingHumor

Your API isn’t slow — your pagination might be. 📉 It worked perfectly… until your data grew. Then every page got slower than the last. Your code didn’t change. But your dataset did. The culprit? Offset pagination. The deeper the page, the more rows your database has to scan and skip. Page 1 → fast Page 1000 → painful Same query shape. Very different cost. The fix isn’t always caching. Sometimes it’s changing the pattern. Switch to cursor-based pagination. No skipping. Just seeking. In Django REST Framework: Use *CursorPagination* instead of *PageNumberPagination*. Performance stays consistent — even at scale. Because most performance issues aren’t complex. They’re patterns that don’t scale. And most developers don’t notice… until production. #BackendDevelopment #Django #Python #WebDevelopment #SoftwareEngineering #APIPerformance #DatabaseOptimization #SystemDesign #ScalableSystems #DjangoRESTFramework

Moving from the flexibility of Flask to the "Batteries-Included" power of Django! 🐍🔥 After spending significant time building with Flask, where I enjoyed the "build-it-from-scratch" approach, I decided to dive deep into Django today to see how it handles large-scale architectures. The transition is eye-opening! Here’s what I learned today while building a User Management System: ✅ The Architecture Shift: In Flask, I was used to manual setups for everything. Django’s "Batteries-Included" philosophy (like the built-in User model and Admin panel) is a massive time-saver for rapid development. ✅ From SQL/Manual JSON to Django ORM: I moved away from manual dictionary mapping to using Django’s ORM for JsonResponse. It’s interesting to see how User.objects.all() simplifies data retrieval. ✅ API-First Thinking: I bridged the gap between Backend and Frontend using the Fetch API. Instead of standard page redirects, I built a system where my Django backend serves JSON, and JavaScript handles the UI dynamically via Popups (Modals). ✅ The "Nickname" Logic: One thing I loved? Django’s URL names. In Flask, I’d often hardcode paths, but in Django, using name='user_list_link' makes the code so much more maintainable. The Verdict: Flask taught me how things work under the hood. Django is now showing me how to scale those concepts efficiently. #Python #Django #Flask #WebDevelopment #Backend #CodingJourney #SoftwareEngineering #LearningInPublic #SaaS

🚀 𝐃𝐚𝐲 𝟏: 𝐃𝐢𝐯𝐢𝐧𝐠 𝐢𝐧𝐭𝐨 𝐭𝐡𝐞 𝐒𝐩𝐞𝐞𝐝 𝐨𝐟 𝐅𝐚𝐬𝐭𝐀𝐏𝐈! ⚡ After building robust applications with Django and DRF, I’ve decided to level up my backend game. Today marks Day 1 of my journey into FastAPI, and I’m already blown away by its efficiency! Here’s a breakdown of what I explored today: 🔍 𝙒𝙝𝙖𝙩 𝙞𝙨 𝙁𝙖𝙨𝙩𝘼𝙋𝙄? It’s a modern, high-performance web framework for building APIs with Python, based on standard Python-type hints. It’s designed to be easy to use while being one of the fastest Python frameworks available. 🌟 𝙒𝙝𝙮 𝙩𝙝𝙚 𝙝𝙮𝙥𝙚? (𝘼𝙙𝙫𝙖𝙣𝙩𝙖𝙜𝙚𝙨) 𝗦𝗽𝗲𝗲𝗱: It’s on par with Node.js and Go, thanks to Starlette and Pydantic. 𝐀𝐮𝐭𝐨-𝐃𝐨𝐜𝐬: It generates Swagger UI and ReDoc automatically—no more manual API documentation! 𝐓𝐲𝐩𝐞 𝐒𝐚𝐟𝐞𝐭𝐲: Fewer bugs thanks to rigorous data validation. Asynchronous: Native support for async and await. 🏢 𝙒𝙝𝙤’𝙨 𝙪𝙨𝙞𝙣𝙜 𝙞𝙩? FastAPI isn't just a trend; industry giants like Microsoft, Uber, Netflix, and Tesla are leveraging it to power their services. Plus, the community is massive and growing every day! 📈 🛠️ 𝙏𝙚𝙘𝙝𝙣𝙞𝙘𝙖𝙡 𝙁𝙤𝙪𝙣𝙙𝙖𝙩𝙞𝙤𝙣𝙨 𝘾𝙤𝙫𝙚𝙧𝙚𝙙: 𝗧𝗵𝗲 𝗨𝘃𝗶𝗰𝗼𝗿𝗻 𝗦𝗲𝗿𝘃𝗲𝗿: Learned how this lightning-fast ASGI server keeps everything running. 𝐇𝐓𝐓𝐏 𝐌𝐞𝐭𝐡𝐨𝐝𝐬:Refreshed my knowledge on GET, POST, PUT, and DELETE in the context of FastAPI routes. 𝐓𝐡𝐞 𝐃𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧: Spent time exploring the official FastAPI docs and their GitHub repo—the DX (Developer Experience) is top-tier! I’m excited to see how my Django background helps me master this "fast" new world. Stay tuned for more updates! #Python #FastAPI #WebDevelopment #BackendDeveloper #CodingJourney #LearningEveryday #Django #SoftwareEngineering #TechCommunity