Aora is an application designed to leverage AI for advanced document handling and natural language processing. This repository contains both backend and frontend components to get the application up and running.
Highly recommended:
- VSCode
- Python
- Docker
- Node
- Vue - Official by Vue: Inter alia code formatter used for Vue.
- π Attention: Disable Vetur!
- Remark: The extension is also called Volar.
- Prettier
Further helpful VSCode extensions:
- Vue.js Extension Pack by Muhammad Ubaid Raza (Collection of extensions providing syntax highlighting, code format, code snippets, IntelliSense, linting support, npm & node tools)
- Vue 3 Snippets by hollowtree
- Peacock by John Papa: VSCode Workspace color scheme for multiple instances.
π Note: The VSCode settings.json
is pushed to git. In order to properly use the defined formatting settings, you definitely will need the above mentioned extension.
git clone https://github.com/tmeftah/Aora.git
-
Navigate to the backend directory:
cd backend/
-
Create a virtual environment:
python -m venv venv
-
Activate the virtual environment:
- On Windows:
venv\Scripts\activate
- On macOS/Linux:
source venv/bin/activate
- On Windows:
-
Install all required packages:
pip install -r requirements.txt
-
Run the development server:
fastapi dev
-
Navigate to the frontend directory:
cd frontend
-
Install all necessary packages:
npm install
-
Run the development server:
npm run dev
You need ollama to run llms locally. Ollama have to be installed as docker container on your machine (docker have to run also).
Install and Run Ollama Docker Container
Ensure Docker is installed and running on your machine. Then, install and run the Ollama container with the following command:
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
This will set up and start the Ollama container in the background, with the necessary volumes and ports configured.
After installing and running the ollama docker container, you have to connect to that container and pull the llm model you want to use.
docker exec -it ollama ollama pull llama3.1
Replace llama3.1 with the appropriate model version, if necessary.
To start the Ollama container if it is stopped, run the following command:
docker start ollama
you can follow the official ollama documenation for more settings.
To create a vector datastore of your documents, you need follow this steps:
- Inside the 'backend/embeddings' folder create folder named 'docs' and add you pdf documents.
- run following command
cd backend/embeddings
python ingest.py # create embeddings.
-
Create an
.env
file inside thebackend
folder with the following settings:SECRET_KEY=<your_secret_key> PUBLIC_KEY=<your_public_key> LANGFUSE_HOST=<your_langfuse_host> DATABASE_PATH=<chroma_db> COLLECTION_NAME=<langchain>
-
Create an
.env
file inside thefrontend
folder with the following settings for the UI:API=http://ip-address-of-api:port
Contributions are welcome! Please open an issue or submit a pull request to contribute to the project.
main
Branch: Represents the production-ready codebase. Only fully tested and approved code gets merged here.develop
Branch: The main integration branch. All feature branches are merged here for testing before going tomain
.- Feature Branches (one per feature): Short-lived branches where each developer works on a specific feature, bug fix, or task in isolation.
-
Project Setup (Do This Once)
git init # Initialize the repository if you haven't already git remote add origin [remote-repo-url] # Connect to your remote repository (e.g., GitHub, GitLab) git checkout -b develop # Create the `develop` branch git push -u origin develop # Push `develop` to the remote
-
Starting a New Feature
- Developer A:
git checkout develop git pull origin develop # Ensure you have the latest changes git checkout -b feature-<issue-number>/user-authentication # New branch for user authentication
- Developer B:
git checkout develop git pull origin develop git checkout -b feature-<issue-number>/product-catalog # New branch for a product catalog
- Developer A:
-
Working on Features (Independently)
- Both developers work on their respective branches, making commits and pushing changes frequently:
git add . git commit -m "Implemented login logic" git push origin feature-<issue-number>/user-authentication
- Both developers work on their respective branches, making commits and pushing changes frequently:
-
Merging a Feature into
develop
(Example: Developer A)-
Before Merging (Important!):
git checkout develop git pull origin develop # Get the latest changes from the remote `develop`
-
Merging:
git checkout feature-<issue-number>/user-authentication # Switch to your feature branch git merge develop # Merge the updated `develop` into your feature branch # Resolve any conflicts that might occur (more on that later) git push origin feature-<issue-number>/user-authentication # Push the merged version
-
Creating a Pull Request: Open a pull request on your platform (GitHub) from
<issue-number>/user-authentication
todevelop
. This allows for code review before merging.
-
-
Code Review and Merging to
develop
- Developer B (or the other developer) reviews the pull request, provides feedback, and approves it.
- Once approved, Developer A can merge the pull request into
develop
on the remote platform (GitHub).
-
Repeating the Process (Developer B's Turn)
- Developer B now pulls the latest
develop
, merges it into theirfeature-<issue-number>/product-catalog
branch (to resolve conflicts early), pushes, and creates a pull request for review.
- Developer B now pulls the latest
-
Deploying to
main
- Once enough features are tested on
develop
, you can mergedevelop
intomain
.git checkout main git pull origin main git merge develop git push origin main
- Once enough features are tested on
- Frequent Pulls and Merges: Regularly pulling from
develop
and merging into your feature branches helps identify and resolve conflicts earlier. - Effective Communication: Talk to your teammate! Discuss what you're working on to avoid overlapping changes in the same files.
- Small, Focused Features: Breaking work into smaller pieces makes conflicts less likely and easier to manage.
- If
git merge
encounters a conflict, it will mark the conflicting areas in your code. - Open the affected files, manually edit them to choose the correct changes, and then use
git add [filename]
to stage the resolved files. - Commit the resolution:
git commit -m "Resolved merge conflict in [filename]"
This workflow emphasizes collaboration and regular integration to minimize the chances of major merge conflicts. Remember that clear communication and consistent practices are your best tools to keep your Git workflow running smoothly.
This project is licensed under the MIT License.
This project is a part of the GenAI project. In case there are any questions, please contact