# Project Management MVP: Day 1

When building a portfolio project that demonstrates cloud-native architecture and event-driven design, the first day sets the tone. Today, I’ll walk through how I set up the foundation for my Project Management & SaaS Collaboration Platform MVP (an optimized, scaled-down Jira/ClickUp clone) and explain why I chose a single GitHub repository for both frontend and backend.

* * *

### Why a Single Repository?

Many enterprises split frontend and backend into separate repositories. That makes complete sense when development teams are large, autonomous, and deploying on independent cycles. But for a portfolio MVP, a monorepo (single repository) offers distinct, strategic advantages:

*   **Simplicity for Reviewers:** Recruiters and hiring managers can clone one single repository and immediately see how both the Angular frontend and .NET backend work together.
    
*   **Unified CI/CD Pipeline:** Instead of managing multiple detached pipelines, one GitHub Actions workflow can easily build Angular, build .NET, and deploy both to their respective Azure services. This keeps the DevOps story clean and easy to audit.
    
*   **Documentation Clarity:** Your architecture diagrams, Infrastructure as Code (Bicep) scripts, and environment setup instructions all live in one central location.
    

> **Architectural Note:** In my project's main `README.md`, I’ll explicitly note that splitting repositories is industry standard for large enterprise teams. This demonstrates to engineering managers that I understand corporate scale, but deliberately chose a monorepo here for MVP agility and reviewability.

* * *

### Day 1 Goals

1.  Initialize the workspace repository with proper `.gitignore` boundaries.
    
2.  Scaffold the .NET Web API backend.
    
3.  Scaffold the Angular frontend.
    
4.  Set up platform-agnostic local emulators for Azure services (Azurite + Cosmos DB).
    

* * *

### Step 1: Repository Setup & Frontend Scaffolding

First, we initialize our project directory. To ensure our repository remains clean right from the start, we will generate our Angular application immediately so we can cleanly manage our configuration files.

```bash
# Create and enter the project directory
mkdir project-mgmt-mvp
cd project-mgmt-mvp
git init

# Generate the Angular frontend app directly with necessary flags
ng new frontend --routing --style=scss --skip-git

```

Next, we generate a default .NET gitignore file at the root:

```bash
dotnet new gitignore

```

**Crucial Step:** Open your root `.gitignore` file and manually append Angular’s common ignore patterns (like `/frontend/node_modules/`, `/frontend/dist/`, and `.sourcemaps/`) into it. This ensures node packages never accidentally pollute your git history.

* * *

### Step 2: Backend API Scaffold

With the root and frontend prepped, let's spin up the core server-side layer using the .NET CLI:

```bash
# Create the backend Web API project
dotnet new webapi -o backend

# Navigate and test execution
cd backend
dotnet run

```

Modern .NET projects dynamically allocate random ports inside `properties/launchSettings.json` to prevent local port collisions. Check your console output to see your specific assigned port (e.g., `https://localhost:7123`), and navigate to it in your browser to confirm the boilerplate API is active.

* * *

### Step 3: Verifying the Frontend

Because we scaffolded the frontend structure during Step 1, starting your local Angular development environment is straightforward:

```bash
# Navigate to the frontend directory
cd ../frontend

# Spin up the local development server
ng serve

```

Open your browser and visit `http://localhost:4200` to confirm that the Angular boilerplate application is rendering cleanly.

* * *

### Step 4: Setting Up Cross-Platform Azure Emulators

To ensure this project costs exactly **$0** to build, test, and iterate on, we mimic our target cloud ecosystem entirely on our local machine using emulators.

#### 1\. Azurite (Blob & Queue Storage)

Instead of hardcoding rigid, OS-specific folder paths, we use relative paths within our workspace directory. Run the following commands to install and start Azurite:

```bash
npm install -g azurite
azurite --silent --location ./azurite_data --debug ./azurite_data/debug.log

```

*(Make sure to append* `/azurite_data/` *to your root* `.gitignore` *file so emulator state database files are ignored by git!)*

#### 2\. Azure Cosmos DB Emulator

We will use NoSQL data modeling for our core entity architecture.

*   **Windows Users:** Download and install the standard MSI installer from Microsoft Docs.
    
*   **Linux Mint / macOS Users:** You can spin up the emulator instantly inside a Docker container:
    

```bash
docker run -p 8081:8081 -p 10251:10251 -p 10252:10252 -p 10253:10253 -p 10254:10254 mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator

```

* * *

### Current Repository Layout

At the close of Day 1, your monorepo workspace directory tree should look exactly like this:

```text
project-mgmt-mvp/
├── .gitignore
├── README.md
├── azurite_data/      <-- Local emulator binary data (Git ignored)
├── backend/           <-- .NET Web API Core
│   ├── Program.cs
│   └── backend.csproj
└── frontend/          <-- Angular Client SPA
    ├── src/
    └── package.json

```

* * *

### Architecture Snapshot

Here is the decoupled, local loop data flow we established today:

```mermaid
graph TD
  A[Angular Frontend: Port 4200] -->|HTTP Requests| B[.NET API: Dynamic Port]
  B -->|NoSQL SDK| C[Cosmos DB Emulator: Port 8081]
  B -->|Azure.Identity SDK| D[Azurite Local Blobs/Queues]

```

This diagram will scale significantly over the next two weeks as we introduce our live Bicep IaC automation, Azure App Services, Consumption-tier Azure Functions, and Azure Queue Storage integration.

* * *

### Day 1 Wrap-Up

We have successfully accomplished our architectural baseline:

*   A unified repository infrastructure housing both client and server stacks.
    
*   A platform-agnostic, zero-cost emulator topology running locally.
    
*   A clean developer workflow built for cloud-native translation.
    

Tomorrow, we will dive deep into advanced **Cosmos DB schema design**, mapping out JSON partitions for Workspaces, Tasks, and Users, and implementing a highly efficient Repository Pattern inside our C# backend. Stay tuned!