DEV Community: Saleh Azimidokht

I Built a Signed Webhook Receiver for Cross-Server Communication

Saleh Azimidokht — Tue, 11 Aug 2026 12:05:48 +0000

Sometimes your application can reach an external service from one server, but not from another.

I ran into this problem while working on one of my projects. I needed my server in Iran to communicate with Telegram, but the connection wasn't reliable from inside Iran.

Instead of moving the whole application, I built a small intermediate service:

Signed Webhook Receiver

It is a lightweight FastAPI service that receives requests signed with an RSA private key and verifies them using the corresponding public key before processing them.

Your Server
     |
     | RSA Signed Request
     v
Webhook Receiver
     |
     | HTTP Request
     v
External Service

The receiver can be useful for:

Secure server-to-server communication
Webhooks and internal APIs
Acting as a controlled proxy/gateway
Connecting servers across different network environments
Payment integrations where a provider requires requests from an Iranian IP

For example, if your main application is hosted outside Iran but a payment gateway only accepts requests from Iranian IP addresses, an Iranian server can act as the intermediate gateway:

Foreign Server
      |
      | Signed Request
      v
Iranian Gateway Server
      |
      v
Payment Gateway

The important part is that this isn't an open proxy. Requests can be authenticated and the gateway can be restricted to specific operations and destinations.

The project is built with Python, FastAPI, Cryptography, Docker, and Traefik and is open source.

View the project on GitHub

I also wrote more technical notes and development articles on my website:

Building a Secure Webhook Receiver for Server-to-Server Communication | CyberHuginn

Designing a Gold Jewelry E-Commerce Database with Django

Saleh Azimidokht — Tue, 04 Aug 2026 05:04:51 +0000

When I accepted a project to build an online gold jewelry store, I thought it would be just another e-commerce platform.

Products. Orders. Payments.

Nothing unusual.

I couldn't have been more wrong.

A few hours into the database design, I realized the real challenge wasn't Django—it was understanding the business.

Unlike a regular online store, customers aren't buying a generic product. They're buying a very specific variation of that product.

A single ring, for example, can exist in multiple versions:

Different weights
Different karats
Different sizes
Different gemstones
Different making fees
Different prices
Different inventory

That simple observation completely changes how your database should be designed.

The Common Mistake

Many developers model their orders like this:

Order
 └── Product

That works perfectly for books, digital products, or simple inventory.

It completely falls apart for jewelry.

Because the customer isn't purchasing the Product.

They're purchasing one specific variation of that product.

The Missing Model

Instead of attaching orders directly to Product, I introduced another layer:

Product
    └── ProductVariable
            ├── Price
            ├── Stock
            ├── Making Fee
            ├── Weight
            ├── Karat
            └── Attributes

Now every purchasable item has its own inventory, pricing, and specifications while still belonging to the same parent product.

This approach also makes searching and filtering much easier because attributes become reusable across multiple products.

Start From Business Scenarios

Before writing models, I always walk through real business scenarios.

Questions like:

What exactly is the customer buying?
Can inventory differ between variations?
Can price change based on weight?
What happens when an item is out of stock?
Can customers order custom-made jewelry?

Those questions usually define your entities long before you write your first Django model.

This article only scratches the surface.

In the full version, I explain:

How to identify entities using Use Cases
Building an ER Diagram
Designing Django models
Modeling ProductVariable
Categories vs Tags
Product Attributes
Inventory management
Ordering and payment architecture
Real-world jewelry business scenarios

👉 Read the complete article here:

https://cyberhuginn.com/notes/designing-a-gold-jewelry-ecommerce-database-with-django

If you're building an e-commerce platform with Django, especially one that sells configurable products, this design pattern can save you from painful database refactoring later.

Why Every Small SaaS Needs Uptime Monitoring

Saleh Azimidokht — Sat, 01 Aug 2026 17:34:22 +0000

Building software has never been easier.

Keeping it online is the hard part.

Whether you're running a personal project, an internal API, a startup MVP, or a growing SaaS business, downtime can quickly become expensive. Users lose trust, support requests increase, and revenue disappears while you're unaware that something has gone wrong.

The worst part?

Most outages aren't discovered by monitoring systems.

They're discovered by users.

That realization is exactly what led me to build Bidar—a lightweight uptime monitoring platform focused on one simple goal:

Notify developers as soon as their services become unavailable.

The Hidden Cost of Downtime

It's easy to think of downtime as "just a server issue."

In reality, the impact is much broader.

Even a short outage can affect:

User trust
Customer satisfaction
Conversion rates
Search rankings
Team productivity
Brand reputation

Your users don't care whether the issue was caused by a failed deployment, DNS problem, database outage, or cloud provider incident.

They only know one thing:

Your service wasn't available when they needed it.

Why Manual Monitoring Doesn't Scale

In the beginning, many developers rely on manual checks.

They refresh the website.

They test an API endpoint.

They occasionally check server metrics.

That works for hobby projects.

It stops working when real users depend on your application.

You can't monitor your services 24 hours a day.

You can't wake up every hour to verify your API is still responding.

Automation eventually becomes a necessity.

What Should You Monitor?

A good monitoring solution should cover more than just your homepage.

Some of the most valuable things to monitor include:

Website availability
REST API endpoints
SSL certificate expiration
Response time
HTTP status codes
Critical customer-facing pages
Internal services

Monitoring the right endpoints allows you to detect problems before your customers notice them.

What Makes a Good Monitoring Tool?

After working on several backend systems, I've found that a monitoring solution doesn't need hundreds of features.

It needs to do a few things really well.

Fast Detection

The sooner you're notified, the sooner you can fix the issue.

Reliable Alerts

Notifications should arrive immediately through the channels you actually use.

Easy Setup

Monitoring should take minutes—not hours.

Clear Results

The goal isn't generating pretty dashboards.

The goal is answering one question:

Is my service healthy?

Why I Built Bidar

While working on Django projects and APIs, I wanted a monitoring service that focused on uptime instead of trying to be a complete observability platform.

Many existing tools are incredibly powerful.

They also come with dozens of dashboards, metrics, traces, and features that smaller teams often don't need.

So I built Bidar.

Its philosophy is simple:

Add your website or API.
Configure monitoring.
Get notified when something goes wrong.

That's it.

No unnecessary complexity.

Just reliable uptime monitoring.

Who Is It For?

Bidar is especially useful for:

Indie Hackers
SaaS founders
Freelancers managing client websites
Small development teams
Backend developers
Anyone running production APIs

If uptime matters to your users, monitoring should matter to you.

Final Thoughts

Reliable software isn't just about writing good code.

It's also about knowing when things stop working.

Monitoring helps you detect issues faster, reduce downtime, and respond before your users start sending emails asking if your service is down.

If you're looking for a lightweight uptime monitoring platform, I'd love for you to check out Bidar.

🌐 Website: https://bidarhq.ir

I'm always looking for feedback from developers.

If there's a feature you'd like to see, let me know!

About the Author

I'm a backend developer focused on Django, distributed systems, developer tools, and open-source software.

Website: https://cyberhuginn.com

GitHub: https://github.com/cyberhuginn

I Built a Lightweight Health Check Package for Django

Saleh Azimidokht — Sat, 01 Aug 2026 17:30:06 +0000

While working on several Django projects, I often needed a simple endpoint to verify that the application was actually healthy—not just running.

Most existing solutions were either too heavy, required extra configuration, or didn’t provide the flexibility I wanted.

So I built django-healthkit.

What it does

The package lets you expose a health endpoint that can verify different parts of your application.

Current checks include:

Database connectivity
Cache availability
Disk usage
Memory usage
CPU usage

Configuration is intentionally simple:

HEALTH_CHECKS = [
    "database",
    "cache",
    "disk",
    "memory",
    "cpu",
]

Then expose the endpoint and you're ready to use it with:

Docker health checks
Kubernetes probes
Traefik
Nginx
Monitoring systems
Uptime monitoring services

Why I built it

My goal wasn't to create another monitoring platform.

I wanted a small package that answers one simple question:

Is my Django application actually healthy?

No dashboards.

No unnecessary dependencies.

Just a clean JSON response that can be consumed by automation.

What's next?

This is only the first release.

Some ideas planned for future versions:

Custom health checks
Async support
Response customization
More built-in system checks
Better integrations with monitoring tools

I'd love your feedback

If you're using Django, I'd really appreciate your thoughts.

What health checks are missing?
What features would make this useful in production?
Any ideas for improving the API?

About the author