# Django signals vs API

**URL:** <https://forum.djangoproject.com/t/django-signals-vs-api/16388>\
**Category:** Forms & APIs\
**Created:** [October 9, 2022, 2:52am UTC](https://forum.djangoproject.com/t/django-signals-vs-api/16388 "2022-10-09T02:52:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![shawnngtq](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/shawnngtq/32/5834_2.png) [@shawnngtq](https://forum.djangoproject.com/u/shawnngtq)\
**Post date:** [October 9, 2022, 2:52am UTC](https://forum.djangoproject.com/t/django-signals-vs-api/16388/1 "2022-10-09T02:52:59Z")

</div>

## 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.

## Challenge

1. I can’t use django model signals ([Signals | Django documentation | Django](https://docs.djangoproject.com/en/4.1/ref/signals/#module-django.db.models.signals)) 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](https://docs.djangoproject.com/en/4.1/ref/signals/#module-django.core.signals)) will be useful in this use case right?

## Solution

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.

## Question

Is there a better solution?

Signal receiver can’t work like an API right?

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [October 9, 2022, 3:30am UTC](https://forum.djangoproject.com/t/django-signals-vs-api/16388/2 "2022-10-09T03:30:40Z")

</div>

> [@shawnngtq](#):
>
> I don’t think django request/response signals ([Signals | Django documentation | Django](https://docs.djangoproject.com/en/4.1/ref/signals/#module-django.core.signals)) will be useful in this use case 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.)

> [@shawnngtq](#):
>
> I think the solution is to create a fastapi in server A.

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.

---

<div class="post-metadata">

**Author:** ![shawnngtq](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/shawnngtq/32/5834_2.png) [@shawnngtq](https://forum.djangoproject.com/u/shawnngtq)\
**Post date:** [October 9, 2022, 5:43am UTC](https://forum.djangoproject.com/t/django-signals-vs-api/16388/3 "2022-10-09T05:43:26Z")

</div>

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