django-qstash 0.0.14__tar.gz → 0.0.15__tar.gz

{django_qstash-0.0.14 → django_qstash-0.0.15}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.2
 Name: django-qstash
-Version: 0.0.14
+Version: 0.0.15
 Summary: A drop-in replacement for Celery's shared_task with Upstash QStash.
 Author-email: Justin Mitchel <justin@codingforentrepreneurs.com>
 Project-URL: Changelog, https://github.com/jmitchel3/django-qstash
@@ -86,7 +86,9 @@ This allows us to:
     - [Arguments Must be JSON-ready](#arguments-must-be-json-ready)
     - [Example Task](#example-task)
   - [Management Commands](#management-commands)
-  - [Public Domain In Development](#public-domain-in-development)
+  - [Development](#development)
+    - [Development with a Public Domain](#development-with-a-public-domain)
+    - [Development with Docker Compose](#development-with-docker-compose)
   - [Django Settings Configuration](#django-settings-configuration)
     - [`DJANGO_QSTASH_DOMAIN`](#django_qstash_domain)
     - [`DJANGO_QSTASH_WEBHOOK_PATH`](#django_qstash_webhook_path)
@@ -319,15 +321,33 @@ _Requires `django_qstash.schedules` installed._
 - `python manage.py task_schedules --list` see all schedules relate to the `DJANGO_QSTASH_DOMAIN`
 - `python manage.py task_schedules --sync` sync schedules based on the `DJANGO_QSTASH_DOMAIN` to store in the Django Admin.
 
-## Public Domain In Development
+## Development
 
-django-qstash _requires_ a publicly accessible domain to work (e.g. `https://djangoqstash.com`). There are many ways to do this, we recommend:
+During development, you have two options:
+
+- Use Upstash.com with a publicly accessible domain (preferred)
+- Use Docker Compose with [compose.dev.yaml](./compose.dev.yaml)
+
+### Development with a Public Domain
+
+The closer your development environment is to production the better. For that reason, using a publicly accessible domain is the preferred with to develop with _django-qstash_.
+
+To get a public domain during development, we recommend any of the following:
 
 - [Cloudflare Tunnels](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) with a domain name you control.
 - [ngrok](https://ngrok.com/)
 
 Once you have a domain name, you can configure the `DJANGO_QSTASH_DOMAIN` setting in your Django settings.
 
+### Development with Docker Compose
+Upstash covers how to run QStash during development on [this guide](https://upstash.com/docs/qstash/howto/local-development)
+
+In our case we need to the following things:
+
+- `docker compose -f compose.dev.yaml up`
+- Add `QSTASH_URL=http://127.0.0.1:8585` to your `.env` file.
+- Use the `QSTASH_TOKEN`, `QSTASH_CURRENT_SIGNING_KEY`, and `QSTASH_NEXT_SIGNING_KEY` the terminal output of Docker compose _or_ the values listed in [compose.dev.yaml](./compose.dev.yaml).
+
 ## Django Settings Configuration
 
 Various options are available to configure django-qstash.
@@ -371,10 +391,13 @@ CSRF_TRUSTED_ORIGINS = [os.environ.get("CSRF_TRUSTED_ORIGIN")]
 ###########################
 # qstash-py settings
 ###########################
+USE_LOCAL_QSTASH = str(os.environ.get("USE_LOCAL_QSTASH")) == "1"
 QSTASH_TOKEN = os.environ.get("QSTASH_TOKEN")
 QSTASH_CURRENT_SIGNING_KEY = os.environ.get("QSTASH_CURRENT_SIGNING_KEY")
 QSTASH_NEXT_SIGNING_KEY = os.environ.get("QSTASH_NEXT_SIGNING_KEY")
-
+if DJANGO_DEBUG and USE_LOCAL_QSTASH:
+    # connect to the docker compose qstash instance
+    os.environ["QSTASH_URL"] = "http://127.0.0.1:8585"
 ###########################
 # django_qstash settings
 ###########################
@@ -511,7 +534,7 @@ I think serverless is the answer. Pay for what you use and scale to zero when yo
 
 Django can be serverless and is pretty easy to do thanks to Docker and the countless hosting options and services out there. Celery cannot be serverless, at least yet.
 
-Let's face it. Celery is a powerful tool to run async background tasks but it comes at a cost. It needs at least one server running 24/7. For best performance it needs 2 (one worker, one beat). It also needs Redis or RabbitMQ. Most background processes that are tied to web apps are not serverless; they have to "listen" for their next task.
+Let's face it. Celery is a powerful tool to run async background tasks but it comes at a cost. It needs at least one server running 24/7. For best performance, it needs 2 (one worker, one beat). It also needs Redis or RabbitMQ. In a traditional Django setup with Celery and Redis, you need to run 3 to 4 different processes. Most background processes that are tied to web apps are not serverless; they have to "listen" for their next task.
 
 To make Django truly scale-to-zero and serverless, we need to drop Celery.
 
@@ -525,4 +548,6 @@ It works by leveraging Upstash QStash to deliver messages about your tasks (e.g.
 >
 > Instead of calling an endpoint directly, QStash acts as a middleman between you and an API to guarantee delivery, perform automatic retries on failure, and more.
 
+Compared to a traditional setup with Django, Celery, and Redis, which requires 3 to 4 processes, you only need to run a single process and can delegate the rest to Upstash QStash, significantly simplifying your infrastructure.
+
 django-qstash has a webhook handler that converts a QStash message to run a specific `@shared_task` function (the one that called `.delay()` or `.apply_async()`). It's easy, it's cheap, it's effective, and best of all, it unlocks the scale-to-zero potential of Django as a serverless app.

{django_qstash-0.0.14 → django_qstash-0.0.15}/README.md

@@ -57,7 +57,9 @@ This allows us to:
     - [Arguments Must be JSON-ready](#arguments-must-be-json-ready)
     - [Example Task](#example-task)
   - [Management Commands](#management-commands)
-  - [Public Domain In Development](#public-domain-in-development)
+  - [Development](#development)
+    - [Development with a Public Domain](#development-with-a-public-domain)
+    - [Development with Docker Compose](#development-with-docker-compose)
   - [Django Settings Configuration](#django-settings-configuration)
     - [`DJANGO_QSTASH_DOMAIN`](#django_qstash_domain)
     - [`DJANGO_QSTASH_WEBHOOK_PATH`](#django_qstash_webhook_path)
@@ -290,15 +292,33 @@ _Requires `django_qstash.schedules` installed._
 - `python manage.py task_schedules --list` see all schedules relate to the `DJANGO_QSTASH_DOMAIN`
 - `python manage.py task_schedules --sync` sync schedules based on the `DJANGO_QSTASH_DOMAIN` to store in the Django Admin.
 
-## Public Domain In Development
+## Development
 
-django-qstash _requires_ a publicly accessible domain to work (e.g. `https://djangoqstash.com`). There are many ways to do this, we recommend:
+During development, you have two options:
+
+- Use Upstash.com with a publicly accessible domain (preferred)
+- Use Docker Compose with [compose.dev.yaml](./compose.dev.yaml)
+
+### Development with a Public Domain
+
+The closer your development environment is to production the better. For that reason, using a publicly accessible domain is the preferred with to develop with _django-qstash_.
+
+To get a public domain during development, we recommend any of the following:
 
 - [Cloudflare Tunnels](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) with a domain name you control.
 - [ngrok](https://ngrok.com/)
 
 Once you have a domain name, you can configure the `DJANGO_QSTASH_DOMAIN` setting in your Django settings.
 
+### Development with Docker Compose
+Upstash covers how to run QStash during development on [this guide](https://upstash.com/docs/qstash/howto/local-development)
+
+In our case we need to the following things:
+
+- `docker compose -f compose.dev.yaml up`
+- Add `QSTASH_URL=http://127.0.0.1:8585` to your `.env` file.
+- Use the `QSTASH_TOKEN`, `QSTASH_CURRENT_SIGNING_KEY`, and `QSTASH_NEXT_SIGNING_KEY` the terminal output of Docker compose _or_ the values listed in [compose.dev.yaml](./compose.dev.yaml).
+
 ## Django Settings Configuration
 
 Various options are available to configure django-qstash.
@@ -342,10 +362,13 @@ CSRF_TRUSTED_ORIGINS = [os.environ.get("CSRF_TRUSTED_ORIGIN")]
 ###########################
 # qstash-py settings
 ###########################
+USE_LOCAL_QSTASH = str(os.environ.get("USE_LOCAL_QSTASH")) == "1"
 QSTASH_TOKEN = os.environ.get("QSTASH_TOKEN")
 QSTASH_CURRENT_SIGNING_KEY = os.environ.get("QSTASH_CURRENT_SIGNING_KEY")
 QSTASH_NEXT_SIGNING_KEY = os.environ.get("QSTASH_NEXT_SIGNING_KEY")
-
+if DJANGO_DEBUG and USE_LOCAL_QSTASH:
+    # connect to the docker compose qstash instance
+    os.environ["QSTASH_URL"] = "http://127.0.0.1:8585"
 ###########################
 # django_qstash settings
 ###########################
@@ -482,7 +505,7 @@ I think serverless is the answer. Pay for what you use and scale to zero when yo
 
 Django can be serverless and is pretty easy to do thanks to Docker and the countless hosting options and services out there. Celery cannot be serverless, at least yet.
 
-Let's face it. Celery is a powerful tool to run async background tasks but it comes at a cost. It needs at least one server running 24/7. For best performance it needs 2 (one worker, one beat). It also needs Redis or RabbitMQ. Most background processes that are tied to web apps are not serverless; they have to "listen" for their next task.
+Let's face it. Celery is a powerful tool to run async background tasks but it comes at a cost. It needs at least one server running 24/7. For best performance, it needs 2 (one worker, one beat). It also needs Redis or RabbitMQ. In a traditional Django setup with Celery and Redis, you need to run 3 to 4 different processes. Most background processes that are tied to web apps are not serverless; they have to "listen" for their next task.
 
 To make Django truly scale-to-zero and serverless, we need to drop Celery.
 
@@ -496,4 +519,6 @@ It works by leveraging Upstash QStash to deliver messages about your tasks (e.g.
 >
 > Instead of calling an endpoint directly, QStash acts as a middleman between you and an API to guarantee delivery, perform automatic retries on failure, and more.
 
+Compared to a traditional setup with Django, Celery, and Redis, which requires 3 to 4 processes, you only need to run a single process and can delegate the rest to Upstash QStash, significantly simplifying your infrastructure.
+
 django-qstash has a webhook handler that converts a QStash message to run a specific `@shared_task` function (the one that called `.delay()` or `.apply_async()`). It's easy, it's cheap, it's effective, and best of all, it unlocks the scale-to-zero potential of Django as a serverless app.

{django_qstash-0.0.14 → django_qstash-0.0.15}/pyproject.toml

@@ -6,7 +6,7 @@ requires = [
 
 [project]
 name = "django-qstash"
-version = "0.0.14"
+version = "0.0.15"
 description = "A drop-in replacement for Celery's shared_task with Upstash QStash."
 readme = "README.md"
 license = { file = "LICENSE" }

{django_qstash-0.0.14 → django_qstash-0.0.15}/src/django_qstash/__init__.py

@@ -1,6 +1,6 @@
 from __future__ import annotations
 
-__version__ = "0.0.14"
+__version__ = "0.0.15"
 
 from django_qstash.app import shared_task
 from django_qstash.app import stashed_task

django_qstash-0.0.15/src/django_qstash/client.py

@@ -0,0 +1,25 @@
+from __future__ import annotations
+
+import os
+import warnings
+
+from qstash import QStash
+
+from django_qstash.settings import QSTASH_TOKEN
+
+QSTASH_URL = os.environ.get("QSTASH_URL", None)
+
+
+def init_qstash():
+    kwargs = {
+        "token": QSTASH_TOKEN,
+    }
+    if QSTASH_URL is not None:
+        warning_msg = f"\n\n\033[93mUsing {QSTASH_URL} as your QStash URL. \
+            \nThis configuration should only be used in development.\n\033[0m"
+        warnings.warn(warning_msg, RuntimeWarning, stacklevel=2)
+        kwargs["base_url"] = QSTASH_URL
+    return QStash(**kwargs)
+
+
+qstash_client = init_qstash()

{django_qstash-0.0.14 → django_qstash-0.0.15}/src/django_qstash/settings.py

@@ -11,7 +11,7 @@ DJANGO_QSTASH_WEBHOOK_PATH = getattr(
 )
 if not QSTASH_TOKEN or not DJANGO_QSTASH_DOMAIN:
     warnings.warn(
-        "QSTASH_TOKEN and DJANGO_QSTASH_DOMAIN should be set for QStash functionality",
+        "DJANGO_SETTINGS_MODULE (settings.py required) requires QSTASH_TOKEN and DJANGO_QSTASH_DOMAIN should be set for QStash functionality",
         RuntimeWarning,
         stacklevel=2,
     )

{django_qstash-0.0.14 → django_qstash-0.0.15}/src/django_qstash.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.2
 Name: django-qstash
-Version: 0.0.14
+Version: 0.0.15
 Summary: A drop-in replacement for Celery's shared_task with Upstash QStash.
 Author-email: Justin Mitchel <justin@codingforentrepreneurs.com>
 Project-URL: Changelog, https://github.com/jmitchel3/django-qstash
@@ -86,7 +86,9 @@ This allows us to:
     - [Arguments Must be JSON-ready](#arguments-must-be-json-ready)
     - [Example Task](#example-task)
   - [Management Commands](#management-commands)
-  - [Public Domain In Development](#public-domain-in-development)
+  - [Development](#development)
+    - [Development with a Public Domain](#development-with-a-public-domain)
+    - [Development with Docker Compose](#development-with-docker-compose)
   - [Django Settings Configuration](#django-settings-configuration)
     - [`DJANGO_QSTASH_DOMAIN`](#django_qstash_domain)
     - [`DJANGO_QSTASH_WEBHOOK_PATH`](#django_qstash_webhook_path)
@@ -319,15 +321,33 @@ _Requires `django_qstash.schedules` installed._
 - `python manage.py task_schedules --list` see all schedules relate to the `DJANGO_QSTASH_DOMAIN`
 - `python manage.py task_schedules --sync` sync schedules based on the `DJANGO_QSTASH_DOMAIN` to store in the Django Admin.
 
-## Public Domain In Development
+## Development
 
-django-qstash _requires_ a publicly accessible domain to work (e.g. `https://djangoqstash.com`). There are many ways to do this, we recommend:
+During development, you have two options:
+
+- Use Upstash.com with a publicly accessible domain (preferred)
+- Use Docker Compose with [compose.dev.yaml](./compose.dev.yaml)
+
+### Development with a Public Domain
+
+The closer your development environment is to production the better. For that reason, using a publicly accessible domain is the preferred with to develop with _django-qstash_.
+
+To get a public domain during development, we recommend any of the following:
 
 - [Cloudflare Tunnels](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) with a domain name you control.
 - [ngrok](https://ngrok.com/)
 
 Once you have a domain name, you can configure the `DJANGO_QSTASH_DOMAIN` setting in your Django settings.
 
+### Development with Docker Compose
+Upstash covers how to run QStash during development on [this guide](https://upstash.com/docs/qstash/howto/local-development)
+
+In our case we need to the following things:
+
+- `docker compose -f compose.dev.yaml up`
+- Add `QSTASH_URL=http://127.0.0.1:8585` to your `.env` file.
+- Use the `QSTASH_TOKEN`, `QSTASH_CURRENT_SIGNING_KEY`, and `QSTASH_NEXT_SIGNING_KEY` the terminal output of Docker compose _or_ the values listed in [compose.dev.yaml](./compose.dev.yaml).
+
 ## Django Settings Configuration
 
 Various options are available to configure django-qstash.
@@ -371,10 +391,13 @@ CSRF_TRUSTED_ORIGINS = [os.environ.get("CSRF_TRUSTED_ORIGIN")]
 ###########################
 # qstash-py settings
 ###########################
+USE_LOCAL_QSTASH = str(os.environ.get("USE_LOCAL_QSTASH")) == "1"
 QSTASH_TOKEN = os.environ.get("QSTASH_TOKEN")
 QSTASH_CURRENT_SIGNING_KEY = os.environ.get("QSTASH_CURRENT_SIGNING_KEY")
 QSTASH_NEXT_SIGNING_KEY = os.environ.get("QSTASH_NEXT_SIGNING_KEY")
-
+if DJANGO_DEBUG and USE_LOCAL_QSTASH:
+    # connect to the docker compose qstash instance
+    os.environ["QSTASH_URL"] = "http://127.0.0.1:8585"
 ###########################
 # django_qstash settings
 ###########################
@@ -511,7 +534,7 @@ I think serverless is the answer. Pay for what you use and scale to zero when yo
 
 Django can be serverless and is pretty easy to do thanks to Docker and the countless hosting options and services out there. Celery cannot be serverless, at least yet.
 
-Let's face it. Celery is a powerful tool to run async background tasks but it comes at a cost. It needs at least one server running 24/7. For best performance it needs 2 (one worker, one beat). It also needs Redis or RabbitMQ. Most background processes that are tied to web apps are not serverless; they have to "listen" for their next task.
+Let's face it. Celery is a powerful tool to run async background tasks but it comes at a cost. It needs at least one server running 24/7. For best performance, it needs 2 (one worker, one beat). It also needs Redis or RabbitMQ. In a traditional Django setup with Celery and Redis, you need to run 3 to 4 different processes. Most background processes that are tied to web apps are not serverless; they have to "listen" for their next task.
 
 To make Django truly scale-to-zero and serverless, we need to drop Celery.
 
@@ -525,4 +548,6 @@ It works by leveraging Upstash QStash to deliver messages about your tasks (e.g.
 >
 > Instead of calling an endpoint directly, QStash acts as a middleman between you and an API to guarantee delivery, perform automatic retries on failure, and more.
 
+Compared to a traditional setup with Django, Celery, and Redis, which requires 3 to 4 processes, you only need to run a single process and can delegate the rest to Upstash QStash, significantly simplifying your infrastructure.
+
 django-qstash has a webhook handler that converts a QStash message to run a specific `@shared_task` function (the one that called `.delay()` or `.apply_async()`). It's easy, it's cheap, it's effective, and best of all, it unlocks the scale-to-zero potential of Django as a serverless app.

django_qstash-0.0.14/src/django_qstash/client.py

@@ -1,7 +0,0 @@
-from __future__ import annotations
-
-from qstash import QStash
-
-from django_qstash.settings import QSTASH_TOKEN
-
-qstash_client = QStash(QSTASH_TOKEN)