|
| 1 | +# **Block Diagram** |
| 2 | + |
| 3 | +## **Introduction** |
| 4 | + |
| 5 | +This document provides a concise block diagram illustrating the architecture of our software application, Transcript Summarization. The diagram outlines the key components and their interactions to help you better understand how the application functions. |
| 6 | + |
| 7 | +**Block Diagram Overview:** |
| 8 | + |
| 9 | +The block diagram represents the software application's architecture in a visual format, making it easier to grasp its structure and functionality. |
| 10 | + |
| 11 | +## Block Diagram |
| 12 | + |
| 13 | + |
| 14 | + |
| 15 | +## Components and Functionalities |
| 16 | + |
| 17 | +1. **User/PWA** |
| 18 | + - This component is responsible for making the request to the transcript summarization API with a VTT file uploaded by the user. |
| 19 | + |
| 20 | +### **2\. GraphQL API** |
| 21 | + |
| 22 | + - The core component, created with NestJS, is responsible for accepting the incoming requests made by the user/application for creating a transcript summary. |
| 23 | + - A status response is sent back to the user/PWA to signify if the file has been successfully summarized or if any errors were encountered. |
| 24 | + - Upon receiving the request, the API stores the received job ID and other necessary details in the database. |
| 25 | + |
| 26 | +### **3\. Database TypeORM** |
| 27 | + |
| 28 | +- The MariaDB database is responsible for holding the records of uploaded transcripts along with all other required details about them such as the jobId, CreatedAt time, CreatedBy username etc. |
| 29 | +The records in the database are updated with the summarized file download link received from the server upon conversion success. |
| 30 | + |
| 31 | +### **4\. Cron Job Scheduler** |
| 32 | + |
| 33 | +A scheduled cron fetches all the uploaded transcripts in the pending status from the database and adds their Job IDs to the queue for processing. |
| 34 | + |
| 35 | +### **5\. Queue** |
| 36 | + |
| 37 | +- A queue is maintained to allow processing of transcript records one by one. |
| 38 | +- These queues are implemented using Bull Queue. |
| 39 | +- The queue receives the Job ID of the transcript to be summarized and fetches its File data from the database using this Job ID to pass it onto the service. |
| 40 | + |
| 41 | +### **6\. OpenAI Python Script** |
| 42 | + |
| 43 | +- The script holds the business logic for generating the summary of the uploaded transcript. |
| 44 | +- Upon success/failure, the response is sent back to update the status of the job ID |
| 45 | + |
| 46 | +## Data Flow |
| 47 | + |
| 48 | +- User interacts with the progressive web App to upload transcript files. |
| 49 | +- NestJS backend receives the file upload request and enqueues a job in the Bull queue for transcript summarization. |
| 50 | +- Cron job scheduler triggers a job every second |
| 51 | +- The queue processor picks up jobs from the Bull queue and executes transcript summarization of the uploaded file using the OpenAI Python script. |
| 52 | +- On success, summarized files are stored on a server, and a download link is generated using a REST API Endpoint which is stored in MariaDB database |
| 53 | +- A download link through a REST API endpoint is made available for users to download the summarized file. |
| 54 | + |
| 55 | +## **Conclusion** |
| 56 | + |
| 57 | +This block diagram serves as a valuable resource for understanding the architecture of our software application. It highlights the core components, their interactions, and the flow of data within the application. |
0 commit comments