Forward Deployed Engineer 101: Frontend and UI Basics (React or Similar – Rapid Prototyping for Stakeholders)

Frontend and UI Basics (React or Similar – Rapid Prototyping for Stakeholders)

Frontend & UI Basics (React) – Rapid Prototyping for Stakeholders

A Field-Ready Study Guide for Forward Deployed Engineers

What This Is

As an FDE, you’ll often need to build and iterate on UIs under tight deadlines—whether for a classified dashboard, a disaster response tool, or a last-minute stakeholder demo. Unlike traditional frontend dev, you’re not optimizing for pixel-perfect design; you’re validating assumptions fast, working around constraints (air-gapped networks, limited dependencies, security restrictions), and delivering something usable in hours or days.

Field Example:
You’re deployed to a military base to prototype a real-time drone feed dashboard for a classified mission. The customer (a colonel) has vague requirements ("I need to see the video and some metadata"), but the real need is to flag anomalies in the feed (e.g., unauthorized vehicles). You have 48 hours, no internet access, and must use their locked-down Windows machines with no admin rights. You whip up a React app with a mock API (since the real backend isn’t ready), hardcode sample data, and deploy it via a USB stick as a static site. The colonel loves it—now you’ve got buy-in to build the real thing.

Key Terms & Concepts

• React (or Preact/Vue): A component-based frontend library for building UIs. Preact is a lightweight (~3KB) alternative to React, useful for air-gapped or low-resource environments where bundle size matters.
• Create React App (CRA) / Vite: Boilerplate tools to scaffold a React app in seconds. Vite is faster and better for rapid prototyping (hot module reloading, smaller bundles).
• Field note: If you’re on a restricted machine, use npx vite@latest (no global install needed) or bring a pre-built static bundle on a USB.
• Component-Driven Development: Break UIs into reusable, isolated components (e.g., DroneFeedCard, AlertBanner). Critical for iterating fast—stakeholders can react to individual pieces.
• Mock APIs (MSW, Mirage, or json-server): Simulate backend endpoints without writing a real API. MSW (Mock Service Worker) intercepts HTTP requests in the browser—perfect for air-gapped demos.
• Example: npx json-server --watch db.json (spins up a fake REST API in 5 seconds).
• State Management (Zustand, Jotai, or Context API): For small apps, avoid Redux (overkill). Zustand is ~1KB and works great for prototypes.
• Static Site Generation (SSG) / Next.js: Pre-render pages at build time for faster loads and offline use. Next.js is overkill for prototypes, but useful if you need SSR later.
• Tailwind CSS: Utility-first CSS framework for rapid styling without writing custom CSS. Works well with design constraints (e.g., "use the customer’s brand colors").
• Storybook: Isolate and test components without the full app. Useful for stakeholder feedback ("Does this button look right?").
• Docker (for Frontend): Containerize your app for consistent deployments (even in air-gapped environments). Use nginx for static files: dockerfile FROM nginx:alpine COPY build/ /usr/share/nginx/html
• USB Deployment: For air-gapped environments, build a static site (npm run build), zip it, and deploy via USB. Use serve for local testing: bash npx serve -s build
• Security Constraints (CSP, CORS, HTTPS): Many enterprise environments block inline scripts or require HTTPS. Use helmet in React to set security headers: javascript import helmet from "helmet"; app.use(helmet());
• Ask vs. Infer (UI Edition):
• Ask: "We need a map with drone locations." (Customer’s stated requirement.)
• Infer: "They actually need real-time alerts when drones deviate from their flight path." (What the mission requires.)

Step-by-Step / Field Process

1. Rapid Discovery (30–60 mins)

• Goal: Turn vague requirements into a prioritized list of UI components.
• Actions:
• Ask: "What’s the #1 thing you need to see on this screen?" (Not "What features do you want?")
• Sketch a wireframe on paper (or use Excalidraw) and get sign-off.
• Identify data sources (APIs, CSVs, hardcoded mocks) and constraints (no internet, must run on IE11, etc.).
• Field tip: If the customer says "We’ll give you the API later," mock it immediately (MSW or json-server).

2. Scaffold the App (10 mins)

• Goal: Get a working dev environment in the customer’s constraints.
• Actions:
• If you have internet access, use Vite:
  bash
npm create vite@latest my-prototype --template react
cd my-prototype
npm install
npm run dev
• If no internet, bring a pre-initialized project on a USB (or use npx with a cached node_modules).
• If no Node.js, use Preact + CDN (no build step):
  html
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/preact.min.js"></script>
<script>
const { h, render, Component } = preact;
// Write components here
</script>

3. Build the MVP (2–4 hours)

• Goal: A clickable prototype with the top 3 components.
• Actions:
• Start with hardcoded data (no API yet). Example:
  javascript
const mockDroneData = [
{ id: 1, lat: 34.05, lng: -118.25, status: "NOMINAL" },
{ id: 2, lat: 34.06, lng: -118.26, status: "ALERT" },
];
• Use Tailwind CSS for styling (no custom CSS):
  bash
npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init
• Build one component at a time, testing in Storybook if possible.
• Field tip: If the customer changes requirements mid-build, refactor later—get something working first.

4. Mock the Backend (15 mins)

• Goal: Simulate API responses so the UI feels real.
• Actions:
• Use MSW to intercept API calls:
  javascript
import { setupWorker, rest } from "msw";
const worker = setupWorker(
rest.get("/api/drones", (req, res, ctx) => {
return res(ctx.json(mockDroneData));
})
);
worker.start();
• If no Node.js, use json-server (run it on a separate port):
  bash
npx json-server --watch db.json --port 3001

5. Deploy for Stakeholders (30 mins)

• Goal: Get the prototype in front of users fast.
• Actions:
• Option 1: Static Site (USB/Offline)
  • Build the app: bash npm run build
  • Serve it locally (for demos): bash npx serve -s build
  • Zip the build/ folder and deploy via USB or shared drive.
• Option 2: Docker (Air-Gapped)
  • Build a Docker image: bash docker build -t prototype .
  • Save the image to a file: bash docker save prototype > prototype.tar
  • Load it on the customer’s machine: bash docker load < prototype.tar docker run -p 80:80 prototype
• Option 3: GitHub Pages / Netlify (If Internet Allowed)
  • Push to a private repo and enable GitHub Pages.
  • Field trap: If the customer’s network blocks GitHub, use a local tunnel (e.g., ngrok): bash ngrok http 3000

6. Iterate Based on Feedback (1–2 hours)

• Goal: Turn stakeholder feedback into actionable changes.
• Actions:
• Prioritize feedback (e.g., "The map is too slow" > "The button color is wrong").
• Hardcode fixes first, then refactor later.
• If the customer adds a new requirement, ask:
  • "Is this blocking the mission?" (If no, defer it.)
  • "Can we mock this for now?" (Avoid scope creep.)

Common Mistakes

FDE Interview / War Story Insights

1. "The customer demands a feature that violates the original scope. How do you respond?"

• Bad Answer: "We can’t do that—it’s out of scope."
• Good Answer:
• "Let’s mock it up and see if it solves the real problem. If it does, we’ll reprioritize."
• Why: FDEs validate before committing. A quick prototype can kill a bad idea or unlock new requirements.
• Field Story: A customer insisted on a real-time chat feature in a drone dashboard. We mocked it in 30 mins—turns out they didn’t need it (they just wanted a way to flag anomalies). Saved 2 weeks of work.

2. "You’re deploying to an air-gapped environment with no Docker. What’s your plan?"

• Bad Answer: "We’ll figure it out when we get there."
• Good Answer:
• "I’ll build a static site (npm run build), zip it, and deploy via USB. If they need dynamic data, I’ll use json-server or a local SQLite DB."
• Why: Static sites work everywhere. If you need a backend, mock it locally.

3. "The stakeholder says the UI is ‘too slow’ but won’t specify why. How do you debug?"

• Bad Answer: "I’ll optimize the React code."
• Good Answer:
• "I’ll ask: ‘Is it slow when loading, or when interacting?’ Then I’ll check the network tab (for API calls) and the React profiler (for renders)."
• Field Tip: 90% of "slow" UIs are due to unoptimized API calls or too many re-renders. Fix the low-hanging fruit first.

Quick Check Questions

1. You’re on site and the customer’s network blocks all external API calls. The UI needs to fetch data. What’s your first step?

Answer: Mock the API locally using json-server or MSW.
Why: You can’t rely on external services in restricted environments—always have a fallback.

2. The stakeholder says, "I need a map with real-time drone locations," but the backend team won’t deliver the API for 2 weeks. What do you build first?

Answer: A static map with hardcoded drone data (e.g., Google Maps + mock JSON).
Why: Validate the UI first—the backend can be swapped in later.

3. You’re deploying a React app to a customer’s Windows machine with no Node.js. What’s the simplest way to run it?

Answer: Build a static site (npm run build) and serve it with npx serve -s build or a USB-deployed Docker container.
Why: Static sites require no runtime—just a browser.

Last-Minute Cram Sheet

1. Vite > CRA for prototypes (npm create vite@latest).
2. Tailwind CSS for styling (npm install -D tailwindcss).
3. Mock APIs with MSW (npm install msw).
4. Zustand > Redux for state (npm install zustand).
5. Static site deployment: npm run build → npx serve -s build.
6. Docker for air-gapped: docker build -t app . → docker save app > app.tar.
7. USB fallback: Always have a zipped build/ folder on a USB.
8. ⚠️ Test on the customer’s hardware early—your MacBook ≠ their Windows 7 machine.
9. ⚠️ Hardcode data first—don’t wait for the backend.
10. ⚠️ If the customer changes requirements, mock it first before committing.