1MEIC05T2: GeraldAI - FEUP-MEIC-DS-2024-25/ai4sd GitHub Wiki

GeraldAI is a project management assistant designed to help teams organize and analyze project data effectively. It can process various inputs, such as text files (e.g., meeting minutes), software engineering Q&A, GitHub repositories, and, potentially in the future, Google Drive and audio files, to provide insights into the project's current state and suggest next steps based on the collected information.

More details about the product should be found here below, including the product vision, market research and domain analysis.

Vision

GeraldAI's vision is to empower project teams by providing a clear understanding of their project's current state and guiding them on the most effective next steps. It aims to be a comprehensive project management assistant that seamlessly integrates with the user's workflow, transforming how teams plan, track, and execute their tasks. By leveraging AI capabilities, GeraldAI will analyze diverse inputs like audio recordings from meetings and text files such as minutes, transforming raw data into valuable insights that can inform decision-making.

The focus of GeraldAI is on delivering maximum value to users by helping them stay aligned with their project goals and objectives. The assistant's core purpose is to reduce the cognitive load on teams by organizing complex information, highlighting potential roadblocks, and suggesting actionable steps to maintain momentum in the development process. It aims to adapt to the unique needs of each project, providing personalized support that evolves as the project progresses.

Looking ahead, GeraldAI's development will emphasize continuous learning and adaptability, ensuring that the assistant grows alongside the user's needs. With plans to incorporate more advanced features, such as deeper integration with external tools and enhanced audio processing capabilities, GeraldAI aims to be a vital partner in the user's journey toward project success.

Architecture and design

image

The current architecture of the tool consists of a modular setup deployed across three primary components:

GeraldAI Docker Container

  • SQL Database: Used to store context from each chat with GeraldAI, so that the assistant can "remember" previous given information, as well as information from the project.
  • Django Application: Acts as the backend for the GeraldAI tool. It handles the data operations with the SQL database, processes logic for interactions, and communicates with other components like the React Web App and Gemini API.

Interactions:

  • Django ↔ SQL Database: The Django app retrieves and stores data in the SQL database, ensuring that the necessary data is available for processing.
  • Django ↔ Gemini API: The Django application interacts with the Gemini API to gather additional data from the Gemini Server when needed.
  • Django ↔ React Web App: The Django app communicates with the React Web App in the Web App Docker container, providing the front end with the data and responses needed for user interactions.

Web App Docker Container

React Web App: Serves as the front end for the tool, offering an interactive user interface. The React app enables users to interact with the GeraldAI system and access the functionality exposed by the backend.

Interactions:

  • React Web App ↔ Django Application: The React app makes requests to the Django application for data and receives responses for display. This interaction is key for providing users with real-time information and feedback.

Gemini Server

Gemini API: An external API that offers additional data and functionality required by the Django application. The Django app requests data from the Gemini API to support more comprehensive and dynamic responses.

Interactions:

  • Gemini API ↔ Django Application: The Django application calls the Gemini API as needed, using it as a supplementary data source for processing complex queries or providing additional features to users.

Envisioned Future Architecture

In the future, the architecture could include additional components or improvements, such as:

  • Load Balancing and Caching: Implementing load balancing for high traffic handling and caching to reduce the load on the SQL database and Gemini API.
  • Enhanced Security Layers: Adding authentication and access control between the React Web App, Django Application, and Gemini API for improved security.

Risks and Design Choices

  • Data Consistency: Ensuring consistency between the SQL Database and the Gemini API is critical. The chosen architecture mitigates this by using the Django app as a central mediator, avoiding direct dependency between the database and API.
  • Scalability: By separating the Web App and backend services into Docker containers, the system can scale more easily by adding instances as needed.

Technologies Used

The system architecture leverages a variety of modern technologies to ensure scalability, security, and seamless user interaction. The following components and tools are integral to the project:

  1. Django Framework:
    The backend of the application is built using the Django framework, which provides a robust environment for implementing the core logic, handling database interactions, and managing API endpoints.

  2. SQL Database:
    For data persistence, an SQL-based relational database is utilized. It stores and manages essential application data, including user credentials, session tokens, and metadata for the GeraldAI system. The database is tightly integrated with the Django application.

  3. React:
    The frontend is developed using React, a JavaScript library known for its efficiency in building dynamic and interactive user interfaces.

  4. GitHub OAuth Authentication:
    User authentication is handled through GitHub OAuth, which enhances security and simplifies the login process. This ensures that only authenticated users with valid GitHub credentials can access the system.

  5. Gemini Server and API:
    The system integrates with an external service hosted on the Gemini Server, accessed through the Gemini API. This API provides additional functionality or data necessary for the overall workflow, seamlessly interacting with the Django application.

  6. Docker:
    The application utilizes Docker for containerization, isolating each service (backend, frontend, and third-party integrations) into separate containers. This approach enhances scalability and simplifies the deployment process across different environments.

  7. RESTful APIs:
    Communication between the frontend, backend, and external services is managed using RESTful API principles. This ensures consistent and efficient data exchange throughout the system.

How to use

Installation

Prerequisites

Installing Docker

The best approach to install docker is to follow the offical guide here.

Please follow the steps in Install using the repository section.

Next, follow these steps to configure docker access with non sudo permissions in the Manage Docker as a non-root user section.

Installing Docker Compose

The best approach to install docker-compose is to follow the offical guide here.

Usage

Development

First, you'll need to build a dev server.

docker compose build

If you have already built the images/containers before you can simply run:

docker compose up

Sprint Retrospective

Sprint 1

What Went Well
Sprint 1 marked a strong start, with foundational features successfully implemented. GeraldAI can now maintain context between chats, making interactions smoother and more intuitive. The integration of the Gemini API expanded Gerald's capabilities, and the ability to upload files directly to Gerald was added, streamlining data input. We also enabled audio file conversion to text, opening up new possibilities for processing meeting data. Additionally, mockups for the chat page were completed, providing a solid vision for the user interface.

What Went Wrong
While progress was significant, some early-stage challenges arose with defining the overall scope of Gerald's features and ensuring that all integrations worked seamlessly together.

What Is Still a Problem
At this stage, some feature refinements, such as the full integration of user data from files and audio, required more time to ensure robustness and usability.

Sprint 2

What Went Well
Progress was made in starting GitHub login functionality, enabling Gerald to access users' repositories. We extended audio file usage by implementing conversion to text and file saving. Additionally, mockups for the Projects page were completed, setting the stage for better project organization.

What Went Wrong
Time constraints significantly impacted this sprint, limiting the scope of improvements. Work assigned exceeded what could realistically be accomplished, leading to a lack of clarity and focus.

What Is Still a Problem
A more realistic approach to task assignment and sprint planning needs to be established. The GitHub login feature remained incomplete at the end of the sprint, requiring further work in the next iteration.

Sprint 3

What Went Well
Critical features were completed, including GitHub login functionality, granting Gerald access to users' repositories. File-saving functionality for uploaded files was implemented successfully. The Chat Page was finished and is now fully operational, while the Projects Page was created to allow users to select and manage projects.

What Went Wrong
With multiple deadlines and commitments, much of the work was delayed to the end of the sprint. This limited the team's ability to refine and polish features to the desired level of quality.

What Is Still a Problem
The rushed nature of the sprint left some features less refined than planned. Moving forward, we need to ensure better pacing throughout the sprint to avoid last-minute bottlenecks.

Future Work
To build on Sprint 3, we plan to develop an "About" page for Gerald to provide users with an overview of its features. Additionally, we need to explore ways for Gerald to conduct a fast and efficient analysis of GitHub projects, delivering actionable insights to users.