I've been deep-diving into Django REST Framework and Django Q2 recently to better understand asynchronous task handling. While studying the internal models, I hit a friction point: monitoring tasks always required logging into the Django Admin. I wanted to see if I could decouple this and expose the queue data via a standard API to build custom dashboards.
So, I built django-q-monitor as a solution.
It wraps the Q2 models to provide:
1. Read-only JSON endpoints for Tasks and Schedules.
2. Action endpoints to Retry or Cleanup tasks (using DRF ViewSets).
3. Configurable permissions (so you don't actually need to be an Admin to monitor tasks).
Since I'm new to the open-source community, I treated this as an exercise to learn proper packaging (pyproject.toml) and API design. I'd really appreciate any feedback on the code structure or best practices I might have missed.
previa1998•52m ago
This is officially my first open-source package.
I've been deep-diving into Django REST Framework and Django Q2 recently to better understand asynchronous task handling. While studying the internal models, I hit a friction point: monitoring tasks always required logging into the Django Admin. I wanted to see if I could decouple this and expose the queue data via a standard API to build custom dashboards.
So, I built django-q-monitor as a solution.
It wraps the Q2 models to provide: 1. Read-only JSON endpoints for Tasks and Schedules. 2. Action endpoints to Retry or Cleanup tasks (using DRF ViewSets). 3. Configurable permissions (so you don't actually need to be an Admin to monitor tasks).
Since I'm new to the open-source community, I treated this as an exercise to learn proper packaging (pyproject.toml) and API design. I'd really appreciate any feedback on the code structure or best practices I might have missed.
Docs/Code: https://github.com/previa1998/django-q-monitor