Research the end-to-end user experience of using Dev Proxy in a GitHub Codespace (as an app developer)

[waldekmastykarz]

Investigate and document the step-by-step experience of an app developer using Dev Proxy within a GitHub Codespace (not working on Dev Proxy's codebase, but using it as a tool to assist app development). The research should cover:

• Codespace creation and startup, ensuring Dev Proxy can be set up as a runtime dependency or tool
• Guidance for installing, configuring, and running Dev Proxy in a Codespace terminal
• Usability of Dev Proxy's CLI for local app development in Codespaces (including port forwarding, networking, and integration with the user's app)
• How to use Dev Proxy to simulate API failures, throttling, and chaos for app testing
• Troubleshooting common issues specific to this workflow in Codespaces
• Recommendations for improving onboarding, documentation, or setup scripts for app developers

Deliverables:

• A documented E2E walkthrough (with screenshots or code snippets where possible) for an app developer
• A list of UX pain points and suggestions
• Recommendations for improvements

[waldekmastykarz]

Did some preliminary research from the codebase side to identify what matters for the Codespace UX evaluation.

Installation in Codespaces

Our scripts/setup.sh handles Linux installation (download zip, extract, add to PATH). It supports non-interactive mode (detects when stdin isn't a terminal and skips the confirmation prompt), which is great for automation in Codespaces. The script supports both x64 and arm64 architectures.

Key areas to test

1. Proxy setup: Dev Proxy uses Titanium.Web.Proxy which requires setting up a system proxy. In Codespaces, this might conflict with the built-in port forwarding proxy. Need to verify if toggle-proxy.sh (macOS-only) has a Linux equivalent or if manual proxy config is needed.

2. Certificate trust: Dev Proxy intercepts HTTPS traffic, which requires trusting the proxy's root certificate. In a Codespace, we'd need to verify the cert ensure command works properly in the container environment and that apps running in the Codespace trust the cert.

3. Port forwarding: Dev Proxy runs an API on port 8897 and the proxy on port 8000. If a developer wants to access the Dev Proxy API from outside the Codespace (e.g., for Dev Proxy Toolkit in VS Code), they'd need port forwarding configured.

4. Networking: Codespaces have specific networking constraints. Need to verify that intercepting traffic from an app running in the Codespace works correctly when the target APIs are external.

5. Devcontainer setup: Related to Create a Development Container Feature for Dev Proxy #1334 — a devcontainer.json feature would streamline the setup significantly. We could pre-install Dev Proxy, trust the cert, and configure the environment automatically.

Next step: This needs hands-on E2E testing in an actual Codespace to validate these assumptions and document the real experience. The codebase analysis gives us the areas to focus on, but only real testing will surface the actual UX pain points.