DEV Community: Arslon Erkinov

Today’s Progress Update — Food Blog Project

Arslon Erkinov — Mon, 20 Apr 2026 18:15:16 +0000

A productive day working on my Food Blog Platform 🍰

Here’s what I accomplished today:

🔹 Improved recipe listing performance and fixed filtering edge cases
🔹 Enhanced live search functionality (faster + more stable results)
🔹 Fixed pagination behavior with category filters
🔹 Polished UI elements (spacing, hover effects, responsiveness)
🔹 Improved like system stability and animation consistency
🔹 Refactored parts of the Django views for cleaner structure

💡 Small but important step toward a more scalable and production-ready project.

Each improvement brings the platform closer to a real-world product experience 🚀

Next steps:
➡️ User authentication system
➡️ Favorites/bookmarks feature
➡️ Deployment setup

Python #Django #FullStack #WebDevelopment #100DaysOfCode #FoodTech

Day 18 — Migrating Django Rate Limiting to Redis (Production Architecture)

Arslon Erkinov — Tue, 10 Mar 2026 13:59:52 +0000

Today I moved my Django REST API from in-memory throttling to Redis-based rate limiting.

Why?

Because in-memory rate limiting (LocMemCache):
Breaks in multi-instance deployments
Doesn’t scale horizontally
Is not production-safe

What I implemented:

✅ Redis-based Rate Limiter
Atomic counters
Plan-based limits
24-hour TTL
Proper 429 response handling
Usage tracking even on failures

Remaining requests exposed via header

✅ Clean Architecture
Removed legacy limiter file
Removed duplicate imports
Centralized rate limiting logic
Clean exception handling using DRF Throttled

✅ Observability
Usage logging for 200 / 400 / 429 responses
Redis debug endpoint for monitoring rate keys
Ready for SaaS analytics layer

Now the backend is:
Horizontally scalable
Cloud-ready
Production-safe
Clean and maintainable

This is how you build infrastructure before UI.
Next step: more backend hardening before moving to interface.

Day 17 – Building SaaS-Grade Analytics for My AI Phishing Defense Platform

Arslon Erkinov — Mon, 02 Mar 2026 21:40:16 +0000

Today I focused entirely on backend robustness.

Instead of jumping to UI, I strengthened the analytics layer.

What I Added
1️⃣ API Usage Monitoring
Status codes
Request latency (ms)
Per-API-key tracking
Error rate calculation

2️⃣ Risk Intelligence Metrics
High / Medium / Low distribution
Risk percentage breakdown
7-day usage trends
Average risk score over time

3️⃣ Performance Metrics
Average latency
Error rate (%)
Per-plan breakdown
Real Bug I Faced
I hit this error:

sqlite3.OperationalError: no such column: analyzer_apiusage.latency_ms

The model was updated, but the database schema wasn’t.
Classic migration issue.

The fix:
Run makemigrations
Run migrate
Ensure correct module imports in models/init.py

Lesson:
Your ORM and your DB schema must always stay aligned.
Why This Matters
Before building UI, backend must be stable.

Now the system:
Tracks performance
Measures abuse
Prepares for production
Supports SaaS analytics dashboards

Next step: Backend hardening before frontend.
Security is not just detection — it’s architecture.

django #ai #cybersecurity #backend #saas

Building a Real Analytics Engine in Django (AI Security SaaS)

Arslon Erkinov — Wed, 25 Feb 2026 17:32:40 +0000

Today I implemented a production-style analytics layer for my AI Phishing Defense Platform.

What was added?
Global Usage Metrics
Total requests
Requests today

Risk Distribution

High / Medium / Low counts
Percentage breakdown
Product-ready formatting

Daily Usage Trend

Using:

TruncDate + Count
This produces a 7-day usage trend that can directly power charts.

Per-User Stats

Each PRO API key now sees:
Its own total request count

Clean JSON Structure

Instead of returning flat data, the response is structured for dashboards:

{
"global_stats": {...},
"risk_distribution": {...},
"usage_by_plan": {...},
"daily_usage_trend": [...],
"my_usage": {...}
}

This makes frontend integration trivial.

Architectural Takeaway

Good analytics endpoints are:
Aggregated at DB level
Role-protected
Plan-aware
Structurally clean
Frontend-ready

This project is now evolving from an API experiment into a monetizable security SaaS.

Next milestone:
Latency tracking + error rate monitoring.

Day 17 — Building PRO-Only Analytics in a Django SaaS Platform

Arslon Erkinov — Tue, 24 Feb 2026 22:23:52 +0000

Today I implemented role-based access control for analytics in my AI Phishing Defense Platform.

What was the goal?

Allow only PRO and ENTERPRISE API keys to access advanced usage statistics.

What was implemented?

Custom API Key Authentication

Instead of default DRF token auth, I built a custom:

class APIKeyAuthentication(BaseAuthentication)

It reads:

X-API-Key: <key>

And attaches:

request.api_key

to the request.

Important lesson:
Authentication must be side-effect free.
No DB updates inside authenticate().

Custom Permission Layer
class ProPlanOnly(BasePermission)

Checks:

API key exists
Key is active
Plan is in ("pro", "enterprise")

This creates clean separation:

Authentication → Who are you?
Permission → Are you allowed here?

Usage Tracking System

Every request now logs:

endpoint
method
status code
timestamp
API key reference

This enables real SaaS metrics later.

Real Bug Found & Fixed
I accidentally had duplicate URL routes:

analytics/usage/

Django resolves first match only.

Lesson learned:
URL duplication silently overrides logic.

Architecture Now

*Anonymous *→ basic limited access
*Free *→ tracked analysis
*Pro *→ analysis + analytics

This project is evolving from a demo into a monetizable security SaaS.

Tomorrow: analytics expansion layer.

From String Fields to Real Architecture — Fixing Audit Logging in Django

Arslon Erkinov — Fri, 13 Feb 2026 20:35:23 +0000

Today I closed Day 17 — Part 1 of my AI Phishing Defense Platform.

The system was “working”… but architecturally wrong.
The Problem
Audit logs were storing API keys as plain strings.

That breaks:

relational integrity
analytics joins
usage aggregation
long-term scalability

It looked like this:
api_key = models.CharField(max_length=64)

That’s not production-grade.

The Refactor

I replaced it with:

api_key = models.ForeignKey( APIKey, null=True, blank=True, on_delete=models.SET_NULL, )

This allowed:

proper usage aggregation
accurate plan tracking
clean JOIN queries
future-ready analytics

What Broke

As expected, migrations and existing logic exploded:
ForeignKey assignment errors
IntegrityError on status_code
Rate limit filters pointing to wrong fields
Audit logger passing strings instead of instances
This is normal when upgrading architecture.

What Was Fixed
• Correct FK assignment
• Refactored log_audit_event
• Unified rate limit logic
• Clean APIUsage logging
• Plan-aware audit entries

Now the system tracks:

Anonymous
Free
Pro
Status codes
Daily usage
Endpoint analytics

Lesson

Don’t build demos.
Build systems that survive refactoring.
Architecture debt always shows up later.

Day 17 is about backend maturity.
Tomorrow: analytics expansion layer.

Day 16 (Part 4 & Part 5): Audit Logs, Migrations, and Stability

Arslon Erkinov — Mon, 09 Feb 2026 19:23:58 +0000

Day 16 (Part 4 & Part 5): Audit Logs, Migrations, and Stability

Today’s work was about making the backend reliable, not just functional.

I focused on:

Designing a proper AuditLog model
Migrating from a raw field to a ForeignKey relationship
Dealing with broken migrations after schema changes
Resetting and rebuilding the database cleanly
Verifying audit logging through real request simulations

This part of the project reinforced an important lesson:
backend engineering isn’t only about writing new code —
it’s about maintaining data integrity as the system evolves.

With Day 16 fully completed (Part 4 & 5),
I’m ready to move forward to Day 17, where I’ll work on:

Rate limiting
API quotas
Usage tracking

Thanks for following along 🚀

Designing a Production-Grade API Control Layer

Arslon Erkinov — Fri, 06 Feb 2026 21:35:03 +0000

Day 16 · Part 4 — Designing a Production-Grade API Control Layer

In this stage of the project, I focused on something many apps postpone — API control and observability.

What I implemented:

🔐 Authentication

API key–based auth
Unified request contract (request.api_key_obj)
No implicit globals or hidden state

🛂 Permissions

Plan-aware permissions (Pro / Enterprise only)
Explicit access boundaries at the view level

🚦 Rate Limiting

Daily limits per API key
Plan-driven quotas
Cache-backed, deterministic, testable

📜 Audit Logging

Target hashing (privacy by design)
IP masking
Immutable audit records
Zero dependency on views’ internal logic

The key architectural rule:

Views should not “know” how security works — they should only consume it.

This makes the system:

safer to evolve
easier to test
compliant with real security audits

Day 16 · Part 4 is complete.
Next step: usage tracking & billing foundations.

Hardening a Security API with DRF Serializers

Arslon Erkinov — Tue, 03 Feb 2026 11:46:27 +0000

Day 16: Hardening a Security API with DRF Serializers

Wrapped up Day 16 / Part 3 of my AI Phishing Defense Platform.

This stage was about cleaning up the API layer and making it production-ready:

Key changes

Replaced manual request parsing with DRF serializers
Enforced strict URL validation at the framework level
Unified error handling (serializer.errors)
Ensured audit logs are written only after successful validation
All tests passing ✔️

Why serializers matter more than people think:
In security-related APIs, accepting malformed input silently is a bug — not a feature.
Serializers give:

deterministic validation

consistent error contracts

safer evolution of the API

No ML yet. No hype.
Just building the foundation correctly.

Next (Day 16 / Part 4):
rate limits, permissions, and real-world abuse protection.

Designing Analytics for a Security-Focused Django API Day 15

Arslon Erkinov — Fri, 30 Jan 2026 10:10:32 +0000

Today I focused on the analytics and internal observability of my phishing detection platform.

Key takeaways from this stage:

Analytics should live separately from core business logic
URL routing clarity prevents long-term technical debt
API-key–scoped statistics are critical for SaaS-style products
Import errors are often symptoms of deeper architectural problems

Implemented:

Usage stats by plan
Risk score aggregation
Verdict distribution
Admin vs user-level analytics separation

This wasn’t about shipping fast —
it was about making sure the system can be trusted, monitored, and extended.

Next: testing and public-facing API improvements.

AI Phishing Defense Platform Day 13

Arslon Erkinov — Wed, 28 Jan 2026 19:11:46 +0000

Day 13 completed: API Security & Usage Tracking

Today I finished Day 13 of building my AI Phishing Defense Platform.
What’s implemented:
✅ API Keys (per user)
✅ Endpoint protection
✅ Custom rate limiting (production-ready, no third-party magic)
✅ API usage tracking (endpoint, method, time)
✅ Architecture ready for SaaS billing & plans

This is no longer a “pet project”.
It’s a real API product foundation — scalable, secure, and measurable.

Next step:
📊 Plans, quotas, admin dashboard, and SaaS polish.

I’m building this long-term with a clear goal:
strong portfolio, real users, and global impact.

AI Phishing Defense Platform Day 14

Arslon Erkinov — Wed, 28 Jan 2026 19:08:30 +0000

Day 14 completed — AI Phishing Defense Platform

I’m building an enterprise-ready phishing detection platform focused on real-world security, not demos.

What’s already implemented:
• API-first architecture with API keys
• Rate limiting & abuse protection
• Multi-layer URL analysis (heuristics + AI scoring + reputation)
• Explainable threat reports (human-readable & technical)
• Usage analytics and observability mindset

This project is designed with a security-first approach:
• No implicit trust in user input
• Explainable verdicts for audit & compliance
• Monitoring for false positives, latency, and abuse

Goal: build a real-world security platform that could operate at scale for developers, SOC teams, and businesses.

More coming soon — Day 15 will focus on detection depth and explainability.

Хэштег#CyberSecurity Хэштег#AI Хэштег#Phishing Хэштег#Django Хэштег#SecurityEngineering Хэштег#Startup Хэштег#OpenToWork