Django REST Framework: CBVs vs FBVs for Scalable APIs

Devlog Day 30 Today I revisited a question "Two Sum II" which is a very simple problem until you know the approach. The difference between Two Sum and Two Sum II is in Two Sum II the array is sorted and you have to solve the problem with O(n) TC and O(1) SC. Using two pointer approach you can solve this question. In brute force we use nested loops which loops through entire array to check if the sum of nums[i] and nums[j] equals to target. Else continue. It takes O(n2) TC and O(1) SC as we are not using any extra space for solution. In better approach we use two pointers by taking advantage of sorted order of array. We start from first and last pointer and check if the sum of them equals to target. If the sum is less we move left pointer else right. The problem in itself is not that hard but I am started analysing the pattern of such questions like if you have sorted array and want to find any element or perform any operation it is most likely targetting binary search and two pointers. Anyways later I continued my django course and today I learnt static files handling when your code is in production and even wrote a command script. Django lets you write your own command and you can access that command using python manage.py <command_name>. It really helps when you are containerizing your code and want to automate some processes like fetching static files from third party cdn and load it in locally so you dont have to request api for every reload. #DevLog #BuildInPublic #DSA #NeetCode #Stack #LearningInPublic #IndieHacker #WebDevelopment #Django #Coding #Development #Explore

API Documentation in Django REST Framework — Simplified with drf‑spectacular Building APIs is easy. Maintaining them at scale? That’s where things get tricky. As teams grow and endpoints multiply, keeping a clear API contract becomes essential. That’s why I explored drf‑spectacular, a powerful tool that turns your DRF code into a clean, OpenAPI‑compliant schema — ready for Swagger and Redoc. In my latest Medium article, I break down: How to set up drf‑spectacular in minutes Why schema generation matters for scaling and collaboration Integrating JWT authentication for secure testing Hiding internal endpoints and documenting complex responses Best practices for production‑ready API docs Think of it as reverse‑engineering your API into documentation. 👉 Read the full article here: https://lnkd.in/dbuTaNym #Django #DRF #API #Documentation #OpenAPI #Swagger #Redoc #Python #BackendDevelopment

Day 28/90 I solved one LeetCode in four different ways, but my Django project stayed at zero today. I took April 2nd off for personal reasons. Yesterday, Day 28, I finished my DSA session, but I couldn't get started on the development work. I am converting my Sunday rest day into a working day again to make up for the lost time. DSA & LeetCode: • Solved LeetCode 268 (Missing Number). • I deliberately started with a Sorting approach. By sorting the array, I could see exactly where the index and the value stopped matching. It’s a simple way to find the gap, but the O(n log n) time complexity is slow for bigger arrays. • Next, I optimized it by using a Set for hashing. Turning the list into a Set gave me O(1) lookups and dropped the total time to O(n). It’s faster, but it still carries an O(n) space cost. • Then, I tried the Summation (Gauss Formula) method. I calculated the expected sum using (n * (n + 1)) // 2, where n is the length of the nums array, and subtracted the actual sum. This hit a 0ms runtime and O(1) space. • Finally, I used the Bitwise Exclusive OR method. Since any number XORed with itself cancels out (a ^ a = 0), I XORed every index from 0 to n with every value in the array. The pairs cancelled each other out, leaving only the missing number. It’s O(n) time and a perfect O(1) space, and unlike the math formula, it doesn't risk an integer overflow. Do you find value in solving the same problem multiple ways to understand trade-offs, or do you prefer moving quickly to the next challenge? #python #django #backenddevelopment #leetcode #dsa #90daysofcode #softwareengineering #bitwise #refactoring #consistency

Day 3 of #TDD_Series_Django Most testing frameworks need hours of configuration. Django? Zero setup. Everything is built in. Ready from day one. With Django you get: ✅ Run tests with one command ✅ Separate test database ✅ Auto reset between tests ✅ Test client (no server needed) ✅ Auth simulation out of the box Sounds simple… but it's powerful. Because it enforces one thing: test isolation No shared state. No random failures. No surprises. That’s what makes tests reliable. Tomorrow: the folder structure mistake that makes your tests silently disappear 👀 Do you use Django testing or pytest? 👇 #Python #Django #TDD #WebDevelopment #TDDWithDjango #Day3

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

Decoupling logic in Django is always an interesting architectural challenge. Recently, I’ve been relying more on Django Signals to keep my models clean and enforce a strict separation of concerns. For those who haven't dug into how they work under the hood: Django signals essentially implement the Observer design pattern. There is a central dispatcher, when a specific action occurs in the application (the sender), the dispatcher routes that event to any function "listening" for it (the receiver), allowing them to execute their own logic independently. In the snippet below, I’m using the post_save signal. Whenever a new Student instance is successfully created, this receiver catches the signal and automatically generates a CreditWallet for them. Why use a signal here instead of just overriding the save() method on the Student model? It comes down to encapsulation. Overriding save() works fine for simple apps, but as a project grows, it can lead to massive, bloated models. By using signals, the Student model remains strictly responsible for student data, while the financial/wallet logic is encapsulated in its own domain. It makes the codebase much easier to maintain, scale, and test. I’m curious to hear from other developers on here: What is the most complex, creative, or technically challenging way you have utilized Django signals in a project? I'd love to learn from your experiences! #Django #Python #SoftwareEngineering #WebDevelopment #Architecture #Coding

Django vs FastAPI is not a debate. It's a use case question. Django when you need: Admin panel out of the box ORM, auth, migrations all bundled A monolith that ships fast A team that doesn't want to wire things together FastAPI when you need: High throughput async APIs Full control over every layer ML model serving or agentic backends Type safety and auto docs without extra setup Django is a framework that makes decisions for you. FastAPI is a framework that trusts you to make them. Neither is better. Wrong tool for the job is the only mistake. #Python #Django #FastAPI #BackendDevelopment #SoftwareEngineering

Most beginner backend projects die in refactoring. Here's the structure I use to prevent that. When I built my Task Manager CLI, I learned this the hard way — a monolithic file that worked until it very much didn't. After refactoring, here's the structure I now start with: Before writing a single line: → Define your data model first → Identify all operations (CRUD) you'll need → Map inputs, outputs, and error states While building: → One module per concern (routes, models, utils, exceptions) → Validate inputs at the boundary — not deep inside logic → Handle errors explicitly — no silent failures Before shipping: → Test the unhappy paths, not just the happy ones → Read your own code like a stranger would This approach reduced my debugging effort by 40% on a real project. It works at any scale — from a CLI tool to a FastAPI service. What's the first thing you do when starting a new backend project? #BackendDevelopment #Python #FastAPI #SoftwareEngineering #CodingTips

🔧 Django REST Framework Serializers — the unsung heroes of your API If you've worked with DRF, you know serializers are more than just "JSON converters." They're the gatekeepers of your entire data layer. Here's what makes them genuinely powerful: 1) Validation built-in — field-level and object-level validation in one place. No extra form logic, no scattered checks. 2) Nested relationships — serialize related models automatically, or override with custom logic when you need it. 3) Read/write separation — use read_only / write_only fields cleanly, without duplicating code. 4) ModelSerializer — auto-generates fields from your model. Less boilerplate, faster iteration. 5) SerializerMethodField — add any computed property to your API response without touching the model. One underrated pattern: using serializers for input validation outside of views — in Celery tasks, management commands, anywhere you're ingesting untrusted data. Serializers are where your API contract actually lives. Treat them with the same care you'd give your models. What's your go-to serializer trick? Comment below! #Django #DRF #Python #BackendDevelopment #WebDevelopment #SoftwareEngineering

#The_most_expensive_comma_I’ve_ever_typed. 💸 I recently spent way too long debugging a background task that was "failing successfully." No errors in the frontend, no crashes in the logs—just... silence. The culprit? A single trailing comma at the end of a string: #email_body = "Hello there...", In Python, that tiny comma turns your intended String into a Tuple. So, instead of sending a block of text to the email handler, I was sending ("Hello there...",). Because we had fail_silently=True enabled in our background thread (standard practice to keep the UI snappy), the system was quietly choking on the Tuple and dying without a word. #The Lesson: Syntax Matters: Even in a "readable" language like Python, one character changes the entire data structure. The Danger of Silence: fail_silently is a double-edged sword. It keeps the user experience smooth, but it can bury the "why" during development. Log Everything: If it’s failing silently, make sure your logger isn’t! Has a single character ever brought down your entire workflow? Let’s commiserate in the comments. 👇 #Python #SoftwareEngineering #CodingLife #Debugging #Django #WebDevelopment