RQ and Django-RQ

RQ is a lightweight Python library for managing background tasks. It allows developers to offload time-consuming operations - such as sending emails, processing images, or performing heavy calculations - to background workers. These workers process the tasks asynchronously, improving the performance of your application by keeping the request-response cycle fast and responsive.

DjangoRQ is an integration package that simplifies using RQ with Django . It provides tools for managing task queues, workers, and even a built-in admin interface to monitor tasks.

Even though these two tools seem to be mutually exclusive, they are not. There is possibility to omit Django’s http server and relay all HTTP traffic to FastAPI’s ASGI application. These are the goals of the new package Django FastAPI Bridge

Wait, isn’t Django too old for FastAPI?

If you type “Django and fastapi” into Google you will get results that are simply misinformation. Speaking gently - they’re outdated or written by persons without an experience (a real plague these days):

O kiepskim podejściu do migracji schematów baz danych w Django pisałem już w 2014r. Co jakiś czas jednak temat do mnie wraca, gdyż w niektórych projektach używam (niestety) tego rozwiązania. Powody są różne, a główny to “oszczędność czasu”. No bo trudno zaprzeczyć, że automatyczne wygenerowanie plików z migracjami jest wolniejsze od klepania XML-i Liquibase lub plain SQL , prawda? Sam z tego przecież korzystam…

Jednak bywają takie momenty, gdzie zostaję z tymi migracjami w “czterech literach”, gdzie nawet nie dochodzi ani jeden promyk światła. I taką sytuacją jest m.in. usuwanie atrybutu z modelu, co generuje operację RemoveField.

Nie tak dawno temu wielu zarzucało Django , że w przeciwieństwie do Railsów nie posiada wbudowanego rozwiązania umożliwiającego wersjonowanie i modyfikowanie struktur bazodanowych. Niedługo po tym pojawił się South - dosyć obiecujące rozwiązanie, które oczywiście szybko przygarnąłem do projektów. Z czasem jednak okazało się, że architektura tego rozwiązania ma szereg wad.

Na południe

Podstawowym problemem a zarazem zaletą South jest związek migracji z aplikacjami Django . To poszczególne aplikacje są “dostawcami” migracji. Ma to na celu umożliwienie łatwiejszego utrzymania reusable apps, których upgrade w projektach był bez South bardzo trudny - wymagał poznania zmian struktury i własnoręcznego przygotowania skryptów SQL . O ile było to mozolne ale do zrobienia, to ustalenie migracji danych nie sposób było odtworzyć. Dzięki South sprawa się uprościła.

Prowadziliśmy swego czasu dyskusje o logice biznesowej i szukaliśmy rozwiązania starając się znaleźć jej miejsce w MVC . Stosując bowiem ten paradygmat logika naturalnie “rozmywa się” po kontrolerach i modelach (ekstremiści wstawiają ją nawet do widoków). Typowy przykład złego podejścia to kiepskie implementacje ORM (Propel - PHP , DjangoORM - Python ):

class User(Model):
    def save(*args, **kwargs):
        pass

W tym przypadku Model jest jednocześnie persistance managerem i wykonuje operacje, których nie powinien. Prawidłowe podejście to

class UserManager:
   def save(self, user):
       pass

Który kod łatwiej przetestować? Gdzie znajduje się logika zapisu stanu encji?