标签：#django

Link to the Source Code As a data engineer, I spend my days designing clean, optimized data structures. But at home, I face a much tougher crowd: my family. We manage our shared finances together to optimize our budget, and because of where we live and work, we have to do this in several different currencies (like USD, EUR, CZK, and UAH) Like any developer, I first tried to find a ready-made app to solve this. But I ran into a classic problem: they were either bloated with a million features we didn’t care about, or they were missing the exact features we actually needed. So, we did what any desperate family does: we opened a Google Sheet . We tracked our money there for a while, not because it was perfect, but because it helped us figure out what we actually needed from a real application. It was our "living schema design" before I wrote a single line of code. In this article, I want to show you how I looked at this problem from two sides—as a frustrated user who just wants to log expenses, and as a data engineer obsessed with clean database design. Here is the story of how I built our custom home accounting server. Part 1: Django, a Star Schema, and the Framework Battle By 2025, I was ready to replace our Google Sheet. My main programming language is Python, so I had three realistic choices: FastAPI, Flask, or Django. FastAPI is the cool kid on the block for high-speed APIs, but we didn’t expect millions of requests (unless my family suddenly grew by a factor of a million). We also needed a friendly web UI, which FastAPI isn't naturally built for. I had just used Flask for my previous project, but I wanted to challenge myself and learn something new. Django felt like an old friend I hadn't seen in years. It has amazing built-in tools (like the admin panel and great translation support), and using it was the perfect way to refresh my skills and grow as a developer. The Database: Why a "Star Schema" Actually Makes Sense As a data engineer, I didn’t want a messy data

There is a layer in my database called 1 . Somebody created it, presumably by accident, and it sat there for months looking harmless. It was the only layer in the system that never served a single tile, and nobody noticed, because it was empty anyway. That layer turned out to be a symptom of a SQL injection vulnerability. This post is about the design that produced it — which I still think is a good design — and the four things I got wrong inside it. The setup A web GIS with about 2.7 million features: 1.8 million points, 697,000 lines, 172,000 polygons. Users create layers through the UI, upload data into them, edit geometry, and expect to see it on a map. The features do not live in a table per layer. They live in three tables — one for points, one for lines, one for polygons — with a layer_id foreign key and a JSON column for attributes: project_pointfeature 1,820,288 rows project_linefeature 697,009 rows project_polygonfeature 171,830 rows That's a deliberate trade. A table per layer means DDL every time a user clicks "new layer", a migration story that never ends, and a schema that drifts. Three generic tables mean one schema, one set of indexes, and layers that are just rows in a metadata table. The cost lands on the tile server. The pattern Martin serves vector tiles from PostGIS. Point it at a database and it discovers spatial tables and views and publishes each as an MVT endpoint. It can be told to publish views but not tables: postgres : auto_publish : from_schemas : [ public ] publish_tables : false reload_interval : 5s So: give every layer its own view. A Django post_save signal on the Layer model creates it: CREATE OR REPLACE VIEW t19_saobracajni_znakovi AS SELECT f . id , f . feature_attrs , f . geom , f . layer_id , l . name AS layer_name , lg . name AS layer_group_name , p . title AS project_title FROM project_pointfeature f JOIN project_layer l ON f . layer_id = l . id JOIN project_layergroup lg ON l . layer_group_id = lg . id JOIN project_project p

Python is a perfect language for Agile development, where requirements might change on the go. Especially if you are in a startup business, you will need to experiment and change things fast. However, Python is an interpreted language, and in certain situations you might need faster performance than what an interpreted language can provide. A common practice in these cases is using python-to-binary bindings, where the binary code is built with Rust, C++, or Go. In this article, I will explore bindings to Rust-based code. How do the bindings work The idea behind bindings is that you create a module with functions of a specific domain in a language that compiles to binary, and build it as a C-compatible dynamic library ( .so on Linux, .dylib on macOS, .dll on Windows). Then a Python wrapper is built as a Python package and installed together with the dynamic library, allowing you to import and use functions that pass control to the corresponding functions in the dynamic library. On some occasions, classes can be used instead of functions. If any parameters are complex, they must be serialized in the wrapper and passed to the dynamic library as a JSON string or as a set of individual primitive parameters. An experiment with benchmarks To try this Python-Rust communication, I vibe coded an experiment that reads a large CSV file and builds a new one with duplicates stripped out based on specified column indexes. In my test case, it was a 3 MB CSV file with data about European NGOs for the donation platform I am building, where I wanted to remove the NGOs that don't have website URLs listed. As benchmarked, the file was processed 4.3x faster with the Rust binding than directly with Python. Here is the repo to get a first glimpse into the code and structure. What is there to know about Rust A few things about Rust: Rust packages are built with Cargo, which is the equivalent of pip, virtualenv, and setuptools combined. A single package is called a crate, and it can be publi

The first time we deployed Celery to production on a client project, we thought we had done everything right. We had workers running, tasks queuing, and Redis as the broker. Six weeks later, the task queue was backed up with 40,000 unprocessed jobs, the workers had silently died, nobody knew, and a batch of client invoices had not been generated for two weeks. That was four years ago. Since then we have deployed Celery on dozens of projects and we have learned what actually goes wrong — not in development, where everything works, but in production, where things fail in ways you do not anticipate. This post covers the configuration and operational patterns we now use on every Celery deployment. Why tasks fail silently (and how to stop it) The most dangerous thing about Celery is how quietly it can fail. A worker process dies, the task queue fills up, and your application keeps accepting work and sending it to a queue that nobody is processing. No exception is raised. No alert fires. Users notice eventually, or you notice when a daily report does not arrive. The fix has two parts: monitoring and task acknowledgement configuration. Task acknowledgement By default, Celery acknowledges a task (removes it from the queue) as soon as a worker picks it up, before the task runs. If the worker dies mid-task, the task is lost. # celery.py app = Celery ( ' myproject ' ) app . conf . update ( # Only acknowledge after the task completes successfully task_acks_late = True , # If a worker dies, reject the task back to the queue task_reject_on_worker_lost = True , # Limit memory — workers that leak memory will restart cleanly worker_max_memory_per_child = 200_000 , # 200MB in KB # Limit tasks per child process to prevent long-running workers # from accumulating state worker_max_tasks_per_child = 1000 , ) With task_acks_late=True , a task that is picked up by a dying worker will be requeued and picked up by another worker. The task might run twice (more on that shortly), but it will n

Rate limiting is one of those features every production API eventually needs. Whether you're building a public REST API, a WebSocket service, or an authentication endpoint, you'll eventually face problems like: Credential stuffing Brute-force attacks API abuse Bots scraping your endpoints Unexpected traffic spikes Most applications solve this with a simple request counter. But after building several APIs with Django, FastAPI, and Flask, I realized that production traffic requires much more than "X requests per minute." That observation led me to build drogue , an open-source Python library for rate limiting and traffic protection. The Problem Traditional rate limiting is straightforward: Allow 100 requests per minute. This works well for many cases, but real-world applications quickly expose its limitations. For example: A distributed attack can remain below the per-IP limit. A bot can rotate through proxies. WebSocket connections often require different handling than HTTP requests. Different endpoints need different protection strategies. I wanted a system that could go beyond simple request counting. Design Goals From the beginning, I focused on a few principles. 1. Clean framework integration I didn't want endpoint functions filled with framework-specific plumbing. Instead, the library should feel like a natural extension of the framework. from fastapi import FastAPI from drogue.adapters.fastapi import DrogueLimiter app = FastAPI () limiter = DrogueLimiter ( app , default_limits = [ " 100/minute " ]) @app.get ( " /users " ) @limiter.limit ( " 10/minute " ) async def users (): return { " status " : " ok " } No additional request objects. No complicated middleware configuration. Minimal boilerplate. Multiple Rate Limiting Algorithms Different applications require different algorithms. Instead of supporting only one approach, drogue includes multiple options: Token Bucket Sliding Window Fixed Window Each has different trade-offs between accuracy, burst handling, and

As part of my learning journey with Django, I wanted to build a project that would challenge me beyond the basics. I decided to create RecipeHub, a web application where users can create, manage, and share recipes while exploring recipes from other users. The project started from a Django starter template, but I customized it by adding new features, redesigning the interface, and deploying it online. Features RecipeHub allows users to: Register and log in Create, edit, and delete recipes Browse recipes by category Save favourite recipes Upload recipe images Access a personal dashboard Use the application in both light and dark mode The application is fully responsive, making it easy to use on both desktop and mobile devices. Technologies Used I built the project using: Python Django Django Allauth PostgreSQL Tailwind CSS DaisyUI HTMX Vite Gunicorn Render GitHub was used for version control throughout the project. Challenges One of the biggest challenges was deployment. While everything worked locally, deploying to Render required configuring PostgreSQL, environment variables, and static files correctly. I also encountered an issue with uploaded recipe images. Since the application is hosted on Render's free tier, uploaded media is stored on an ephemeral filesystem, meaning uploaded images are lost after redeployment. Learning why this happens gave me a better understanding of the difference between development and production environments. Another challenge was redesigning the dashboards. I wanted them to feel clean and modern instead of looking like a default Django application, so I spent time improving the layout, spacing, and responsiveness. What I Learned This project helped me improve my understanding of: Django project structure Authentication and user management CRUD operations Database relationships Responsive UI design Git and GitHub workflows Deploying Django applications Debugging real-world issues More importantly, it taught me how to troubleshoot proble

Over the past few months, I've been exploring how AI can move beyond chatbots and become an active part of business workflows. That journey led me to build SmartStock AI , an inventory management platform that combines modern web technologies with AI agents, Retrieval-Augmented Generation (RAG), demand forecasting, and automation. Instead of only tracking inventory, SmartStock AI helps businesses make proactive decisions. What SmartStock AI Can Do 🤖 Forecast future product demand 📦 Recommend purchasing decisions through AI agents 📚 Answer inventory-related questions using Hybrid RAG with source citations 📄 Process invoices using multimodal AI ⚡ Generate real-time inventory alerts 🔐 Secure the platform with JWT authentication and role-based access control Technology Stack Frontend React 19 Backend Django 5 Django REST Framework Database PostgreSQL pgvector AI LangChain Hybrid RAG AI Agents Prophet Forecasting Infrastructure Celery Redis Docker GitHub Actions What I Learned Building SmartStock AI taught me much more than integrating an LLM into an application. Some of the biggest lessons were: Designing AI features that solve real business problems. Building reliable agent workflows instead of simple chatbot interactions. Combining vector search with structured database queries. Managing asynchronous AI tasks using Celery and Redis. Creating production-ready APIs with Django REST Framework. Deploying and maintaining a modern full-stack application. Demo 🎥 YouTube Demo https://www.youtube.com/watch?v=DQJqs6bgE98 🌐 Live Demo https://smart-stock-dev.vercel.app/ Demo Account Email: viewer@smartstock.ai Password: Viewer123! 💻 GitHub Repository https://github.com/Eng-Ayman-Mohamed/SmartStock-AI Final Thoughts This project was developed as my graduation project during the Information Technology Institute (ITI) Full Stack Web & Generative AI Program. It was an incredible opportunity to explore AI engineering, backend architecture, and modern software development while buildin

In today's world where websites and web applications play a very important role in businesses, choosing the right tool for developing a project is of great importance. Developers usually use frameworks to build websites faster, more securely, and more professionally. One of the most powerful and popular web development frameworks is Django . Django is a powerful and open-source web framework built with the Python programming language that allows developers to create complex and professional websites and web applications in a short amount of time. From simple websites to large systems, online stores, social networks, admin panels, and professional APIs — all can be developed with Django . In this article, we will thoroughly examine what Django is, why it has become popular, what its use cases are, and why many developers and large companies use it. What is a Framework? Before we get to know Django , it's better to understand the concept of a framework. A framework is a collection of pre-built tools, libraries, and rules that help developers build software faster and with better structure. In the past, developers had to create many features from scratch; for example: User login system Database connection Request management Application security Page structure File management But by using a framework, many of these capabilities are already prepared, and the developer can focus on the core logic of the project. Simply put, a framework is like a ready-made skeleton for building software that increases the speed and quality of development. What is Django? Django is a server-side (backend) web development framework written in Python . This framework is designed for building web applications and provides developers with many features by default. The main goal of Django is to make web development faster, more secure, more organized, and more scalable. Django's official slogan: The web framework for perfectionists with deadlines This slogan indicates that Django was built for

Every application we use today—from banking apps to social media platforms—has something working behind the scenes. That hidden engine is called the backend. The backend is responsible for processing requests, storing data, handling authentication, enforcing business rules, and ensuring everything works as expected when users interact with an application. One of the first decisions backend developers make is choosing a framework. A framework provides the tools, structure, and best practices needed to build applications faster and more securely. Today, let's look at three popular backend frameworks: Django, Gin, and Ruby on Rails. Django (Python) Django is one of the most mature and feature-rich backend frameworks available. Built using Python, it follows the philosophy of "batteries included." This means many features developers need are already built into the framework, including: User authentication Admin dashboard Database ORM Security protections URL routing Form validation Because so much comes ready to use, developers can spend more time solving business problems instead of rebuilding common features. Best for: Content management systems E-learning platforms Business applications APIs Startups building products quickly Advantages: Fast development Excellent security features Large community Extensive documentation Scales well for many applications Trade-offs: The framework includes many components, so it can feel heavier than minimalist frameworks. Gin (Go) Gin is a lightweight web framework built for the Go programming language. Unlike Django, Gin keeps things minimal. It gives developers speed and flexibility while letting them choose many of the additional tools they want to use. One reason many developers enjoy Gin is its impressive performance. Since Go is a compiled language designed for concurrency, Gin can efficiently handle many requests simultaneously while using relatively few system resources. Best for: REST APIs Microservices High-performance syst

We built our first "multi-agent system" by accident. What started as a single agent that could research a topic, draft a report, check it against source data, and send a summary email had grown into a 2,000-token system prompt and a function list so long that the model kept forgetting tools existed. It wasn't a system — it was a monolith pretending to be intelligent. Breaking it apart into coordinated agents fixed most of the problems. It also introduced a new category of problems we hadn't thought about. Here's what we actually learned. When One Agent Is Enough (and When It Isn't) The temptation to add more agents is real, but the overhead isn't free. Every agent boundary you add is a place where context can get lost, latency increases, and errors compound. One agent is the right call when: The task fits in a single LLM context window without crowding The steps are sequential and each depends heavily on the prior output You need tight reasoning across all the information (summarising a document, for example) You need multiple agents when: A single agent's context window is being maxed out with tool definitions, history, or data Different steps require genuinely different "personas" or instruction sets (research vs. writing vs. fact-checking) Steps can run in parallel and the latency saving matters You want to isolate failure — if the data extraction agent fails, the report-writing agent shouldn't be affected The key question we ask: Is this one job or a pipeline of jobs? If you'd describe it to a human as "first do X, then Y takes that and does Z", you probably have a pipeline, not a single task. The Three Patterns We Actually Use 1. Supervisor-Worker A thin orchestrator agent decides what needs doing, dispatches to specialised worker agents, and stitches the results together. The workers are narrow — they do one thing and don't need to know about the rest of the workflow. This is our most common pattern. The supervisor's system prompt stays small because it's rout

The Problem: Feature Velocity Was Creating Structural Debt The system originally started as a simple feature delivery backend: A Django API powering agricultural insights Celery workers handling asynchronous processing Independent endpoints for each new capability A growing set of Earth Observation computations (NDVI, NDWI, etc.) At first, it worked. But as more features were added, a pattern emerged: Each feature introduced its own pipeline logic Observability was inconsistent across services API contracts drifted between frontend and backend Debugging required tracing multiple disconnected systems We weren’t scaling functionality. We were scaling fragmentation. The Turning Point: Features vs Platforms The key realization was simple: Features solve user problems. Platforms solve system problems. We were repeatedly rebuilding: Authentication flows Data ingestion logic Processing pipelines API validation layers Monitoring hooks Each feature was solving its own version of these concerns. That is where platform engineering became necessary. The Shift: Introducing a Platform Layer We introduced a platform layer between feature delivery and infrastructure. Instead of building isolated pipelines, we standardized: 1. Unified API Surface All Earth Observation workflows (NDVI, NDWI, and future indices) were normalized into a consistent API contract. Shared request/response structure Versioned endpoints Schema validation through serializers Central routing logic This eliminated endpoint fragmentation. 2. Standardized Processing Pipeline Celery tasks were refactored into a reusable pipeline pattern: Ingestion Validation Computation Storage Publishing Instead of feature-specific workers, we moved toward composable tasks. This allowed new indices or processing logic to plug into the same execution flow. 3. Observability as a First-Class Layer One of the biggest failures in the original system was visibility. We introduced: Structured logging across all services Traceable job IDs

The real question isn't which framework is better. It's which one you can stop thinking about six months into the project. Key Takeaways Project Suitability — Django is built for weight. Flask is built for speed. Know which one your project actually needs before you commit. Development Flexibility — Django makes decisions so your team doesn't have to. Flask hands those decisions back. Both are features, depending on who's writing the code. Scalability & Performance — Scaling is an architecture problem first, a framework problem second. Pick the one that matches the system you're building — not the one you hope to build. Security Features — Django's protections are on by default. Flask's require you to turn them on. In a fast-moving team, that difference is more significant than it sounds. Ecosystem & Community — Both communities are active and well-documented. You won't be stuck either way. The Decision Nobody Takes Seriously Enough I've watched this play out more times than I'd like to count. A team kicks off a Python project, someone picks a framework — usually the one the most senior person knows best — and everyone moves on. Fast forward six months and the codebase is exhausting to work in. Either they're dragging a full framework through a service that should've been twenty lines of Flask, or they're rebuilding authentication from scratch on something that outgrew its lightweight origins two sprints in. The framework choice isn't irreversible. But undoing it mid-project is expensive in a way that doesn't show up in any estimate. Django and Flask are both genuinely good. What they're good for is different. That's the part worth slowing down on. What You're Actually Getting With Each One Django arrives with almost everything a web application needs already assembled — an ORM, an admin panel, authentication, form handling, CSRF protection, and more. The design assumption is that most web applications need most of these things, so it makes more sense to ship them i

Building a Real-Time Chat Feature with Django Channels and React Real-time features have become table stakes for modern web applications. Whether it is a customer support widget, a collaborative tool, or a social platform, users expect instant communication without page refreshes. In this article, I will walk through how we built a production-ready real-time chat feature using Django Channels and React at UCDREAMS. Why Django Channels? Django is traditionally synchronous. It handles one request at a time per worker. This works fine for standard HTTP requests, but WebSocket connections require persistent, bidirectional communication. Django Channels extends Django to handle WebSockets, background tasks, and asynchronous protocols alongside traditional HTTP. The beauty of Channels is that it does not replace Django. It layers on top, letting you keep your existing models, ORM, authentication, and admin panel while adding real-time capabilities. For a team already invested in Django, this is a massive advantage over introducing an entirely separate real-time server. Setting Up the Backend Start by installing Django Channels and a channel layer. Redis is the recommended backend for production use: channels == 4.0 . 0 channels - redis == 4.2 . 0 daphne == 4.0 . 0 Configure your Django settings: INSTALLED_APPS = [ ... " channels " , ] ASGI_APPLICATION = " your_project.asgi.application " CHANNEL_LAYERS = { " default " : { " BACKEND " : " channels_redis.core.RedisChannelLayer " , " CONFIG " : { " hosts " : [( " 127.0.0.1 " , 6379 )], }, }, } Building the WebSocket Consumer The consumer handles WebSocket connections: import json from channels.generic.websocket import AsyncWebsocketConsumer class ChatConsumer ( AsyncWebsocketConsumer ): async def connect ( self ): self . room_name = self . scope [ " url_route " ][ " kwargs " ][ " room_name " ] self . room_group_name = f " chat_ { self . room_name } " await self . channel_layer . group_add ( self . room_group_name , self . cha

PageSpeed Insights had been staring at me for weeks. Desktop was holding at 91. Mobile was stuck at 63. I'd already fixed the obvious stuff — non-blocking fonts, preconnects, fetchpriority on the hero image. But there it was, every single run: Improve image delivery — Est savings of 985 KiB Nearly a megabyte of wasted transfer, just from six project screenshots. And that was just the images visible above the fold. The full list across all projects was worse. The culprit: every image I'd ever uploaded through the Django admin was a PNG. Some of them were over 1 MB. WebP would have cut most of them by 80%. I knew this. I just hadn't done anything about it. So I wrote a management command to fix the backlog, and then made the model auto-convert on every future upload so I'd never have to think about it again. The Problem With PNGs in a Portfolio When you're building a portfolio, you screenshot your work and drag it into the admin. That screenshot is usually a PNG — lossless, full-size, straight from your display. Nobody optimises it because the admin accepts it and it shows up fine in the browser. But "shows up fine" isn't the same as "loads fast." A 1.4 MB PNG of a law firm homepage does not need to be 1.4 MB. Served as WebP at quality 85, it's 175 KB. Same visual result. Eight times smaller. Multiply that across 28 projects and you're looking at tens of megabytes that mobile users on slow 4G are downloading just to scroll past thumbnails. The One-Time Backlog Fix: A Management Command First, I needed a way to convert everything that was already in S3. A management command was the right tool — it runs in the production container with full access to the Django ORM and the configured storage backend, so it can read and rewrite files without needing to know whether they're on S3, local disk, or anywhere else. # backend/projects/management/commands/convert_images_to_webp.py from io import BytesIO from django.core.files.base import ContentFile from django.core.management.b

I wanted a soft gate on my resume download. Not a paywall. Just an email field — enough friction to filter bots, enough signal to know who's interested. What started as a straightforward feature turned into a three-part lesson: stateless token signing, S3 public access, and email delivery mechanics. Here's the full story. The Feature The flow I wanted: Visitor clicks "Download Resume" on the About page or Hero A modal asks for their email Backend validates the email (format + disposable domain check) A signed, time-limited link is emailed to them They click the link, the PDF opens No database tokens. No cron jobs. No permanent S3 URLs floating around. Part 1 — The Model and the Gate The Resume Model Resume follows the singleton pattern I already use for page headers — force pk=1 on every save, restrict add/delete in admin. One row, forever. class Resume ( models . Model ): pdf = models . FileField ( upload_to = " resume/ " , storage = private_resume_storage ) last_updated = models . DateField ( default = date . today ) def save ( self , * args , ** kwargs ): self . pk = 1 super (). save ( * args , ** kwargs ) ResumeDownloadRequest logs every email that requests a link — no tokens, no expiry columns, just a record of who asked and when. class ResumeDownloadRequest ( models . Model ): email = models . EmailField () created_at = models . DateTimeField ( auto_now_add = True ) unsubscribed = models . BooleanField ( default = False ) class Meta : ordering = [ " -created_at " ] The unsubscribed flag is there for a future newsletter broadcast — when a new blog post goes out, skip anyone who opted out. Blocking Disposable Emails Before signing anything, the email is checked against a frozenset of ~70 known throwaway domains: # core/validators.py DISPOSABLE_EMAIL_DOMAINS : frozenset [ str ] = frozenset ({ " mailinator.com " , " guerrillamail.com " , " yopmail.com " , " 10minutemail.com " , " trashmail.com " , # ... ~70 total }) def is_disposable_email ( email : str ) -> bool