AITextSummarizerAndSharer

A Django App to summarize text/Meeting notes and share it via email.

AI Text/Meeting Notes Summarizer and Sharer Django Web-App. Phase 1: Project Scoping and Design (The Blueprint) This initial phase is about planning. Before writing any code, we define what we're building and how.

1. Core Feature Definition (User Stories) The goal is to translate the app's idea into concrete functionalities from a user's perspective. As a user, I want to upload a text file (.txt) so I can provide the source material. As a user, I want to write a custom instruction (a prompt) to guide the AI's output. As a user, I want to click a "Generate" button to process the transcript and prompt. As a user, I want to view the AI-generated summary in an editable text area. As a user, I want to save my edits to the summary. As a user, I want to share the final summary with others via email.
2. Technology Stack Selection Backend: Django was chosen because it's a "batteries-included" framework. It provides a robust ORM (Object-Relational Mapper) for database interactions, a secure way to handle forms (CSRF protection), and a powerful templating engine, which is perfect for a project that needs both data storage and server-rendered pages. Frontend: Vanilla JavaScript(Jinja) and Tailwind CSS were selected for simplicity and rapid UI development. This approach avoids the complexity of a full frontend framework like React or Vue for a project of this scale. Tailwind allows for direct styling within the HTML, making it fast to create a modern-looking interface. AI Service: The Groq API with the model = "llama-3.3-70b-versatile" was chosen for its powerful generative capabilities and a straightforward Python SDK, making integration into the Django backend seamless. Database: SQLite is the default for Django development. It's a simple, file-based database that requires no extra setup, making it ideal for prototyping and small-scale applications. For production, this could be swapped for PostgreSQL.
3. Data Modeling We need to decide what information to store. For this app, the model is simple: A Transcript object will represent each session. Fields: id: A unique identifier (UUID) for each record. original_text: To store the full, uploaded transcript. summary_text: To store the AI-generated (and potentially user-edited) summary. created_at: A timestamp to know when the record was created.
4. Architectural Approach We follow Django's native Model-View-Template (MVT) architecture: Model (models.py): Defines the database structure (the Transcript object). View (views.py): Contains the business logic. It handles user requests, interacts with the Model, calls the Gemini API, and decides which template to render. Template (.html files): The user-facing HTML files that display the data.

Phase 2: Backend Development (Building the Engine)

This is where we build the core server-side logic.

1. Environment Setup A virtual environment is created to isolate the project's Python dependencies. Django is installed, and a new project (summarizer_project) and app (summarizer) are created using the django-admin and manage.py command-line tools.
2. Model and Database Implementation The Transcript class is written in summarizer/models.py. The commands python manage.py makemigrations and python manage.py migrate are run. These commands tell Django to inspect the model, create a database migration file (a recipe for changing the database), and then apply that recipe to create the actual database table.
3. URL Routing (urls.py) Project urls.py: The main URL router. It's configured to delegate any incoming requests to the summarizer app's own URL file. App urls.py: Defines the specific URL patterns for the app: / (the root URL) maps to the home view for uploading. /summary/uuid:transcript_id/ maps to the summary_view to display a result. /summary/update/uuid:transcript_id/ and /summary/share/... are API-like endpoints for the JavaScript to send data to.
4. View Logic (views.py) This is the heart of the application. The home view handles two scenarios: a GET request (just showing the upload page) and a POST request (processing the uploaded file and prompt). Upon a POST request, it reads the file, gets the prompt, and calls the generate_ai_summary function. The generate_ai_summary function performs prompt engineering. Instead of just sending the raw text, it constructs a more detailed prompt that gives the AI clear instructions and context, separating the user's prompt from the transcript. It then calls the Gemini API and includes try...except blocks to handle potential API errors gracefully. The update_summary and share_summary views are designed to handle asynchronous fetch requests from the frontend, returning JsonResponse objects to confirm success or failure.

Phase 3: Frontend Development (Creating the UI)

This phase focuses on what the user sees and interacts with.

1. Templating A base.html template is created. It contains the common HTML structure (header, footer, CSS links). Other templates (home.html, summary.html) extend this base template, which avoids code duplication.
2. UI and Styling The forms and layout are built using standard HTML tags. Tailwind CSS classes are used directly in the HTML to style every element, from button colors and text sizes to the responsive layout, ensuring the app looks good on both desktop and mobile devices.
3. Client-Side Interactivity (JavaScript) File Upload Feedback: A small script listens for changes on the file input. When a user selects a file, the script updates the UI to display the filename, providing essential visual feedback. Asynchronous Actions (AJAX): Instead of full page reloads, fetch is used to send data to the backend for saving and sharing. When a user edits the summary and clicks "Save," a fetch request sends the updated text to the /summary/update/... URL. The "Share" button opens a modal. When the user clicks "Send," another fetch request sends the recipient emails to the /summary/share/... URL. This makes the app feel faster and more modern.

Phase 4: Integration, Security, and Deployment

1. Secure API Key Management Sensitive information like the Gemini API key and email passwords are never hard-coded. They are stored in a .env file, which is excluded from Git version control via the .gitignore file. The python-dotenv library is used in settings.py to load these variables into the application's environment securely.
2. Production Preparation DEBUG Mode: In settings.py, DEBUG is set to False. This is a critical security measure that prevents sensitive error information from being shown to the public. ALLOWED_HOSTS: This setting is configured with the production domain name (e.g., Your-Username.pythonanywhere.com) to prevent HTTP Host header attacks. Static Files: The collectstatic command is used to gather all static files (CSS, JS) into a single directory (staticfiles) that the production web server can serve efficiently.
3. Deployment on PythonAnywhere Platform Choice: PythonAnywhere is chosen as a Platform-as-a-Service (PaaS) because it simplifies deployment. It manages the underlying server, operating system, and web server (like Nginx), allowing the developer to focus on the code. Process: The code is pushed to GitHub. A Bash console is opened on PythonAnywhere, and the code is cloned from GitHub. A virtual environment is created with the correct Python version. The WSGI file is configured. This is the entry point that connects the PythonAnywhere web server to the Django application. The environment variables (API keys, etc.) are set in the PythonAnywhere web interface. The static file mapping is configured to tell the server where to find the collected static files. The web app is reloaded to apply all changes.

Alternative Approaches and Future Improvements

Decoupled Frontend: For a more complex application, one might use Django REST Framework to build a backend API. The frontend would be a completely separate Single-Page Application (SPA) built with React or Vue.js. This provides a cleaner separation of concerns but adds complexity. Asynchronous Processing: If users were to upload very large transcripts, the API call to Gemini could take a long time and cause the web request to time out. The professional approach would be to use a task queue like Celery with a message broker like Redis. The view would hand off the summarization task to Celery, which would process it in the background and update the database when finished. The frontend could then poll the server to check if the summary is ready. Different Hosting: For applications requiring more control or scalability, one might deploy to an Infrastructure-as-a-Service (IaaS) provider like AWS EC2 or DigitalOcean. This would require manually configuring the web server (Nginx), application server (Gunicorn), database, and firewall, offering more power at the cost of more complexity.