2025 09 28 week 2 - Session 2 TDS Sep 2025#

Duration: 2h 36m

Here’s an FAQ summary of the live tutorial:

Q1: Why should I use Podman/containers instead of just VS Code or a terminal for application development, especially for AI applications?

A1: You can definitely use VS Code or a terminal for coding, but Podman (and containers generally) offer isolated, lightweight environments. This helps manage complex applications by allowing you to run different parts (like a database and a front-end) in separate, self-contained units, making management easier. For AI applications, this means you can encapsulate specific models or services within their own pods.

Q2: How do containers (like those managed by Podman) differ from virtual machines (VMs), and what are the key benefits of using containers?

A2: VMs are like full virtual computers; each has its own operating system kernel, memory, and virtual hardware. This makes them heavy and slower to start. Containers, on the other hand, are lightweight because they share the host machine’s kernel and only package the application code and its specific dependencies.

Key benefits of containers:

Lightweight: They consume fewer resources, allowing you to run many more containers than VMs on the same hardware.
Faster Communication: Sharing the kernel allows for faster communication between containers and the host.
Portability: Container images can be easily pushed to and pulled from registries (like Podman Hub or Docker Hub) and then built/run with minimal setup on any compatible system.
Isolation: While VMs offer complete hardware-level isolation, containers provide robust process-level isolation, keeping applications separate and preventing conflicts.
Speed: Because they are lightweight and don’t need to boot a full OS, containers start much faster than VMs.

Q3: What are the main differences and similarities between Podman and Docker?

A3: Functionally, Podman and Docker are very similar and use largely the same command-line interface. If you know Docker commands, you’ll be familiar with Podman.

The key differences are:

Licensing: Podman is open-source, while Docker is proprietary.
Rootless Mode: Podman defaults to a “rootless” mode, meaning containers run as a specific user without requiring root privileges, which enhances security. Docker typically runs as a superuser (root).

Q4: What is GitHub Pages, what types of files can it host, and how can I set up my own project to be hosted there?

A4: GitHub Pages is a service that allows you to host static websites directly from your GitHub repositories. It’s primarily designed for static files like Markdown (.md), HTML, CSS, and JavaScript.

To set up your project:

Create your repository: Ensure your repository contains the static files you want to host.
Go to Settings: In your GitHub repository, click on the “Settings” tab.
Navigate to Pages: In the left sidebar, click on “Pages” under the “Code and automation” section.
Choose Deployment Branch: Select your desired deployment branch (e.g., main) and, optionally, a specific folder within that branch if your content isn’t in the root.
Save: Click “Save.” GitHub Pages will then automatically deploy your site, usually providing a URL like your-username.github.io/your-repo-name. Any subsequent changes pushed to the chosen branch will automatically trigger a redeployment.

Q5: My Markdown content isn’t appearing on GitHub Pages, or it’s showing up as raw Markdown. What could be the issue?

A5: GitHub Pages primarily renders HTML, CSS, and JavaScript directly. For Markdown files to be converted into viewable HTML, they often need to be processed by a static site generator like Jekyll (which GitHub Pages uses by default) or Quarto. If your Markdown isn’t showing, or is showing as raw text, it might be due to the Jekyll processing.

To fix this, you can:

Use a .nojekyll file: Adding an empty file named .nojekyll (without any extension) to your repository’s root directory tells GitHub Pages to skip Jekyll processing. This will make GitHub Pages serve your Markdown files as raw HTML (if they are already converted) or simply display the raw .md file in the browser, bypassing Jekyll’s templating system.
Use a Jekyll-compatible setup: Alternatively, if you want proper Markdown rendering, you’d need to ensure your repository is structured correctly for Jekyll (e.g., having a _config.yml file and specific folder structures).

Q6: What is FastAPI, and what are its key advantages, especially regarding performance and asynchronous operations?

A6: FastAPI is a modern, fast, web framework for building APIs with Python. Its main advantages include:

High Performance: It’s built on Starlette (for web parts) and Pydantic (for data parts), offering very high performance comparable to Node.js and Go.
Asynchronous Support: It has built-in, native support for asynchronous programming (async/await). This allows your API to handle multiple concurrent requests efficiently without complex configurations (unlike Flask), making it ideal for high-demand applications like machine learning services.
Automatic API Docs: It automatically generates interactive API documentation (Swagger UI / OpenAPI and ReDoc) from your code, which is invaluable for development and collaboration.
Ease of Use: It’s designed to be intuitive and easy to use, with clear type hints.

Q7: What are environment variables (like API keys) used for in a Vercel deployment, and how can I manage them securely without exposing sensitive information on GitHub?

A7: Environment variables are used to store sensitive information (e.g., API keys, database credentials) or configuration settings that should not be hardcoded into your application’s source code or committed to public GitHub repositories.

To manage them securely with Vercel:

Local Development (.env files): For local testing, you create a .env file in your project’s root. This file contains key-value pairs (e.g., API_KEY=your_secret_key).
Git Ignore: Crucially, add .env to your .gitignore file. This prevents the .env file from being accidentally pushed to your GitHub repository, keeping your secrets private.
Vercel Deployment: Vercel provides a way to define environment variables directly in your project settings. You input your key-value pairs there. Vercel then securely injects these variables into your application’s environment during deployment. Your code (e.g., using os.getenv("API_KEY") in Python) can then access these variables at runtime, whether locally or on Vercel.

Q8: I’ve added my .env file to .gitignore, but it still appears in git status as an untracked file. Why is this happening, and how can I fix it?

A8: This happens if Git started tracking the .env file before you added it to .gitignore. Even if it’s ignored now, Git still remembers it was tracked.

To fix it:

Stop Tracking: Open your terminal in the project directory and run git rm --cached .env. This removes the file from Git’s index but keeps it on your local file system.
Commit gitignore: Ensure your .gitignore file (which should now include .env) is committed: git add .gitignore then git commit -m "Add .env to gitignore".
Future Changes: From this point on, Git will correctly ignore the .env file.

Q9: How does Vercel hosting work for my application, and what are its key limitations, especially regarding execution time and resource access?

A9: Vercel deploys your application as serverless functions. This means you don’t manage a continuous server; Vercel executes your functions only when triggered by a request, making it efficient for billing (you pay for actual usage).

Key limitations of Vercel functions (especially on the free tier):

Execution Time: Functions have a maximum execution duration (e.g., 300 seconds on the free tier). If your function (e.g., a long-running data processing task) exceeds this, it will time out.
Resource Limits: There are limits on CPU and memory allocated per function instance.
File System Access: Functions generally have read-only access to the file system. You cannot write files to disk during execution.
Subprocesses: You cannot run arbitrary subprocess commands (like starting other background processes or executing arbitrary shell commands).
WebSocket/Streaming: For applications requiring persistent connections (like WebSockets for live chat), Vercel functions might not be suitable as they are designed for short, stateless interactions.
Use Case: Vercel is best suited for short-lived, event-driven functions and static site hosting. For complex, long-running backend services or apps needing full server control, you might need a traditional server or a different serverless platform.

Q10: What is uvicorn, and what is its role in running my FastAPI application locally?

A10: uvicorn is a lightweight, asynchronous server gateway interface (ASGI) server. Its primary role is to run your FastAPI application locally, serving it via HTTP requests (typically on localhost:8000). When you develop a FastAPI app, uvicorn acts as the bridge between your Python code and the web server, allowing you to test your API endpoints in real-time on your development machine.

Q11: What is CORS (Cross-Origin Resource Sharing), why is it important, and how can I configure it in FastAPI to allow specific origins or methods?

A11: CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts web pages from making requests to a different domain (origin) than the one that served the web page. This prevents malicious websites from performing unauthorized actions on behalf of a user.

It’s important because it safeguards against various web vulnerabilities.

In FastAPI, you configure CORS using middleware. You specify:

allow_origins: A list of domains (origins) that are permitted to make requests to your API. You can allow all origins (["*"]) or specific ones (e.g., ["https://yourfrontend.com", "http://localhost:3000"]).
allow_credentials: Set to True if your API needs to handle cookies or authorization headers.
allow_methods: A list of allowed HTTP methods (e.g., ["GET", "POST", "PUT", "DELETE"]).
allow_headers: A list of allowed HTTP request headers.

This configuration tells the browser whether to allow or block cross-origin requests, enhancing the security of your API.

Q12: What is the purpose of the _sidebar.md file in a GitHub Pages repository?

A12: The _sidebar.md file is used in GitHub Pages primarily when your site is structured with a sidebar (common in documentation sites). It defines the content and links that appear in the sidebar of your generated website. It can also act as a marker file, and its presence might influence how Jekyll processes or skips certain parts of your site.

Q13: What is the purpose of the .nojekyll file in a GitHub Pages repository?

A13: The .nojekyll file is an empty file placed in the root of a GitHub Pages repository. Its purpose is to explicitly tell GitHub Pages not to process the site using Jekyll. This is extremely useful if you have a plain HTML, Markdown, or JavaScript-based site that you want GitHub Pages to serve directly without any automatic templating or changes that Jekyll might otherwise introduce. By using .nojekyll, your files are displayed exactly as they are in your repository.