Django signals vs API

Use case

Server A: django webapp, database

Server B: airflow

These 2 servers’ apps will work together using database as single source of truth.

Server A (django) will be responsible for creating the database records

Server B (airflow) will update the database records directly once certain job is completed

They are hosted on different servers as I want to split webapp (A) from data processing (B). Easier to scale.


  1. I can’t use django model signals (Signals | Django documentation | Django) such as post_save as Server B (airflow) update database record directly and not using django ORM

  2. I don’t think django request/response signals (Signals | Django documentation | Django) will be useful in this use case right?


I think the solution is to create a fastapi in server A.

Airflow will call server A’s fastapi once the job is completed instead of updating database record directly. Fastapi then call django ORM to update object, so that django signal receiver can execute the next action.


Is there a better solution?

Signal receiver can’t work like an API right?

Correct. Django signals exist strictly within a django process. They don’t even propagate between different Django processes running on the same server. They’re really just a glorified function call. (It might be easier to think about them as an “anonymous function” call rather than a true signal. Thinking about them in those terms may help remember their limitations as well.)

Unnecessary, and still isn’t going to propagate signals to your Django environment. (See above)

Django already exposes API facilities - they’re called “views”. Define your URL and view that you want Airflow to respond to, and perform the desired work in that view. You don’t even need signals in that situation.

Thanks! I am going to use views instead of signals / api