Why guards control access in NestJS - Visual Breakdown

Concept Flow - Why guards control access

Request Received

↓

Guard Checks Conditions

↓

Allow

↓

Controller Executes

When a request comes in, the guard checks if access is allowed. If yes, the controller runs. If no, access is denied.

Execution Sample

NestJS

canActivate(context: ExecutionContext): boolean {
  const request = context.switchToHttp().getRequest();
  return request.user?.isAdmin === true;
}

This guard checks if the user is an admin before allowing access.

Execution Table

Step	Action	Input	Condition Checked	Result	Next Step
1	Receive request	{ user: { isAdmin: true } }	N/A	N/A	Check guard
2	Guard reads user	{ isAdmin: true }	user.isAdmin === true	True	Allow access
3	Controller runs	N/A	N/A	Request processed	Send response
4	Receive request	{ user: { isAdmin: false } }	N/A	N/A	Check guard
5	Guard reads user	{ isAdmin: false }	user.isAdmin === true	False	Deny access
6	Send error	N/A	N/A	403 Forbidden	End

💡 Execution stops when guard denies access or controller finishes processing.

Variable Tracker

Variable	Start	After Step 2	After Step 5	Final
request.user.isAdmin	undefined	true	false	N/A
canActivate result	undefined	true	false	N/A

Key Moments - 2 Insights

Why does the guard block access when user.isAdmin is false?

Because in the execution_table at step 5, the condition user.isAdmin === true evaluates to false, so the guard returns false and denies access.

What happens if the guard returns true?

As shown in execution_table step 2, if the guard returns true, the controller executes and processes the request.

Visual Quiz - 3 Questions

Look at the execution_table, what is the guard's result at step 2?

A False

B True

C Undefined

D Error

💡 Hint

Check the 'Result' column in execution_table row with Step 2.

At which step does the guard deny access?

A Step 5

B Step 1

C Step 3

D Step 6

💡 Hint

Look for where the condition user.isAdmin === true is false in execution_table.

If user.isAdmin was always true, what would change in the execution_table?

A The guard would throw an error.

B All requests would be denied.

C All requests would be allowed, no deny steps.

D The controller would never run.

💡 Hint

Refer to variable_tracker and see how canActivate result affects flow.

Concept Snapshot

Guards in NestJS check conditions before a controller runs.
They return true to allow access or false to deny it.
Guards control who can use routes.
They help protect resources by blocking unauthorized requests.
Use canActivate method to define guard logic.

Full Transcript

In NestJS, guards control access by checking conditions before a controller handles a request. When a request arrives, the guard's canActivate method runs. It looks at the request data, like user roles, and returns true or false. If true, the controller runs and processes the request. If false, the guard denies access and sends an error response. This way, guards protect routes from unauthorized users. For example, a guard can check if a user is an admin. If yes, access is allowed; if no, access is blocked. This flow ensures only allowed users reach the controller.