aiep-app/
├── app-admin/ (Dev Only Frontend for Web Content Management)
├── app-frontend/ (Frontend Servicing Web Application)
├── llm-service/ (Abstracted FastAPI Backend for LLM Operations)
├── app-backend/ (Unified FastAPI Backend)
├── nginx/ (Web Server & Reverse Proxy for Web App Hosting)
├── postgresql/ (SQL Database for User and Shared Document Data Source)
├── mongodb/ (NoSQL Database for Payload CMS Data Source)
└── qdrant/ (Vector Database for RAG data retreival)
''' '''
To Test Locally:
# To build and run
docker-compose -f docker-compose.local.yml up --build -d
# To close & cleanup
docker-compose -f docker-compose.local.yml down
To Deploy on Managed Server:
# SSH Into Server
# Check Git version
git --version
# Install Git if not found
sudo apt-get install git
# sudo yum install git for RHEL-based Environments such as Amazon Linux
# Clone repository
git clone https://github.com/xuhongkang/aiep-app.git
# Enter repository
cd ./aiep-app
# Run deployment script
sudo sh deploy.sh
# On first run you will be prompted to enter unconfigured environment variables
To Rebuild Project After Pushing Local Changes:
# Ensure you're at the root of the repository
sudo sh rebuild.sh
# Remember to check the availability of environment variables, which are only set per session (for security reasons and best practices)
The user-facing frontend web application hosted at a-iep.org. It serves users the below content:
- Landing Page (What's an IEP? What's our Goal? Who are we?)
- Login Page (Signup, User & Guest Login)
- User Home Page (Select Tasks)
- Upload Page (Upload Wizard, Contact Information)
- Chatbot Page (Messaging Interface for back-and-forth interaction)
- Summary Page (Overview of personal IEP information)
The content management system for the frontend application using MongoDB as the NoSQL data source. It manages the following:
- Users & Authentication: Stores User Signup Data & Handles JWT Authentication
- Static Page Content (Headers, Titles, Text)
- Blog Posts (Structured RichText Content)
The unified backend FastAPI application aims to serve all the business logic for the frontend application. It is proposed that Celery can be used for long running async tasks and RabbitMQ as a message broker which can better handling scalling and queuing. FastAPI implementation includes pydantic defined schema models, router and middleware configuration.
Functions include:
- Handling authentication calls between the frontend and cms
- Handling heavy long running document upload & extraction process >10 minutes
- Handling user specific database operations including sign up, chat history update & preferences updates
- Handling LLM calls between the frontend LLM microservice
This follows a very similar architecture to the backend. The separation of this responsibility is motivated by increasing demand to switch away from OpenAI's microservice to support other LLM powered tools due to pricing or performance. However, the current OpenAI API is still the best amongst competitors and in light of future changes in the stack it would be beneficial to abstract this logic. It's also not performance heavy as it will almost always be using an external paid commerical microservice due to the high costs of local hosting.
Functions include:
- Wrapper for a streaming response request for chat completion (OpenAI API)
- Wrapper for an asyncronous response request for chat completion (OpenAI API)
- Wrapper for speech/audio to text (OpenAI API)
- Wrapper for vision to text via VLM (OpenAI API)
- Wrapper for ai assisted translation (AWS Translate)
With properly configured DNS routing & SSL certificates via Domain Provider, the nginx server hosts the 2 frontend web apps and the 2 backend apps.
Database services such as PostgreSQL, MongoDB & Qdrant are run in Docker Containers specified by Docker Compose. For security reasons, they also keep periodic snapshots in disk storage.
- Jun 10: Resolved SSL-Related Proxy Issues, Login & Signup
- Jun 07: Deployed to Debian-Based internal environment
- Jun 05: Subpath Routing Implemented
- Jun 03: Deployed to RHEL-Based self-managed environment
- May 24: Content Management System Approved and Implemented
- May 23: Chatbot User Workflow Revision Approved
- May 22: Backend Architecture Approved
- May 20: Landing Page UI Implemented
- May 17: UI/UX Design Revision Approved
- May 13: Final Sprint Started
Docker Compose supports manual scalling on a single server via changing worker thread count. Deployment on single/multiple clusters will involve custom orchestration via Kubernetes or Docker Swarm.