Ecommerce Store with Rasa Assistant

Products

Wireless Headphones

$10.00

Smart Watch

$12.00

Phone Case

$8.00

Bluetooth Speaker

$15.00

Power Bank

$9.99

USB Cable

$18.00

Laptop Stand

$20.00

Added to cart

📘 Project MVP Log

Track the development progress, ideas, and known issues on Notion. Unfortunately, this button will popup an external link as Notion prevents any of its public pages from being embedded in an iframe on another domain. It’s a known limitation and cannot be bypassed unless Notion changes their headers (unlikely)

Open Notion MVP Log

📖 Project Log: Debugging and Deploying a Rasa Chatbot with Nginx and WebSockets

**Project Goal:** Successfully integrate a Rasa chatbot into an existing e-commerce website, enabling real-time conversational interaction.

**Initial Problem:** The chatbot's frontend UI loaded correctly, but it remained unresponsive. Browser developer tools showed an **HTTP 400 (Bad Request)** error on WebSocket connection attempts to `socket.io`.

Investigation Steps & Technical Challenges

**Frontend Code Review (`rasachatindex.html`):** Examined JavaScript for `socket.io` connection. Noted a potential **Cross-Origin Resource Sharing (CORS)** issue as the `io()` connection targeted `https://chatbot.nlprocessor.us` while the site loaded from `https://nlprocessor.us`.
**Browser Developer Tools (F12):** Used the Network tab's WebSocket filter to confirm the **HTTP 400 error during WebSocket handshake**. The Console tab showed no client-side errors, indicating a server-side or proxy issue.
**Backend (Rasa) Status Check:** Verified Rasa was running on `localhost:5005` with correct `credentials.yml` configuration, shifting focus to the web server proxy.
**Nginx Configuration Analysis:**
- Initially assumed Nginx on a remote server, requesting `sudo nginx -T` output.
- Reviewed `chatbot.nlprocessor.us` server block: Confirmed `proxy_pass` to `localhost:5005` and presence of essential WebSocket headers (`Upgrade`, `Connection: upgrade`, `proxy_http_version 1.1`, `proxy_cache_bypass $http_upgrade`). However, a specific `location /socket.io/` block appeared commented out or improperly closed, hindering explicit WebSocket proxying.
- Repeated attempts to locate an active `server` block for the main `nlprocessor.us` domain in the `nginx -T` output were unsuccessful, leading to persistent confusion about where the main website's HTML was being served from.

Root Cause Identification & Solution Path

The critical breakthrough occurred by clarifying the hosting environment. It was determined that `https://nlprocessor.us` was being served from **Namecheap's shared hosting environment** (evidenced by the `public_html` directory). Simultaneously, Nginx and Rasa were running on the **local desktop**.

This revealed a fundamental incompatibility: **Namecheap's shared hosting does not allow direct Nginx configuration or the execution of custom applications like Rasa**. The Nginx instance being configured was local to the desktop, not the public server. Therefore, the website traffic was not reaching the local Rasa instance.

**Conclusion:** To achieve the project goal of a public, functional Rasa chatbot with WebSocket support, a hosting environment with full server control is required.

**Solution:** The next crucial step is to acquire and configure a **Virtual Private Server (VPS)**. This will enable the deployment of Nginx and Rasa on a single, publicly accessible server, allowing for proper WebSocket proxying and reliable chatbot integration.

Skills Demonstrated:

**Full-Stack Debugging:** Diagnosed issues across frontend (JavaScript), network (WebSockets), and backend (Nginx, Rasa).
**Nginx Configuration:** Understood `server` blocks, `location` directives, `proxy_pass`, and critical WebSocket headers.
**Networking Fundamentals:** Comprehended HTTP/HTTPS, WebSockets, ports, and cross-origin implications.
**Root Cause Analysis:** Persisted in identifying the underlying hosting environment mismatch.
**Solution Architecture:** Proposed a scalable and secure hosting solution (VPS) for complex application deployment.

💻 Backend Setup: Supabase Integration with Frontend

Current Stage: The project uses Supabase as a backend service accessed directly from the static frontend HTML rasaindex.html. This approach enables quick development and straightforward integration without a dedicated backend server.

What�s been accomplished: Supabase authentication and database tables are configured with row-level security policies to ensure users can manage only their own data. The Supabase JavaScript client is integrated via CDN, allowing direct communication between the frontend and the database API.

Using Supabase in the Frontend

Include the Supabase client script in your HTML:

<script src="https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2/dist/supabase.min.js"></script>

Initialize the Supabase client with your project URL and anon key:

const supabaseUrl = 'https://YOUR_PROJECT_ID.supabase.co';
const supabaseKey = 'YOUR_PUBLIC_ANON_KEY';
const supabase = supabase.createClient(supabaseUrl, supabaseKey);

Use the Supabase client methods in your frontend JavaScript to handle authentication and database queries.

Next Steps

We will set up a Node.js backend to handle more complex business logic and improve security by moving sensitive operations server-side. This will enable better scalability and protect environment variables.

Important Notes

This frontend-only Supabase integration suits early prototyping and simple use cases. Be cautious not to expose sensitive keys or operations directly in public code when moving to production.

-->