Explore Deno 2 and Fresh's vocabulary — island architecture, built-in KV storage, the permissions model, and server-side rendering.
0 / 5 completed
1 / 5
During a design review, a teammate asks why Fresh routes don't need a build step. The answer relates to Fresh's architecture:
Fresh renders HTML on the server for every request — no build step. Only explicitly defined islands ship JavaScript to the browser, keeping client bundles minimal by default.
2 / 5
In a PR review, a Fresh page includes a component in an islands/ directory. A reviewer asks what makes an island different from a regular Fresh component. The answer is:
Fresh islands (files in islands/) are Preact components that ship JavaScript to the browser for client-side interactivity. Non-island components are server-rendered to static HTML with no JS hydration.
3 / 5
A standup question: the team wants to use Deno's built-in key-value store for session data. You propose Deno.openKv(). What does it provide?
Deno.openKv() opens Deno's built-in KV store — backed by FoundationDB on Deno Deploy. It supports atomic transactions, key expiry, and queued messages with no extra infrastructure.
4 / 5
In a code review, a Fresh handler file is missing the Handlers export. A junior asks what happens without it. The correct answer is:
In Fresh, a route file without a Handlers export is a render-only page — Fresh serves it via GET using the default-exported component. Handlers is needed only for custom GET logic or other HTTP methods.
5 / 5
During a security review, a colleague asks how Deno 2's permissions model protects production deployments. The correct description is:
Deno's permissions model requires explicit flags (--allow-net=api.example.com, --allow-read=/data, etc.) before code can access any resource. This principle-of-least-privilege approach limits blast radius from compromised dependencies.