Hello everyone,
(Quick Note on the Post: Please accept my apologies—I accidentally deleted this post immediately after I first published it. I am reposting the original announcement here, along with a clarification section addressing the excellent initial feedback I received! Thanks for your understanding.)
I'm a big fan of Node-RED and use it for many of my IoT projects. As my projects started to grow, I ran into some common challenges, especially around managing complex user permissions and figuring out how to scale horizontally across multiple Node-RED instances.
To try and solve this for myself, I've been working on an open-source project that connects Node-RED to a Django backend. I'm calling it Quack Quack , and I wanted to share it here to get your thoughts and feedback.
The main goal was to let Django handle the things it's great at, so Node-RED can focus on the flow logic.
Here are the main problems I was trying to solve:
1. Granular Permissions: I needed more than a simple admin/user role. The idea was to control access for each individual sensor or switch. For example, letting an "engineer" change a value while a "supervisor" can only view it. The Django backend manages this with a full Role-Based Access Control (RBAC) system.
2. Scaling: If you run multiple Node-RED instances to handle many devices, keeping user permissions and state synchronized is difficult. The Django backend acts as a single, central place for all users and device states, so you can spin up as many stateless Node-RED instances as you need.
3. Flexible UI: I didn't want to be locked into a specific dashboard. The backend provides a clean WebSocket API, so you're free to build any front-end you like (React, Vue, or just simple HTML/JS). I made a simple vanilla JS dashboard just to show it works.
To get started, you only need to focus on two simple, well-documented APIs: one for the browser (the front-end) and one for your nodes (the devices). The project includes a minimal UI view which is perfect for debugging and serves as a simple proof-of-concept to show how everything connects.
4. Real-time Updates: When a permission changes in Django, I wanted it to reflect on the user's dashboard instantly. Using Django Signals, if you revoke a user's access, the button on their screen gets disabled in real-time without needing a page refresh.
The project is fully open-source and comes with Docker files for easier setup.
I would be really grateful for any feedback, ideas, or questions from the community here. I'm curious if others have faced similar problems and how you've solved them.
You can check out the code and more detailed documentation on GitHub.
- GitHub Repo: [Link to your GitHub repo]
- Docs: [Link to your docs]
Thanks for your time
Addressing Initial Feedback: Clarifying the Architecture
I received some excellent initial questions regarding enterprise security best practices (using Keycloak/NGINX) and UI tools like UIBUILDER. Below is a clarification of where Quack Quack fits architecturally:
1. Quack Quack and Security: A Layered Approach
Many rightly pointed out that specialized Identity Management (IdM) tools like Keycloak, Authelia, and NGINX are superior for authentication and perimeter security. I agree completely.
Quack Quack is designed to sit behind these essential services, forming a Layer 2 (Application-Level Authorization):
| Layer | Component | Function | Why Django is Necessary |
|---|---|---|---|
| Layer 1 | NGINX / Keycloak | Authentication (Who are you?) and general application access. | Handles standard SSO and infrastructure security. |
| Layer 2 | Django Consumers | Checks real-time object-level permissions (PostgreSQL) before executing a command. |
Enforces granular security (e.g., "User X can only control Sensor Y") against a dynamically changing state model, which IdM tools cannot easily handle. |
2. UI Flexibility vs. Architectural Decoupling (UIBUILDER Comparison)
While tools like UIBUILDER offer fantastic front-end flexibility, Quack Quack’s flexibility is a result of architectural decoupling necessary for scalability:
- UIBUILDER's Communication: UI ⟺ Node-RED Flow.
- Quack Quack's Communication: UI ⟺ Django/Channels ⟺ Redis Layer ⟺ Node-RED Workers.
The UI communicates only with the central Django authority (the Browser Consumer). This means:
- Stateless Node-RED: Node-RED instances are purely execution workers, simplifying deployment and increasing flow throughput.
- Centralized State & Performance: Our reliance on Redis as both a message broker and a cache ensures that the immediate device state is served at high speed from a single source, maintaining real-time responsiveness and state synchronization across the entire cluster.
Quack Quack solves the complex scaling and granular security challenges that emerge when moving beyond single-instance Node-RED deployments, ensuring that the system is both robust and enterprise-ready.
Thank you again for these excellent comments; they greatly help us define Quack Quack's place in modern IoT infrastructure!
