📖 Scenario: You are building a simple Deno server to handle user requests in a production environment. You want to understand why careful architecture is important to keep the server reliable, maintainable, and secure.
🎯 Goal: Build a basic Deno server with clear separation of concerns and configuration to demonstrate the need for careful architecture in production.
📋 What You'll Learn
Create a data structure to hold user information
Add a configuration variable for maximum allowed users
Implement core logic to filter users based on the configuration
Complete the server setup with proper routing and response
💡 Why This Matters
🌍 Real World
In real production Deno servers, clear architecture helps keep code maintainable, secure, and scalable as the app grows.
💼 Career
Understanding how to structure Deno projects with data, config, and server logic is key for backend developers working with modern JavaScript runtimes.
Progress0 / 4 steps
1
DATA SETUP: Create user data
Create a constant called users that is an array of objects with these exact entries: { id: 1, name: "Alice" }, { id: 2, name: "Bob" }, and { id: 3, name: "Charlie" }.
Deno
Hint
Use const users = [ ... ] with objects inside the array.
2
CONFIGURATION: Set maximum users allowed
Create a constant called maxUsers and set it to the number 2.
Deno
Hint
Use const maxUsers = 2; to set the limit.
3
CORE LOGIC: Filter users based on maxUsers
Create a constant called activeUsers that contains the first maxUsers entries from the users array using the slice method.
Deno
Hint
Use slice(0, maxUsers) to get the first users.
4
COMPLETION: Setup Deno server to respond with active users
Import serve from "https://deno.land/std@0.177.0/http/server.ts". Then call serve with an async function that returns a new Response with JSON.stringify(activeUsers) and header {"Content-Type": "application/json"}.
Deno
Hint
Use serve with an async function returning a JSON response of activeUsers.
Practice
(1/5)
1. Why is it important to plan permissions carefully when deploying a Deno app to production?
easy
A. Because Deno restricts access to files, network, and environment by default for security.
B. Because Deno automatically grants all permissions to any script.
C. Because permissions do not affect Deno apps in production.
D. Because permissions only matter during development, not in production.
Solution
Step 1: Understand Deno's default security model
Deno runs scripts with no permissions by default to protect your system.
Step 2: Recognize the need for explicit permission granting in production
In production, you must carefully grant only needed permissions to avoid security risks.
Final Answer:
Because Deno restricts access to files, network, and environment by default for security. -> Option A
Deno denies file read access unless --allow-read is given.
Step 2: Identify the error from missing permission
Running without --allow-read causes a PermissionDenied error.
Final Answer:
PermissionDenied: read access to "data.txt" is not allowed -> Option B
Quick Check:
Missing --allow-read causes PermissionDenied [OK]
Hint: No --allow-read means PermissionDenied error [OK]
Common Mistakes:
Expecting syntax or reference errors
Assuming script runs without permissions
Confusing permission errors with runtime errors
5. You want to build a Deno app that reads a config file, fetches data from an API, and writes logs to a file. Which architecture approach best ensures security and maintainability in production?
hard
A. Grant all permissions globally and write all code in one file.
B. Run the app without permissions and rely on user input for data.
C. Use modular code, grant only needed permissions per module, and handle errors properly.
D. Avoid error handling to keep code simple and grant all permissions at runtime.
Solution
Step 1: Consider security by limiting permissions
Grant only the permissions each module needs to reduce risk.