The GRC Vibe Coding Recipe Book · Lesson 06 of 07
Connect a Dashboard to an Evidence Service
Combine React and Python through a small, testable API boundary.
All 7 Lessons · Jump to a Lesson
Recipe 06 · At a glance
React + Python + FastAPI + JSON
GRC use case: Dashboard connected to an evidence service
Ingredients: React displays results · Python evaluates evidence · FastAPI provides the API · JSON carries the response
Know the boundary: Two components mean a network boundary, more testing, and more operational responsibility.
Connect the ingredients
You've met five stacks. What happens when they work together?
Earlier lessons introduced browser-only vendor reviews, React dashboards, Laravel approval workflows, Python evidence checks, and Cloudflare Workers. Each solved a different GRC problem. None is automatically the next step after another: the requirements determine which responsibilities are necessary.
A technology stack is a collection of tools used together. An architecture describes where the responsibilities live and how the pieces communicate. A single stack may serve the entire application, or a system may connect several specialized parts.
| Lesson | Stack | GRC example | What it contributes | What adds complexity |
|---|---|---|---|---|
| 01 | HTML, CSS, JavaScript | Vendor review | Browser interface and simple rules | Shared records or protected data |
| 02 | Next.js, React, TypeScript | Control dashboard | Reusable interactive views | Server rendering, accounts, deployment |
| 03 | PHP, Laravel, Filament | Policy approvals | Trusted workflow and permissions | Database, access rules, operations |
| 04 | Python, optionally FastAPI | Evidence validation | Repeatable checks and data processing | APIs, credentials, scheduling |
| 05 | Cloudflare Workers, TypeScript | Exception intake | Small server-side request handling | Persistence, access and integrations |
These are illustrative starting points, not a ranking. A Python script may be the complete solution; a complex dashboard may still be unnecessary.
The underlying concepts
How do separate applications communicate?
A frontend presents information and responds to the user. A backend runs trusted operations and applies server-side rules. An API is an agreed interface through which one program requests data or an action from another. A request asks for something; a response reports what happened. JSON is a common text format for exchanging structured values.
An integration connects independently functioning pieces through an agreed boundary. That is different from adding a library inside one application. A database is another responsibility: it stores records when the workflow requires them, but it does not automatically enforce secure access.
The GRC problem
A dashboard and evidence checker that don't talk
The dashboard from Lesson 02 shows control statuses. The Python checker from Lesson 04 can evaluate fictional evidence. If an analyst copies results between them, the dashboard may become stale and the reason behind a status may be lost. Connecting the two is useful only if the team needs updated results in the interface.
Meet the combined stack
Shows the selected control, status, explanation, and check time.
Provides a documented HTTP endpoint the dashboard can request.
Evaluates evidence against an explicit rule and returns a result.
Gives both sides an agreed shape for the result.
FastAPI is not required to run a Python check. It becomes relevant when another application needs to ask for results on demand.
Under the hood
Follow one evidence result through the system
Imagine a reviewer opens a fictional control in the dashboard. The interface requests the latest result, the backend checks the evidence, and the interface displays the answer. Each step has a distinct responsibility.
Opens a control in React
Dashboard asks FastAPI for its status
Evaluates fictional evidence and a rule
Returns status, reason, and checkedAt
Shows Pass, Fail, or Unknown and the explanation
For example, a response could contain controlId, status, reason, and checkedAt. The meaning of Unknown matters: missing evidence or a failed request must never silently become Pass.
In a real deployment, the trusted service—not the browser—must enforce authorization. Cloud credentials stay server-side, and the team must decide how errors, logs, and historical evidence are handled.
Understand the tradeoffs
When is connecting systems worth it?
Integration can reuse an existing Python checker, reduce manual copying, and serve several interfaces. It also introduces more deployment steps, network failures, authentication decisions, logging, version compatibility, and maintenance.
A simpler alternative: If results change only once a week, Python could generate a static report that the dashboard reads. No continuously running API may be necessary. If evidence must be retained for audits, add an appropriately controlled record store. If multiple tools need live results, an API becomes more valuable. If checks must run on a schedule, add scheduling deliberately rather than confusing it with the API itself.
What would change the stack? Shared protected records, historical retention, live cloud credentials, automatic refresh, and additional consumers can each change the architecture. They do not necessarily require rewriting every component.