DEV Community: Bharat Solanke

Database Decoded: Navigating Queries in FastAPI & Django (ORM vs. Raw SQL) 🚀

Bharat Solanke — Tue, 24 Feb 2026 08:58:04 +0000

So, you're building a web application or an API, and you need to talk to a database. Naturally, you're probably thinking about Python, and two of the biggest names that pop up are FastAPI and Django. But when it comes to database interactions, these frameworks approach things a little differently.

Let's dive deep into the world of Object-Relational Mappers (ORMs) like SQLAlchemy (often paired with FastAPI) and Django's built-in ORM, compared to the raw power of SQL queries. By the end, you'll have a "foolproof" understanding of when and why to use each.

The Big Three: SQLAlchemy, Django ORM, and Raw SQL 📊

Imagine your database as a library. SQL is the librarian's native tongue. ORMs are like highly skilled translators who convert your Python requests into SQL, talk to the librarian, and then convert the answer back into Python objects you can easily use.

Let's look at the core differences:

Feature	SQLAlchemy (with FastAPI) ⚡	Django ORM (with Django) 🚂	Raw SQL 🔥
Philosophy	Explicit & Flexible. You're the architect! Define your models, sessions, and engines.	"Batteries-Included" & Implicit. Django handles much of the plumbing behind the scenes.	Direct & Unfiltered. No abstraction layer, full manual control.
Flexibility	Highly Adaptable. Works brilliantly with FastAPI, Flask, or even as a standalone library.	Tightly Integrated. Best suited for the Django ecosystem.	Universally Compatible. If a system speaks SQL, you can use it.
Async Support	First-Class! Designed for async/await from the ground up, especially with asyncpg.	Evolving. Traditionally synchronous, but making great strides with async views and ORM methods.	Driver Dependent. Relies on the database driver (e.g., asyncpg for PostgreSQL).
Query Style	session.execute(select(User))	User.objects.filter(is_active=True)	SELECT * FROM users WHERE is_active = TRUE;
Best For	High-performance microservices, APIs, complex data manipulation.	Rapid development of full-stack web apps, CMS, admin panels.	Extreme optimization, complex analytics, database-specific features.

Why Django's ORM Feels Different (and often magical ✨)

If you're migrating from Django to FastAPI, you'll immediately notice that database interaction feels more "hands-on" with FastAPI and SQLAlchemy.

In Django:

You define your models, and Django takes care of creating database tables (migrations), providing a .objects manager for queries, and even integrating with the admin panel. It's often "magic" that just works. ✨

User.objects.all() is a simple, intuitive way to fetch all users.

In FastAPI with SQLAlchemy:

You explicitly define your models (Base.metadata.create_all(engine)).
You manually manage SessionLocal to get a database session and use session.add(), session.commit(), session.refresh().
Fetching data involves constructs like select(User), session.execute(), and scalars().

The Trade-off: Django gives you incredible speed of development for many common web applications. FastAPI + SQLAlchemy gives you unparalleled speed of execution, especially in concurrent, asynchronous environments, and granular control over every aspect of your data interaction. It's about choosing the right tool for your project's specific needs! 🛠️

Optimization Masterclass: Squeezing Out Every Millisecond ⏱️

No matter which path you choose, neglecting optimization is a fast track to slow APIs and frustrated users. Here are the golden rules:

🚀 For SQLAlchemy (FastAPI):

Crush N+1 Queries (Your #1 Enemy! 😡)

This is where you fetch a list of items (e.g., 10 users) and then, in a loop, fetch related data for each item (e.g., 10 separate queries for each user's address). That's 11 queries instead of 1!

Solution: Use joinedload() (for foreign key relationships, like a SQL JOIN) or subqueryload() (for collections, often using a subquery or IN clause).

# Bad (N+1 example) 😱
users = db.query(User).all()
for user in users:
    print(user.address.street) # Each .address access hits the DB again!

# Good (Joined Load) ✅
users = db.query(User).options(joinedload(User.address)).all()
for user in users:
    print(user.address.street) # All addresses loaded in one go!

Async Bonus: For asyncpg drivers, selectinload() is often the champion for efficiently loading relationships.

Proper Session Management

Always ensure your database sessions are opened and closed correctly. FastAPI's Dependency Injection system is a superhero here! 💪

from sqlalchemy.orm import Session
from .database import SessionLocal


def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

@app.get("/items/")
async def read_items(db: Session = Depends(get_db)):
    pass

🚂 For Django ORM:

select_related() for Foreign Keys (SQL JOINs)

# Bad (N+1 again!) 😱
users = User.objects.all()
for user in users:
    print(user.profile.bio)

# Good (select_related) ✅
users = User.objects.select_related('profile').all()
for user in users:
    print(user.profile.bio)

prefetch_related() for Many-to-Many & Reverse Foreign Keys

posts = Post.objects.prefetch_related('comments').all()
for post in posts:
    for comment in post.comments.all():
        print(comment.text)

.only() or .defer() to Limit Fields

users = User.objects.only('username', 'email').all()

🔥 For Raw SQL Queries (The "Break Glass" Option):

Parameterized Queries (SQL Injection Shield! 🛡️)

# Bad (SQL Injection waiting to happen!) 🚨
user_id = request.query_params.get("id")
query = f"SELECT * FROM users WHERE id = {user_id}"
db.execute(query)

# Good (Parameterized - safe and fast!) ✅
user_id = request.query_params.get("id")
query = "SELECT * FROM users WHERE id = :user_id"
db.execute(text(query), {"user_id": user_id})

Connection Pooling

Creating a new database connection for every request is inefficient. Use a connection pool to reuse existing connections. Both SQLAlchemy and asyncpg offer robust pooling options. ♻️

Explicit Columns (SELECT column1, column2 vs. SELECT *)

Only select the columns you absolutely need to reduce data transfer and processing overhead.

The Hybrid Approach: Your Foolproof Strategy 💡

Here’s the ultimate secret: Don't pick just one! The most robust and high-performing applications skillfully blend these approaches.

✅ Start with the ORM (SQLAlchemy or Django ORM)

For the vast majority of your standard CRUD operations and business logic, the ORM is your best friend. It offers rapid development, better security, and easier maintenance. This should be your default. 🤝

🧐 Optimize with ORM-specific Tools

Before resorting to raw SQL, exhaust all the ORM's optimization features (e.g., joinedload, select_related, .only()). Many performance issues can be solved here.

⚡ Deploy Raw SQL Strategically

If, and only if, you hit a genuine performance bottleneck or need to execute a hyper-specific, complex query (like advanced reporting, graph traversals, or unique database features) that's clunky or slow with the ORM, then drop down to raw SQL.

With SQLAlchemy, you can execute raw SQL through your existing session using session.execute(text("YOUR COMPLEX SQL HERE")).
In Django, Model.objects.raw() or connection.cursor() allow raw SQL execution.

Final Thoughts

By embracing this balanced, hybrid approach, you'll gain the best of all worlds: the development speed and safety of ORMs, combined with the raw power and optimization potential of direct SQL when it truly matters.

Happy coding, and may your databases always be fast and furious! 🚀🏎️💨

🔴 Redis: Complete Beginner to Advanced Guide (With Real Lessons From Major Attacks)

Bharat Solanke — Thu, 05 Feb 2026 16:41:36 +0000

Introduction

In modern backend development, performance and scalability are critical. Applications today serve millions of users, handle real-time updates, and process massive data quickly. Traditional databases alone often struggle to meet these speed requirements.

This is where Redis comes into the picture.

Redis is widely used by companies like Twitter, GitHub, StackOverflow, and many large-scale SaaS platforms to handle caching, real-time messaging, session storage, and more.

In this blog, we will cover:

What Redis is
Why Redis is so fast
Redis data structures
Redis Streams
Redis Geospatial
Real-world use cases
Alternatives to Redis
Major Redis security attacks
Production security lessons

What is Redis?

Redis stands for Remote Dictionary Server. It is an open-source, in-memory data store used as:

Cache
Database
Message broker
Real-time data store

Unlike traditional databases that store data on disk, Redis stores data in RAM (memory) which makes it extremely fast.

Why Redis is So Fast

Redis achieves high performance because:

It stores data in memory.
It uses optimized data structures.
It is single-threaded which avoids locking overhead.
It supports efficient network communication.

Redis can process millions of operations per second.

Redis Data Storage Model

Redis stores data using key-value pairs.

Example:

user:1001 → {"name": "Bharat", "role": "Engineer"}

Redis Data Types

Redis is more powerful than a simple key-value store because it supports multiple data structures.

1. Strings

Used for caching, tokens, and counters.

2. Lists

Ordered collection used for queues.

3. Sets

Unordered unique values.

4. Sorted Sets

Used for leaderboards and ranking systems.

5. Hashes

Store objects like user profiles.

6. Streams

Used for event-driven messaging systems.

7. Bitmaps and HyperLogLog

Used for analytics and counting unique events.

Redis Persistence

Although Redis stores data in memory, it supports persistence:

RDB (Snapshotting)

Stores periodic snapshots of data.

AOF (Append Only File)

Logs every write operation.

Both can be used together for better reliability.

Redis Streams (Event Streaming)

Redis Streams is a data structure designed for real-time event processing.

Features

Time-ordered message storage
Consumer groups
Reliable message processing
Message replay capability

Example Use Cases

Notification systems
Chat applications
Background job processing
Microservices communication

Redis Geospatial

Redis provides geospatial indexing for location-based applications.

What It Supports

Store coordinates
Distance calculation
Radius-based location search

Example Use Cases

Ride-sharing apps
Food delivery services
Fleet tracking
Store locator applications

Real-World Redis Use Cases

Redis is widely used in production for:

1. Caching

Reducing database load by storing frequently accessed data.

2. Session Storage

Used by frameworks like Django and FastAPI.

3. Rate Limiting

Prevent API abuse.

4. Real-Time Analytics

Track user activity and counters.

5. Pub/Sub Messaging

Used in live notification systems.

6. Distributed Locks

Prevent race conditions in distributed systems.

Alternatives to Redis

Although Redis is powerful, there are other tools available:

Memcached

Simple in-memory cache.

Apache Kafka

Event streaming platform.

Hazelcast

In-memory distributed computing grid.

Apache Ignite

Enterprise in-memory data grid.

Aerospike

High-performance NoSQL database.

Each alternative serves different use cases depending on scale and architecture.

Major Redis Security Attacks

One of the most important lessons from Redis history comes from large-scale cyberattacks caused by misconfigured Redis servers.

Smominru Cryptomining Attack

This was one of the largest attacks exploiting unsecured Redis instances.

What Happened?

Thousands of Redis servers were exposed to the internet.
Many had no password protection.
Attackers scanned open Redis ports.
Malware was installed to mine cryptocurrency.

Impact

Over 500,000 servers infected.
Massive cloud infrastructure cost.
System slowdowns and crashes.

Redis Ransomware Attacks

Another major attack involved deleting Redis databases and replacing them with ransom messages.

Attackers executed commands like:

FLUSHALL

This command deletes all data stored in Redis.

Victims were asked to pay cryptocurrency to recover their data.

Why These Attacks Happened

Redis itself was not vulnerable. The real issue was configuration mistakes:

Redis exposed directly to the internet
No authentication enabled
Running Redis with root privileges
No firewall protection

Production Security Lessons

Every backend developer using Redis must follow these practices.

Enable Authentication

Always configure strong passwords.

Restrict Network Access

Redis should only be accessible inside private networks.

Use Firewall Rules

Allow Redis connections only from trusted servers.

Disable Dangerous Commands

Commands like FLUSHALL should be restricted.

Use Access Control Lists (ACL)

Modern Redis versions support role-based access.

Never Run Redis as Root

This prevents attackers from gaining system-level control.

When Should You Use Redis?

Redis is ideal for:

High-speed caching
Real-time messaging
Session storage
Leaderboards
Event streaming
Rate limiting

When Redis May Not Be the Best Choice

Redis may not be suitable when:

Long-term data storage is required
Large analytical queries are needed
Complex relational data is required

Final Thoughts

Redis is one of the most powerful tools available for backend developers. It significantly improves performance, enables real-time features, and simplifies distributed system design.

However, Redis must be used responsibly. Many historical attacks occurred not because Redis was insecure, but because it was deployed without proper configuration.

Understanding Redis functionality along with its security best practices ensures safe and efficient system design.

Conclusion

Redis is more than just a cache. It is a versatile real-time data platform used across modern applications.

By learning Redis fundamentals, advanced features like Streams and Geospatial indexing, and production security practices, developers can build highly scalable and reliable systems.

If you are working in backend development, mastering Redis is a valuable skill that directly impacts system performance and scalability.

If you found this blog helpful, feel free to share it and connect with me for more backend and system design content.

GitHub Is Not Just About Commands: How to Manage It Properly Like a Professional

Bharat Solanke — Mon, 02 Feb 2026 09:43:06 +0000

When most developers think of GitHub, they think of commands like git init, git add, git commit, and git push.

But the truth is this: GitHub is not about commands at all. Commands are just tools. GitHub is really about discipline, structure, communication, and long-term thinking.

If you treat GitHub as only a place to push code, your project will eventually become messy, difficult to maintain, and painful to scale. If you treat it as a system, it becomes one of your strongest engineering skills.

This blog explains how to manage GitHub properly, especially when starting a project from scratch.

1. GitHub Is a Project Timeline, Not a Backup Folder

Many developers use GitHub like cloud storage:

“Let me just push whatever I have.”

This mindset causes problems very quickly.

Every commit you make becomes a permanent part of your project’s timeline. Anyone reading your repository later (including your future self) should be able to understand:

Why something was added
When it was added
How the project evolved

Good GitHub management tells a clear story of how the project was built.

2. Branches Represent Intent, Not Just Code

A branch is not just another copy of code. A branch answers one important question:

What problem am I solving here?

That is why professional projects follow structured branching patterns:

main → stable, release-ready code
develop → active development and integration
feature/* → one specific responsibility

Examples:

feature/authentication
feature/database-setup
feature/workflow-engine

Even an empty branch has value because it clearly defines intent and future direction.

3. Never Treat `main` as a Playground

One of the most important rules in GitHub management is simple:

Never commit directly to the main branch.

The main branch represents trust. It should always be stable, readable, and deployable.

Instead:

Do all work in feature branches
Merge completed work into develop
Merge into main only when the code is stable

Following this rule alone significantly improves code quality and project stability.

4. Small, Meaningful Commits Matter

Poor commit messages:

done
final
fix
changes

Good commit messages explain intent:

chore: add gitignore for env and virtual environment
feat: setup database connection
fix: handle token expiration logic

A good commit message answers:

What changed, and why?

If your commit cannot answer this clearly, it is probably doing too much.

5. GitHub Is Also About What You Do NOT Commit

Professional GitHub usage is not only about what you push, but also about what you intentionally ignore.

Things that should almost never be committed:

.env files
Virtual environments (venv, .venv)
Secrets and credentials
Machine-specific configuration files

Instead:

Commit .env.example
Ignore real .env files
Inject secrets using environment variables

This approach keeps repositories secure, portable, and conflict-free.

6. Empty Branches Are Not a Problem

Many developers think branches must contain code to be useful. This is incorrect.

Empty branches are planning tools. They help:

Define a roadmap
Enable parallel development
Avoid rushed architectural decisions

Creating branches like feature/database-setup or feature/authentication early makes the project easier to manage later.

7. GitHub Is a Communication Tool

Your GitHub repository communicates far more than just code. It shows:

How you think
How you plan work
How you structure systems
How seriously you treat engineering

Recruiters, teammates, and future maintainers often judge a project by its Git history before reading the code itself.

Clean branches and meaningful commits silently demonstrate professionalism.

8. GitHub Scales With Your Project

As projects grow, complexity increases:

More features
More contributors
More environments

Without proper GitHub management, this leads to:

Frequent merge conflicts
Bug-prone releases
Difficult rollbacks

Strong Git discipline early makes scaling smoother and less stressful.

Final Thoughts

GitHub is not about memorizing commands. Anyone can learn Git commands in a day.

What truly matters is:

Thinking before committing
Structuring work clearly
Respecting the future of your project

When used properly, GitHub becomes more than a tool—it becomes a reflection of your engineering maturity.

😲 Most People Don’t Know You Can Log In by Copying a Password Hash 🔐 (And Why It’s NOT a Bug)

Bharat Solanke — Tue, 06 Jan 2026 07:20:24 +0000

😮 Most people don’t even know this is possible.

If you are an admin or have database access, you can copy your own hashed password, paste it into another user’s record, and then log in as that user using your password.

⚡ When people discover this for the first time, the reaction is usually shock:

“Wait… I didn’t know this was possible. That sounds like a huge security issue!”

😰 It feels like something is very wrong.

✅ In reality, this behavior is expected, intentional, and actually proves that the password system is working correctly.

This article explains — from absolute basics — why this happens, what is really going on under the hood, and why it is not a security flaw.

🔰 Let’s Start From Absolute Basics

What Is a Password?

A password is a secret known only to the user.

A secure system must:

✅ Verify the password
❌ Never store it in readable form
❌ Never be able to retrieve it

If a system can read your password later, it is already insecure.

❌ The Most Common Wrong Assumption

Many people believe:

“The system stores my password and checks it during login.”

This is false.

A secure system never stores passwords.

🔐 Then What Does the System Store?

Instead of storing the password, systems store a hash.

A hash is:

A one‑way mathematical transformation
Impossible to reverse
Always the same for the same input (with the same salt)

Example:

Password: admin@123
Hash:     X9A7f...Qm==

You can recreate the hash again — but you cannot get the password back.

Hashing Is NOT Encryption (Very Important)

Encryption	Hashing
Reversible	One‑way
Has a key	No key
Can be decrypted	Cannot be reversed
Used for data	Used for passwords

Passwords must be hashed, not encrypted.

How Modern Frameworks Store Passwords (Example: Django)

When a user is created:

The password is taken
A random salt is added
A strong algorithm (PBKDF2 / bcrypt / Argon2) is applied
The process is repeated thousands of times
Only the final hash is stored

Example stored value:

pbkdf2_sha256$870000$salt$hash

This value is not the password.

🔄 How Login Actually Works

When a user logs in:

User enters a password
The system:

Uses the same algorithm
Uses the same salt
Hashes the entered password
1. Compares the result with the stored hash

If both hashes match → login succeeds.

👉 The password is never read, never retrieved, never decrypted.

Now the Part That Confuses Most People

As an admin, you may notice:

You can see hashed passwords in the database
You copy your own hash
You paste it into another user’s password field
You log in as that user using your password
And it works

This feels alarming.

Many conclude:

“Hashing must be broken.”

It isn’t.

💡 What Actually Happened (Key Insight)

You did not discover the other user’s password.

You did this instead:

You replaced their password with your password.

Now both users:

Have the same hash
Have the same password
Use the same authentication secret

A Simple Real‑World Analogy

Think of a password hash as a lock, not a key.

You didn’t copy someone’s key
You replaced their lock with your lock

If two doors use the same lock, the same key opens both.

That does not mean the lock was cracked.

🛡️ Why This Is NOT a Security Bug

This behavior exists because:

Passwords cannot be recovered
Authentication works via hash comparison
Admins must be able to reset access

If this didn’t work, the system would be trying to decrypt passwords — which would be a serious security flaw.

So ironically:

This behavior proves the system is designed correctly.

What This Does NOT Mean

This does NOT mean:

❌ Passwords can be decrypted
❌ Hashes are reversible
❌ Frameworks like Django are insecure
❌ Admins can see real passwords

It only means:

✅ Hashes define access
✅ Replacing a hash replaces the password

🚨 Why You Should NEVER Do This in Production

Even though it works, manually copying hashes is bad practice.

Risks include:

Account takeover
No audit trail
Insider abuse
Compliance violations
Legal exposure

The Correct Way for Admins to Handle Passwords

Use password reset flows
Set temporary passwords
Force password change on next login
Use built‑in admin tools

Never:

Copy hashes
Share credentials
Bypass reset mechanisms

Why Hashed Passwords Are Still the Best Approach

Even if:

A database is leaked
Backups are stolen
Admin access is compromised

Attackers still:

Cannot read passwords
Cannot reverse hashes
Must brute‑force each account individually

This is why:

Banks use hashing
Enterprises use hashing
Frameworks use hashing by default

🧠 Final Takeaway

Authentication systems never retrieve passwords.
They only compare hashes.
Copying a hash replaces a password — it does not reveal it.

Once this concept is understood, most password‑related confusion disappears.

If you found this useful, share it — because this misunderstanding is far more common than it should be.

2025: Building Real Backend Systems, Not Just Writing Code

Bharat Solanke — Tue, 23 Dec 2025 10:09:14 +0000

Some years add experience to your resume.

Some years change how you think as an engineer.

For me, 2025 was that year. 🌱

This wasn’t about experimenting with side projects or following tutorials. It was about building real backend systems, handling production issues, and understanding what it truly means to own software that people depend on.

From Writing Code to Building Systems 🧠

A major part of my 2025 journey involved building, stabilizing, and enhancing a dynamic logbook and workflow management system using Python, Django, PostgreSQL, and Docker 🐍🐘🐳.

What made this system challenging was that it wasn’t static.

Logbook templates—sections, tables, and fields—were generated at runtime, and corresponding PostgreSQL tables were created dynamically based on configuration.

This meant:

No hardcoded schemas
No predefined models for every table
Full control over runtime validations and inserts

It pushed me beyond standard CRUD development and into real backend engineering, where architectural decisions directly impact reliability and data integrity.

Designing Workflows That Demand Accountability 🔄

The system supported section-wise logbook submissions, each following a strict lifecycle:

➡️ Submit

➡️ Review

➡️ Approve

➡️ Reject

Each transition required:

Role-based access control
Strong validations
Complete traceability

To support this, I implemented audit logging, event tracking, and follow-up mechanisms, ensuring that:

Every action is recorded
Every change has a user and timestamp
Every decision is traceable

This reinforced an important lesson:

In real-world systems, traceability is not optional—it’s foundational.

When Databases Push Back 🗄️

Dynamic systems quickly expose weaknesses—especially in databases.

A significant portion of my time went into:

Fixing data consistency issues
Handling foreign key constraint failures
Preventing partial inserts during dynamic table operations
Managing edge cases where schema changes conflicted with live data

These problems rarely appear in tutorials. They surface only when systems are actively used in production.

Debugging them taught me patience, precision, and respect for the database as a core system component, not just a storage layer.

Production: The Real Teacher 🚨

Beyond application logic, 2025 took me deep into production infrastructure.

I worked hands-on with:

Docker-based deployments 🐳
PostgreSQL backups and restores
Container networking and environment configuration
Fixing ALLOWED_HOSTS issues
Nginx reverse proxy setup
SSL configuration 🔐

I also debugged live production issues, including:

Data not visible despite successful submissions
Network failures between services
Reliability issues under real user load

Nothing accelerates learning faster than debugging while users are waiting.

Growing a System Design Mindset 📈

Alongside day-to-day development, I focused on strengthening my system design fundamentals.

I explored:

Kafka basics (topics, partitions, producers, consumers)
API testing strategies
Performance and scalability considerations

Even when not immediately applied, these concepts reshaped how I think about architecture—helping me design systems with decoupling, scalability, and future growth in mind.

What 2025 Gave Me 💡

In just a few months, my confidence changed—not because everything worked perfectly, but because I learned how to handle things when they didn’t.

2025 taught me how to:

Build backend systems that evolve dynamically
Debug production issues without panic
Design for reliability and auditability
Take true ownership of complex systems

Most importantly, it taught me this:

Real engineering happens outside the comfort zone.

Closing Thoughts 🌱

2025 wasn’t about shortcuts or flashy achievements.

It was about depth, ownership, and growth.

I didn’t just write code this year.

I learned how real systems behave, how production humbles assumptions, and how engineering maturity is earned through responsibility.

And that foundation will stay with me—well beyond 2025. 🚀

🚀 A Complete Guide to Deploying SSL-Enabled Django in Docker With Nginx, PostgreSQL & Redis

Bharat Solanke — Fri, 28 Nov 2025 06:39:19 +0000

A practical journey of debugging, configuring, and enabling HTTPS on a production server.

Deploying a secure Django application in production often looks simple on paper — until you meet the real-world challenges of certificates, Docker networking, Nginx proxying, and cloud firewalls.

This blog walks through the end-to-end process we followed to bring a Dockerized Django system live over HTTPS. It covers:

How we diagnosed SSL misconfigurations
Fixing invalid certificates
Updating Docker + Nginx
Firewall/NAT troubleshooting
Final verification steps

This is not just a how-to; it is a real engineering story.

🧩 1. Deployment Architecture
The application stack:

✔ Django (served with Gunicorn)
✔ Nginx (reverse proxy + static/media)
✔ PostgreSQL
✔ Redis
✔ Celery + Flower
✔ Docker & docker-compose HTTP worked perfectly. HTTPS, however, would hang indefinitely and then time out.

🎯 2. The Goal
We needed to successfully:

✔ Install valid SSL certificates
✔ Configure Nginx to serve HTTPS correctly
✔ Expose port 443 from Docker → host machine
✔ Ensure firewall/NAT permitted inbound HTTPS
✔ Validate secure access from any browser

🔎 3. Debugging the SSL Failure
First step: check Nginx logs inside the container:

docker logs nginx

We found:

cannot load certificate "/etc/nginx/ssl/domain.crt":
PEM_read_bio_X509_AUX() failed (SSL: ... no start line)

This error meant:
👉 The certificate file existed — but its content was empty or invalid.

We checked the file:

head -n 2 nginx/ssl/domain.crt

🛠 4. Fixing the SSL Files
The correct .crt, .key, and CA bundle files were uploaded to the server using:

scp -P <port> certificate.crt ca_bundle.crt user@server:/path/to/nginx/ssl/

We verified they were valid:

ls -l nginx/ssl/

All files now had valid PEM content:

domain.crt
domain.key
ca_bundle.crt Nginx was reloaded afterward.

🧱 5. Configuring HTTPS in Nginx
We updated the configuration to:

✔ Redirect HTTP → HTTPS
✔ Serve static & media correctly
✔ Proxy Django with correct headers
✔ Load the correct certificates

Final Nginx HTTPS configuration

upstream django_app {
    server web:8000;
}

server {
    listen 80;
    server_name _;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name _;

    ssl_certificate /etc/nginx/ssl/domain.crt;
    ssl_certificate_key /etc/nginx/ssl/domain.key;
    ssl_trusted_certificate /etc/nginx/ssl/ca_bundle.crt;

    location /static/ {
        alias /usr/share/nginx/html/static/;
    }

    location /media/ {
        alias /usr/share/nginx/html/media/;
    }

    location / {
        proxy_pass http://django_app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }
}

🐳 6. Updating Docker for HTTPS
We exposed port 443:

nginx:
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - ./nginx/ssl:/etc/nginx/ssl

Then restarted:

docker-compose down
docker-compose up -d

Nginx was now correctly listening on port 443.
But… HTTPS was still unreachable.

🧱 7. Host-Level Firewall Check
We checked:

sudo ufw status

Result: inactive.
Next, iptables:

sudo iptables -t nat -L -n

Docker’s NAT rules were correct:

DNAT tcp dpt:443 → container_ip:443

So the machine itself wasn’t blocking port 443.

📡 8. External Network Test

curl -Iv https://<server-ip>

Result:

Trying <server-ip>:443...
(hangs forever)

This was the critical clue:
❌ No traffic was reaching the server
❌ Not even reaching Docker or Nginx
This meant the cloud/datacenter firewall was blocking 443.

📩 9. Requesting Cloud Team to Open Port 443
We escalated the issue and requested:

“Please enable inbound HTTPS (443) on the network firewall.
The server is listening correctly, but incoming TLS traffic is blocked.”

After the network team opened port 443…
🔥 HTTPS started working instantly.

🎉 10. Final Verification
We tested again:

curl -Iv https://<your-domain>

Response:

HTTP/2 200
server: nginx

Browser showed:

✔ HTTPS lock
✔ Valid certificate
✔ Full redirect from HTTP → HTTPS
✔ Static/media loading correctly
✔ Django + WebSockets running normally

Deployment was successful.
🏁 11. Key Lessons Learned

SSL files must contain valid PEM data Corrupted or empty certificates cause silent failures.
Use a complete certificate chain Both:

domain.crt
ca_bundle.crt

Docker must expose HTTPS explicitly Exposing only port 80 is not enough.
Never forget cloud firewalls Your VM might be open but the provider might still be blocking ports.
Debug every layer To solve HTTPS issues, inspect:

Browser
DNS
Cloud firewall
Server firewall
iptables
Docker NAT routing
Nginx configs
SSL files
Application headers Solving it required checking each of these layers.

📘 12. Conclusion

Deploying SSL in a production Docker environment is not just about placing certificate files in a folder.
It requires a complete understanding of:

✔ Nginx reverse proxying
✔ SSL termination
✔ Docker networking
✔ Cloud firewall rules
✔ Valid certificates
✔ Correct header forwarding Once all layers worked together, the system became fully HTTPS-enabled and production-ready.

Mastering Whitespace and Newlines in Django Templates: The Ultimate Guide 🎯

Bharat Solanke — Thu, 18 Sep 2025 07:46:27 +0000

Introduction

Hidden bugs, mysterious broken outputs, and unexpected rendering errors in Django templates are often caused by invisible foes: whitespace and auto-generated newlines. For Django developers, especially those working with dynamic data, form-heavy UIs, or complex HTML tables, these subtle formatting issues can consume hours of debugging. This post provides an in-depth, practical guide to why whitespace matters in Django templates, how to spot and fix related issues, and best practices to keep your projects robust and professional. 🧑‍💻✨

Why Whitespace and Newlines Cause Problems in Django Templates 🤔

Django templates process the literal text, tags, and code—every character, space, and newline impacts the final output.

Broken logic tags: {% if %}, {{ value|date:"Y-m-d"|default:"-" }} split awkwardly, or with stray spaces, can cause silent bugs and missing output. ⚠️
Blank cells, awkward layouts, or “mystery gaps”—especially in tables and forms where the template’s layout is whitespace-sensitive. 🕳️
Unintended extra lines from loops or indentations, turning clean pages into confusing ones.

Best Practices: Writing Clean and Maintainable Django Templates 💡

1. Keep Tags and Filter Chains on a Single Line

<td>{{ value|date:"Y-m-d"|default:"-" }}</td>  <!-- 👍 Best practice -->

Never do:

<td>
  {{ value
      |date:"Y-m-d"
      |default:"-" }}
</td>   <!-- 👎 This can fail silently! -->

Stray newlines in tags can cause perplexing bugs. Line it up—keep it clear! 🗂️

2. Tame Your Editor 🛠️

Configure VSCode/PyCharm to turn off auto-wrap for .html and Django template files.
A perfectly formatted template today can break tomorrow if your editor “helps” a bit too much! ✍️

3. Use {% spaceless %} for Clean Output

When whitespace creeps into your forms or table markup, Django’s built-in {% spaceless %} tag is your friend:

 {% spaceless %}
  <tr>
    <td>{{ user.username }}</td>
    <td>{{ user.email }}</td>
  </tr>
{% endspaceless %}

No more unexpected gaps—just clean, professional HTML! 🧽

4. Modularize and Comment for Team Success

Use {% include %} and inheritance for complex layouts. 🔗
Consistent block and filename conventions keep your project scalable. 🗃️
Comment tricky sections with {% comment %} ... {% endcomment %} for clarity, especially when revisiting code later. 💬

5. Outsource Complexity: Views Over Template Logic

Templates should show data, not decide what data to show!
Keep calculations, loops, and logic-heavy operations in your view/controller. The simpler your HTML, the fewer whitespace gremlins you’ll face. 🚀

6. Debug Like a Pro 🔍

Use Django Debug Toolbar to inspect how your template renders, step by step.
Regularly “View Source” in your browser—spot empty cells, stray newlines, and hunt down those stealthy bugs. 👀
Advanced: Profiling tools and middleware can help track performance and subtle render errors in production.

Advanced Whitespace Management 🥇

For large apps: Use middleware or packages like django-spaceless-templates to systematically clean up whitespace during rendering.
Needing even more control? Try Jinja2 templates, which offer fine-grained block-level whitespace trimming. 🧩

Visual Debugging (Emoticon Style!)

📝 Compare before/after code samples to spot whitespace issues.
🕵️ Use the browser’s inspect tool to understand the connection between source and output.
🎨 Screenshots of both “messy” and “polished” UIs can make fixes tangible and convincing.

Conclusion & Key Takeaways 🎉

Whitespace and newlines are silent disruptors in Django templating—with just a line break or stray space, you can derail layout and logic. But a handful of best practices—careful formatting, {% spaceless %} tags, editor vigilance, and a modular coding mindset—turns chaos into clarity.

With these insights and tools, it’s easy to banish whitespace bugs for good—and ship Django templates that are as robust as they are beautiful. Good luck, and happy templating! 🥳🚀

Implementing PostgreSQL Replication and Automated Cloud Backups Using Docker and Rclone

Bharat Solanke — Tue, 09 Sep 2025 06:58:08 +0000

In modern production environments, database replication and automated cloud backups are essential for ensuring high availability, fault tolerance, and disaster recovery. In this blog, I’ll walk through a step-by-step approach to set up a PostgreSQL replication system using Docker, create automated backups, and upload them to cloud storage using Rclone.

This guide uses a dummy project structure to maintain confidentiality while illustrating a real-world implementation.

Why This Setup is Useful

Imagine a growing SaaS application that cannot afford downtime. You want to:

Ensure continuous replication of your main database to multiple secondary databases.
Automate daily backups to prevent data loss.
Securely store backups on cloud storage like OneDrive, Google Drive, or S3.
Have a system where restoring the database is straightforward if Docker containers fail.

This approach is ideal for:

Multi-environment deployments (staging, production).
Teams managing sensitive data that requires offsite backups.
Applications where downtime translates to business loss.

project_root/
├── app/
│   └── some_module/                
├── backups/                        
├── backup.sh                      
├── backup_to_cloud.sh             
├── db/
│   ├── parent/
│   │   ├── postgresql.conf         
│   │   └── pg_hba.conf             
│   ├── child1/
│   │   └── postgresql.conf         
│   ├── child2/
│   │   └── postgresql.conf         
│   └── child3/
│       └── postgresql.conf         
├── db_backups/                    
├── docker-init-scripts/             
├── entrypoint.sh                     
├── full_backup.sql.gz                
├── backup.sql                        
├── postgresql.conf                   
├── test_cloud_backup.sh              
├── manage.py                         
├── docker-compose.yml               
└── requirements.txt

Explanation:

db/childX: Config files for replicated child databases.
backups/: Local storage for .sql or .dump files.
cron_jobs/: Scripts scheduled to run periodic backups.
backup.sh: Handles local database backup.
backup_to_cloud.sh: Uploads backups to cloud storage via Rclone.

Step 1: Setting Up Docker Containers for PostgreSQL Replication

We set up one parent database and three child databases. Each child replicates from the parent to ensure redundancy.


services:
  postgres_parent:
    image: postgres:15
    container_name: postgres_parent
    restart: always
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: admin
    volumes:
      - postgres_parent_data:/var/lib/postgresql/data
      - ./db/primary/postgresql.conf:/etc/postgresql/postgresql.conf
      - ./db/primary/pg_hba.conf:/etc/postgresql/pg_hba.conf
    command: postgres -c config_file=/etc/postgresql/postgresql.conf
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 10s
      retries: 5
      timeout: 5s

  postgres_child1:
    image: postgres:15
    container_name: postgres_child1
    restart: always
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: admin
      PARENT_HOST: postgres_parent
    volumes:
      - postgres_child1_data:/var/lib/postgresql/data
      - ./db/child1/postgresql.conf:/etc/postgresql/postgresql.conf
    command: postgres -c config_file=/etc/postgresql/postgresql.conf
    depends_on:
      - postgres_parent

  postgres_child2:
    image: postgres:15
    container_name: postgres_child2
    restart: always
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: admin
      PARENT_HOST: postgres_parent
    volumes:
      - postgres_child2_data:/var/lib/postgresql/data
      - ./db/child2/postgresql.conf:/etc/postgresql/postgresql.conf
    command: postgres -c config_file=/etc/postgresql/postgresql.conf
    depends_on:
      - postgres_parent

  postgres_child3:
    image: postgres:15
    container_name: postgres_child3
    restart: always
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: admin
      PARENT_HOST: postgres_parent
    volumes:
      - postgres_child3_data:/var/lib/postgresql/data
      - ./db/child3/postgresql.conf:/etc/postgresql/postgresql.conf
    command: postgres -c config_file=/etc/postgresql/postgresql.conf
    depends_on:
      - postgres_parent

volumes:
  postgres_parent_data:
  postgres_child1_data:
  postgres_child2_data:
  postgres_child3_data:

Key Points:

Each child container depends on the parent.
Custom PostgreSQL configs are mounted to ensure proper replication settings.
Healthchecks ensure the parent is ready before children start.

Step 2: Local Database Backups
To safeguard against data loss, we create daily backups.

backup.sh Example:

#!/bin/bash

BACKUP_DIR="./backups"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
DB_NAME="mydb"
USER="postgres"

mkdir -p $BACKUP_DIR
pg_dump -U $USER $DB_NAME > $BACKUP_DIR/${DB_NAME}_backup_$DATE.sql
echo "Backup created at $BACKUP_DIR/${DB_NAME}_backup_$DATE.sql"

Stores timestamped .sql backups in backups/.
Can be triggered manually or via cron.

Step 3: Automating Backups with Cron
Set up a cron job to run the backup script daily.

# crontab -e
0 2 * * * /path/to/my_project/backup.sh >> /path/to/my_project/logs/backup.log 2>&1

Runs every day at 2 AM.
Logs are stored for auditing purposes.

Step 4: Uploading Backups to Cloud with Rclone

We use Rclone to upload backups to OneDrive.
backup_to_cloud.sh Example:

#!/bin/bash

BACKUP_DIR="./backups"
REMOTE_NAME="onedrive"
REMOTE_PATH="DB_Backups/$(date +%Y-%m-%d)/"

rclone copy $BACKUP_DIR $REMOTE_NAME:$REMOTE_PATH --progress

Rclone Setup Steps:

Install Rclone on the server.
Run rclone config.
Create a new remote (e.g., onedrive) and authorize it.
Test connectivity using rclone lsf onedrive:.
Tip: Always test rclone copy manually before automating.

Step 5: Handling Failures and Recovery

Scenario: Docker or a container fails.

Recovery Steps:

Stop all containers:

docker-compose down

Restore the database from the latest backup:

psql -U postgres -d mydb < ./backups/mydb_backup_YYYY-MM-DD.sql

Restart containers:

docker-compose up -d

Verify replication status in PostgreSQL:

SELECT * FROM pg_stat_replication;

Key Points:

Keep backups outside Docker volumes to prevent accidental loss.
Use versioned backups and cloud storage to recover from critical failures.

Real-World Example

Scenario: A SaaS application stores customer activity data.

Parent database: Accepts writes.
Child databases: Provide read replicas for analytics and reporting.
Backup scripts: Run nightly, stored locally and in the cloud.
Failure recovery: If the parent container crashes, the latest backup can restore the database, minimizing downtime.
This setup ensures high availability, data durability, and quick disaster recovery.

Summary
In this blog, we covered:

Dockerized PostgreSQL replication with one parent and multiple children.
Automated local backups using scripts and cron jobs.
Cloud backup using Rclone and OneDrive.
Recovery procedure in case Docker or database fails.
Best practices for backup and replication management.

This approach is scalable, secure, and production-ready, suitable for both small teams and enterprise environments.

✅ Next Steps:

Extend Rclone scripts to support multiple cloud providers.
Add monitoring alerts if backup or replication fails.
Schedule incremental backups to optimize storage.

⚡ Building a Real‑Time Collaborative Form Editing System with Django Channels, WebSockets & Redis

Bharat Solanke — Mon, 18 Aug 2025 17:08:36 +0000

🏁 Introduction

In Today's fast-paced work environment. teams often need to edit shared forms simultaneously. Whether it's a multi-user dashboard, a shared data entry sheet, or a confirmation panel - the challenge is the same:

Without real‑time sync, users may overwrite each other’s work 😓
Constant page refreshes slow down productivity
Communication gaps can lead to missing or stale updates

💡 Real‑time collaborative editing solves this by ensuring that everyone connected to the same form sees changes instantly — just like in Google Sheets.

This blog will walk through how I built a multi‑user, live‑updating form system using:

Django Channels for async WebSocket handling
Redis as the message broker
JavaScript WebSockets API for sending/receiving updates

🔍 The Problem We’re Solving

Imagine a shared form where multiple people:

Type into different fields at the same time ✏️
Need to see each other’s changes immediately 👀
Want visual indicators showing who’s editing what 💬
Can dynamically add/remove form rows in real time ➕➖

Without real-time features:

Data can be out of sync between users
There’s a risk of accidental overwrites
The experience feels slow and outdated

🏗 High-Level Architecture

The system follows this flow:

User edits a field → Browser sends WebSocket message to Django  
Django Channels sends it to a Redis Pub/Sub group  
Redis broadcasts to all connected clients in that group  
Other users’ browsers instantly update the field

🗂 Room-based grouping ensures only users editing the same form instance see each other’s updates

⚙ Tech Stack Overview

Technology --> Purpose

WebSockets --> Enables instant 2‑way communication
Django Channels --> Adds async WebSocket support to Django
Redis --> Distributes messages between server processes
JavaScript --> Captures inputs, sends updates, and applies received changes

🖥 Backend – Django Channels Consumer

The consumer acts as the WebSocket handler — connecting users, receiving messages, and broadcasting to others.

import json
from channels.generic.websocket import AsyncWebsocketConsumer

class CollaborativeFormConsumer(AsyncWebsocketConsumer):
    async def connect(self):
        # Identifiers define a unique group for the form session
        self.section_id = self.scope["url_route"]["kwargs"]["section_id"]
        self.template_id = self.scope["url_route"]["kwargs"]["template_id"]
        self.shift_id = self.scope["url_route"]["kwargs"]["shift_id"]

        self.group_name = f"form_{self.section_id}_{self.template_id}_{self.shift_id}"
        self.username = f"{self.scope['user'].first_name} {self.scope['user'].last_name}".strip()

        print(f"✅ Connected: {self.username} joined {self.group_name}")
        await self.channel_layer.group_add(self.group_name, self.channel_name)
        await self.accept()

    async def disconnect(self, close_code):
        print(f"❌ Disconnected: {self.username}")
        await self.channel_layer.group_discard(self.group_name, self.channel_name)

    async def receive(self, text_data):
        data = json.loads(text_data)
        event_type = data.get("type", "")

        # Broadcast to others in the group
        await self.channel_layer.group_send(
            self.group_name,
            {
                "type": "broadcast_message",
                "event": event_type,
                "sender": self.username,
                "sender_channel": self.channel_name,
                **{k: v for k, v in data.items() if k != "type"},
            },
        )

    async def broadcast_message(self, event):
        if event["sender_channel"] == self.channel_name:
            return  # Don’t send updates back to the sender

        payload = {k: v for k, v in event.items() if k not in ("sender_channel", "type")}
        payload["type"] = event["event"]

        await self.send(text_data=json.dumps(payload))

Why this works well:
✅ Group-based rooms keep messages relevant
✅ Echo prevention avoids duplicate updates for the sender
✅ Works with Redis for multi-server scalability

🌐 WebSocket Routing

from django.urls import re_path
from . import consumers

websocket_urlpatterns = [
    re_path(
        r"ws/form/(?P<section_id>\d+)/(?P<shift_id>\d+)/(?P<template_id>\d+)/$",
        consumers.CollaborativeFormConsumer.as_asgi(),
    ),
]

📦 Redis: The Messaging Backbone

Add this to settings.py:

CHANNEL_LAYERS = {
    "default": {
        "BACKEND": "channels_redis.core.RedisChannelLayer",
        "CONFIG": {"hosts": [("localhost", 6379)]},
    },
}

Redis ensures broadcasts work across multiple Django workers.

✨ Frontend – JavaScript WebSocket Integration

Open the connection & sync fields:

function openFormWS(sectionId, shiftId, templateId, currentUser) {
  const protocol = window.location.protocol === 'https:' ? 'wss://' : 'ws://';
  const wsUrl = `${protocol}${window.location.host}/ws/form/${sectionId}/${shiftId}/${templateId}/`;
  const ws = new WebSocket(wsUrl);

  ws.onopen = () => console.log(`🔗 Connected`);

  ws.onmessage = (e) => {
    const data = JSON.parse(e.data);

    if (data.type === 'update') {
      document.querySelectorAll(`[data-template-id="${templateId}"][data-field="${data.field}"]`)
        .forEach(input => {
          input.value = data.value;
          showLastEdited(input, data.sender);
        });
    }
    else if (data.type === 'focus') {
      indicateUserEditing(data.field, data.sender, templateId);
    }
    else if (data.type === 'blur') {
      removeUserEditing(data.field, templateId);
    }
  };

  wireRealtimeFields(templateId, ws, currentUser);
}

Attach event listeners:

function wireRealtimeFields(templateId, ws, currentUser) {
  document.querySelectorAll(
    `[data-template-id="${templateId}"].form-field:not([data-wired="1"])`
  ).forEach(input => {
    input.dataset.wired = "1";

    input.addEventListener('input', () => {
      ws.send(JSON.stringify({ type: 'update', field: input.dataset.field, value: input.value, sender: currentUser }));
    });

    input.addEventListener('focus', () => {
      ws.send(JSON.stringify({ type: 'focus', field: input.dataset.field, sender: currentUser }));
    });

    input.addEventListener('blur', () => {
      ws.send(JSON.stringify({ type: 'blur', field: input.dataset.field, sender: currentUser }));
    });
  });
}

🎨 Visual Indicators for Collaboration

function indicateUserEditing(field, user, templateId) {
  const el = document.querySelector(`[data-template-id="${templateId}"][data-field="${field}"]`);
  el.classList.add('being-edited');
  el.insertAdjacentHTML('afterend', `<span class="editing-badge">✏ Editing: ${user}</span>`);
}

function removeUserEditing(field, templateId) {
  const el = document.querySelector(`[data-template-id="${templateId}"][data-field="${field}"]`);
  el.classList.remove('being-edited');
  const badge = el.parentElement.querySelector('.editing-badge');
  if (badge) badge.remove();
}

function showLastEdited(input, user) {
  let badge = input.parentElement.querySelector('.last-edit-badge');
  if (!badge) {
    badge = document.createElement('span');
    badge.className = 'last-edit-badge';
    input.parentElement.appendChild(badge);
  }
  badge.textContent = `👤 Last edited by: ${user}`;
}

CSS Highlight:

.being-edited {
  border: 2px solid orange;
  background: #fff3cd;
}

💾 Adding an Autosave Feature

To ensure no data loss during network issues, we add a lightweight autosave API:

@csrf_exempt
@login_required
def save_autosave_data(request):
    data = json.loads(request.body)
    template_id = data.get("template_id")
    autosave_data = data.get("autosave_data")

    MyAutosaveModel.objects.update_or_create(
        template_id=template_id,
        defaults={"data": autosave_data},
    )
    return JsonResponse({"status": "success"})

🔥 Challenges & Solutions

Challenge -> Solution

Avoid feedback loops -> Skip sending updates to the origin user

Two users editing same field -> Show “Currently Editing” badges

Dynamic form rows -> Re‑wire event listeners after adding

Offline scenarios -> Periodic autosave to server

🎯 Conclusion

By pairing Django Channels + WebSockets + Redis, we’ve built a scalable, real‑time collaborative form system that:

Keeps all connected users instantly in sync
Shows edit indicators for clarity
Prevents frustrating overwrites
Works for any multi-user form editing scenario

This architecture can be used in dashboards, CRMs, multi-user admin tools, or any shared data entry system you build.

🚀 Why ASGI Over WSGI? 🔄 Solving Multi-Device Login Conflicts in Django 📱💻🛡️

Bharat Solanke — Wed, 30 Jul 2025 07:46:54 +0000

✅ A practical guide to implementing single-user login session enforcement with real-time logout notifications using Django, ASGI, Channels, WebSockets, and Redis.

📌 Problem Statement

We want to ensure that each user can only be logged in on one device at a time.

Hear's the expected behaviour:

When a user logs in from a new device, any existing session on other devices should get:
- ❌ Logged out immediately, and
- 🔔 Notified in real-time about the forced logout.

Traditional Django projects (which run on WSGI) can't do this in real-time - you'd need pulling or periodic refresh. We needed an instant notification system

❓ Why WSGI Couldn’t Help

WSGI (Web Server Gateway Interface) is great for traditional request-response cycles but:

❌ WSGI Limitations

No support for WebSockets
No long-lived connections
No built-in async support
Not scalable for concurrent real-time tasks

Hence, we replaced WSGI with ASGI.

✅ Why We Used ASGI

ASGI (Asynchronous Server Gateway Interface) allows:

✅ Real-time WebSocket support
✅ Async communication
✅ Push-based updates (no polling)
✅ Integration with channels and channels_redis

This made ASGI a perfect fit for:

Real-time session monitoring
Force logout via socket
Scalable async event-driven features

📡 WebSockets (and Why They Matter)

A WebSocket is a protocol that enables bi-directional, full-duplex communication between the server and the client over a single TCP connection.
Unlike HTTP, which is request-response based, WebSockets stay open, so the server can push data to the client without a new request.
In our use case:

When a user logs in from a new device, we:

Save the new session key
Broadcast a message to the old session’s WebSocket connection
The frontend (already connected via WebSocket) receives a real-time message prompting the user

🔧 What We Implemented

✅ 1. WebSocket Connection Per User
Every logged-in user opens a WebSocket connection. We assign each user to a Redis channel group named uniquely, like user_{user.id}.

# consumers.py

class SessionConsumer(AsyncWebsocketConsumer):
    async def connect(self):
        self.user = self.scope["user"]
        if self.user.is_authenticated:
            self.group_name = f"user_{self.user.id}"
            await self.channel_layer.group_add(self.group_name, self.channel_name)
            await self.accept()
        else:
            await self.close()

    async def disconnect(self, close_code):
        if self.user.is_authenticated:
            await self.channel_layer.group_discard(self.group_name, self.channel_name)

    async def force_logout(self, event):
        await self.send(text_data=json.dumps({
            "action": "force_logout"
        }))

✅ 2. Track Current Session ID in DB
We extended Django’s AbstractUser to store the current session key.

# models.py

from django.contrib.auth.models import AbstractUser

class UserMaster(AbstractUser):
    current_session_key = models.CharField(max_length=255, null=True, blank=True)

✅ 3. Check and Destroy Old Sessions on Login
On login, we check if there is a previous session for the user. If yes:

We delete it
Notify the old WebSocket channel (group) to logout

# login view

from channels.layers import get_channel_layer
from asgiref.sync import async_to_sync

if user.current_session_key:
    old_session = Session.objects.filter(session_key=user.current_session_key).first()
    if old_session:
        old_session.delete()

    # 🔔 Notify via WebSocket
    channel_layer = get_channel_layer()
    async_to_sync(channel_layer.group_send)(
        f"user_{user.id}",
        {
            "type": "force_logout",
        }
    )

# Save new session
user.current_session_key = request.session.session_key
user.save()

✅ 4. Frontend WebSocket Listener
When a logout message is sent, the frontend instantly logs the user out.

// session.js

const socket = new WebSocket('ws://' + window.location.host + '/ws/session/');

socket.onmessage = function(event) {
    const data = JSON.parse(event.data);
    if (data.action === "force_logout") {
        alert("You have been logged out because your account was accessed elsewhere.");
        window.location.href = "/logout/";
    }
};

⚙️ Supporting Infrastructure: Redis & Channels
We added these in settings.py:

INSTALLED_APPS += ["channels"]

ASGI_APPLICATION = "your_project.asgi.application"

CHANNEL_LAYERS = {
    "default": {
        "BACKEND": "channels_redis.core.RedisChannelLayer",
        "CONFIG": {
            "hosts": [("redis", 6379)],
        },
    }
}

🧱 Docker Compose Setup

We added Redis and Uvicorn (ASGI server) to our docker-compose.yml:

version: "3.9"
services:
  web:
    build: .
    command: uvicorn your_project.asgi:application --host 0.0.0.0 --port 8000 --reload
    depends_on:
      - redis
    ports:
      - "8000:8000"
  redis:
    image: redis:alpine
    ports:
      - "6379:6379"

🆚 ASGI vs WSGI Summary Table

🧠 Conclusion
With ASGI, we made our Django app:

✅ Real-time capable
✅ WebSocket-enabled
✅ Scalable for future interactive features
✅ More secure with single-session login

This pattern is now ready to be reused for:

🔔 Notifications
📡 Live dashboards
🧾 Collaborative forms
👨‍💻 Chat or support features

Django Context Processors: Explained Step-by-Step

Bharat Solanke — Thu, 24 Jul 2025 17:33:20 +0000

1. What Are Context Processors?

A context processor in Django is a special Python function that receives the request object as an argument and returns a dictionary of variables. These key-value pairs are added to the template context, making them available in every template rendered using Django's template engine

Context processors are a handy way to provide common context data to all templates without having to include them in every view

2. Why Do Context Processors Exist?

DRY (Don't Repeat Yourself): They help developers avoid repeating the same context variables in multiple views. For example, side-wide settings, user info, or notification banners can be injected into templates automatically
Consistency and Centralization: They offer a single location to control data that should be present in all or many templates, improving consistency across an application.
Separation of Concerns: Logic for preparing context data can be separated from view logic, leading to cleaner, more maintainable code.

3. How Do Context Processors Work?

Definition: Write a function that returns a dictionary of context data.
Registration: Add the function's path to the context_processors list inside the TEMPLATES setting in settings.py.
Accessibility: After registration, variables from the context processor are automatically available in relevant templates, with no need to explicitly pass them in each view.

# myapp/context_processors.py
def site_defaults(request):
    return {
        'site_name': 'My Awesome Site',
        'current_year': 2025,
    }

# settings.py
TEMPLATES = [
    {
        # ...
        'OPTIONS': {
            'context_processors': [
                # ...default processors...
                'myapp.context_processors.site_defaults',
            ],
        },
    },
]

Now, site_name and current_year are available in all templates.

4. When Are Context Processors Used?

Automatic inclusion: Context processors are triggered whenever a template is rendered using Django's RequestContext (by default in Django’s render shortcut and generic views).
Global context: Whenever variables need to appear in multiple or all templates, such as in navigation menus or footers.

5. Common Use Cases

User information: Displaying the current user’s name, avatar, or permissions site-wide.
Navigation menus: Providing category lists or navigation items.
Site metadata: Adding site title, company branding, or copyright.
Notification banners: Global alerts, announcements, or maintenance messages.
Cart details in e-commerce: Showing shopping cart count or summary everywhere.
Settings and preference injection: Theme, language, or accessibility settings.
Integration with middleware: Middleware can set attributes on the request object based on authentication, localization, or custom business rules, which context processors then expose to templates.

6. Best Practices

Only inject data that must truly be global, as context processors run on every template render.
Keep context processors fast; avoid database-heavy logic inside them.
Use unique variable names to prevent conflicts, especially when combining multiple processors.

7. Summary Table

Django context processors are a foundational feature for sharing global variables across templates efficiently and cleanly in any scalable Django project.
https://docs.djangoproject.com/en/stable/ref/templates/api/#writing-your-own-context-processors
https://realpython.com/django-template-context-processors/

🧠 Smart Autosave: 💾 Leveraging localStorage Responsibly in a Multi-User World 🌍👥

Bharat Solanke — Thu, 10 Jul 2025 10:06:39 +0000

Autosave protects us from losing work due to crashes or power cuts. For one user, saving to localStorage works like magic. ✨
But in a multi-user app with logins and private data? 🤔 It can lead to serious problems—like saving someone else’s data by mistake. 😱 That's when localStorage's simplicity can turn into a head-scratching, data-leaking nightmare. 🤯

Join me on a journey through the evolution of an autosave feature, from its deceptively simple beginnings with client-side localStorage to a robust, secure system in a multi-user web application🕵️‍♀️

Part 1: The Initial Approach – localStorage Autosave (So Simple, So Tempting! 🍬)

When you hear "autosave," localStorage is often the first idea. Why not? It’s built-in, fast, persistent (even after browser restarts), and doesn’t need a server to work. 🙌

🔁 The Workflow:

User types → JS event (like oninput) triggers
Save draft → Stored in localStorage with a key
On reload → Check localStorage, repopulate field
On submit → Clear the saved draft

<form id="myOnlineEditorForm">
  <textarea id="editorContent" placeholder="Start writing..."></textarea>
</form>

<script>
  const key = 'document_draft_form_A';
  const textarea = document.getElementById('editorContent');

  document.addEventListener('DOMContentLoaded', () => {
    const draft = localStorage.getItem(key);
    if (draft) textarea.value = draft;
  });

  textarea.addEventListener('input', () => {
    localStorage.setItem(key, textarea.value);
  });

  document.getElementById('myOnlineEditorForm').addEventListener('submit', () => {
    localStorage.removeItem(key);
  });
</script>

✅ Why It Feels Great:

Fast ⚡ – No server, no delay
Simple 🧠 – Easy to implement
Offline-Friendly ✈️ – Works without internet

⚠️ But Here's the Catch:

Not User-Aware: Anyone on the same browser sees the same draft 😬
Device-Locked: No access across devices
Not Secure: No encryption—bad for sensitive data 🔓
Storage Limits: 5–10MB max
No Sync Logic: Doesn’t know if a newer draft exists elsewhere

It worked fine for a personal notepad. But once user accounts came into play, we realized: this approach wouldn’t cut it. It was time to go server-side. 💻🔐

Part 2: Backend to the Rescue – Secure, User-Specific Autosave 🌐🔐
localStorage was great… until users, sessions, and privacy came into play. To fix the limitations—like shared browser storage and lack of syncing—we brought in the backend as the single source of truth. ✅

🗂️ Backend Model
We created a UserDraft model with:

user_id → links the draft to the logged-in user
form_identifier → uniquely identifies the form/editor
draft_content → stores the actual draft (text or JSON)

🔌 APIs to Power Autosave

POST /api/save-draft/ → Save draft for the current user
GET /api/load-draft/{form_identifier}/ → Load user’s draft for that form

💡 Updated Frontend Workflow

On input: Send draft via AJAX to the backend
On load: Fetch draft from the server
If no server data? Fallback to localStorage… 😬

// Conceptual logic
if (serverDraft) {
    use(serverDraft);
} else if (localStorage.getItem(formIdentifier)) {
    use(localStorageDraft); // Just in case...
}

⚠️ The Sneaky Pitfall
This tiny fallback to localStorage seemed harmless—but it let old, possibly incorrect data sneak in. And that’s where things started getting tricky... 🕵️‍♀️💥

Part 3: The Problem Unveiled – Cross-User Data Leakage! 😱

Everything looked perfect—until we hit a chilling bug:
“User B is seeing User A’s draft!” 🤯

🧩 What Happened?

User A logs in and starts editing. Autosave stores the draft:
✅ On the server (tied to User A)
✅ In localStorage (document_draft_form_type_X)
User A logs out.
User B logs in on the same browser, opens the same editor.
Backend correctly returns no draft (User B hasn’t saved anything yet).
Our JS fallback kicks in:
“No server draft? Let’s check localStorage!”
🔥 Boom—User A’s draft shows up for User B.

🕵️ Root Cause: Misused Fallback + Persistent localStorage

localStorage belongs to the browser, not the user.
Our “if server returns nothing, use localStorage” logic backfired.
We accidentally loaded private data from one user into another’s session. 🚨

⚠️ Lesson Learned:
Even with perfect backend separation, client-side storage must be handled carefully in multi-user apps. A harmless fallback turned into a serious data leak. 🔒

Part 4: The Robust Solution – Server as Authority, Frontend as Smart Manager ✅

The fix was clear: the server must be the single source of truth for user data. localStorage? Just a fallback—for network issues only. 🔒

🧠 1. Smart Frontend Loading (Only Trust Server Data)
We rewrote our load logic to prioritize server data and treat localStorage as a last resort, never a fallback for "no server data."

async function loadAutosaveFromServerAndPopulate(formIdentifier) {
    try {
        const res = await fetch(`/api/load-draft/${formIdentifier}/`);
        const result = await res.json();

        if (res.ok && result.status === 'success') {
            if (result.data && Object.keys(result.data).length > 0) {
                localStorage.setItem(`autosave_${formIdentifier}`, JSON.stringify(result.data));
                populateFormFields(formIdentifier, result.data); // Server wins
            } else {
                localStorage.removeItem(`autosave_${formIdentifier}`); // Clean stale data
                populateFormFields(formIdentifier, {});
            }
        } else {
            throw new Error(result.message || 'Server error');
        }
    } catch (err) {
        console.error('Error fetching autosave:', err);
        const local = localStorage.getItem(`autosave_${formIdentifier}`);
        populateFormFields(formIdentifier, local ? JSON.parse(local) : {});
    }
}

🔁 localStorage is now only used when the server is unreachable, not when it simply returns no data.

🧹 2. Backend Cleanup on Final Submission
When a user submits the form, the server:
Saves the final document
Deletes any associated draft

def submit_final_document(request):
    submitted = parse_request_body(request)
    save_permanent_document_to_db(user=request.user, data=submitted)
    delete_user_draft_from_db(user_id=request.user.id, form_identifier=submitted.get('form_identifier'))
    return JsonResponse({"status": "success", "message": "Submitted & draft cleared."})

🧽 3. Frontend Cleanup on Submit & Logout
On Submit:

form.addEventListener("submit", () => {
    const formId = 'document_draft_form_type_A';
    localStorage.removeItem(`autosave_${formId}`);
});

On Logout:

function clearAllAutosaveLocalStorage() {
    Object.keys(localStorage).forEach((key) => {
        if (key.startsWith('autosave_')) localStorage.removeItem(key);
    });
}
// Attach to logout action:
// <a href="/logout/" onclick="clearAllAutosaveLocalStorage();">Logout</a>

✅ Conclusion: Trust the Server, Manage the Client Smartly! 💪
This journey brought some key lessons for building reliable web apps:
🛡️ Server is the Source of Truth

Always store user-specific or sensitive data on the backend—never rely on the browser alone.

💾 localStorage is a Resilience Layer

Use it only for temporary caching, and only when the network fails—not as a fallback for missing server data.

🧹 Clean Up Explicitly

Clear autosaved data after final submission and on logout—from both server and localStorage.

👥 Think Multi-User

Always account for multiple users sharing the same browser. Design your client-side logic accordingly.

By following these principles, your autosave system won’t just save work—it’ll protect privacy and deliver a seamless user experience.
Happy coding! 🚀👨‍💻

DEV Community: Bharat Solanke

Database Decoded: Navigating Queries in FastAPI & Django (ORM vs. Raw SQL) 🚀

The Big Three: SQLAlchemy, Django ORM, and Raw SQL 📊

Why Django's ORM Feels Different (and often magical ✨)

In Django:

In FastAPI with SQLAlchemy:

Optimization Masterclass: Squeezing Out Every Millisecond ⏱️

🚀 For SQLAlchemy (FastAPI):

Crush N+1 Queries (Your #1 Enemy! 😡)

Proper Session Management

🚂 For Django ORM:

select_related() for Foreign Keys (SQL JOINs)

prefetch_related() for Many-to-Many & Reverse Foreign Keys

.only() or .defer() to Limit Fields

🔥 For Raw SQL Queries (The "Break Glass" Option):

Parameterized Queries (SQL Injection Shield! 🛡️)

Connection Pooling

Explicit Columns (SELECT column1, column2 vs. SELECT *)

The Hybrid Approach: Your Foolproof Strategy 💡

✅ Start with the ORM (SQLAlchemy or Django ORM)

🧐 Optimize with ORM-specific Tools

⚡ Deploy Raw SQL Strategically

Final Thoughts

🔴 Redis: Complete Beginner to Advanced Guide (With Real Lessons From Major Attacks)

Introduction

What is Redis?

Why Redis is So Fast

Redis Data Storage Model

Redis Data Types

1. Strings

2. Lists

3. Sets

4. Sorted Sets

5. Hashes

6. Streams

7. Bitmaps and HyperLogLog

Redis Persistence

RDB (Snapshotting)

AOF (Append Only File)

Redis Streams (Event Streaming)

Features

Example Use Cases

Redis Geospatial

What It Supports

Example Use Cases

Real-World Redis Use Cases

1. Caching

2. Session Storage

3. Rate Limiting

4. Real-Time Analytics

5. Pub/Sub Messaging

6. Distributed Locks

Alternatives to Redis

Memcached

Apache Kafka

Hazelcast

Apache Ignite

Aerospike

Major Redis Security Attacks

Smominru Cryptomining Attack

What Happened?

Impact

Redis Ransomware Attacks

Why These Attacks Happened

Production Security Lessons

Enable Authentication

Restrict Network Access

Use Firewall Rules

Disable Dangerous Commands

Use Access Control Lists (ACL)

Never Run Redis as Root

When Should You Use Redis?

When Redis May Not Be the Best Choice

Final Thoughts

Conclusion

GitHub Is Not Just About Commands: How to Manage It Properly Like a Professional

1. GitHub Is a Project Timeline, Not a Backup Folder

2. Branches Represent Intent, Not Just Code

3. Never Treat main as a Playground

4. Small, Meaningful Commits Matter

3. Never Treat `main` as a Playground