The GRC Vibe Coding Recipe Book · Lesson 05 of 07
Create a Hosted Exception Intake
Use Cloudflare Workers and TypeScript when a browser needs a trusted service.
All 7 Lessons · Jump to a Lesson
Recipe 05 · At a glance
Cloudflare Workers + TypeScript
GRC use case: Hosted exception intake
Ingredients: TypeScript defines the endpoint · Cloudflare Workers runs it · D1 is optional for persistent records
Know the boundary: Validate requests server-side; add access controls and storage deliberately.
The GRC problem
Why would a team need this?
Employees need to submit exception requests, but putting privileged processing directly in a public form would expose sensitive operations.
A static exception form backed by one small hosted endpoint. This gives us a useful way to understand the technologies involved: start with the work people need to accomplish, then consider what the application must do to support them.
The underlying concepts
What changes from the previous lesson?
The browser is good at presenting a request, but it should not hold secrets or decide who may perform privileged operations. A Cloudflare Worker provides a small server-side boundary. Adding a database such as D1 is a different choice, justified when requests must be saved.
Remember the four responsibilities from Lesson 01: interface, application logic, storage, and hosting. As requirements become more demanding, those responsibilities may need different technologies. More sophisticated does not automatically mean better.
Meet the stack
What does each technology contribute?
HTML, CSS, and JavaScript display the form. A Cloudflare Worker runs TypeScript on a trusted service. D1 is an optional database only when shared requests must persist.
HTML/CSS/JavaScript or a static frontend on Cloudflare Pages
TypeScript functions on Cloudflare Workers
No database for stateless operations; D1 when structured shared records are needed
GitHub
These ingredients have distinct responsibilities. Understanding those boundaries is more useful than memorizing a list of popular tools, because it helps you recognize when a project needs something different.
Under the hood
How would the information move?
Follow a single piece of information through the example. The input starts with a person or an existing record, a rule transforms or validates it, and the interface or report presents the result.
A fictional control ID, exception reason, and requested review date.
The browser sends a request to the Worker. The Worker validates the fields and returns a structured response.
A confirmation or a clear validation error.
The location of the rule matters. A browser can update its own display, but decisions about access to protected records must be enforced by a trusted service. A database stores information; it does not, by itself, make the surrounding application secure.
Understand the limits
What would change the stack?
Add authentication, rate limits, and durable storage before using it for real internal requests.
There is also a reason not to add more technology yet: If the tool only displays a quiz or calculates a fictional score in the browser, a Worker and D1 add complexity without a clear benefit.
What to remember: A public endpoint is not automatically secure. Validate requests on the server, authenticate sensitive actions, limit abuse, and keep secrets out of browser code. A good stack is one whose responsibilities and tradeoffs you can explain, not necessarily one with the most features.