Server routes and API in Vue - Step-by-Step Execution

Concept Flow - Server routes and API

User sends request

↓

Server receives request

↓

Match request to route

↓

Execute route handler

↓

Fetch or process data

↓

Send response back

↓

Client receives data

↓

Vue app updates UI

This flow shows how a user request goes to the server, the server matches it to a route, processes it, and sends back data that the Vue app uses to update the screen.

Execution Sample

Vue

import { createRouter, createWebHistory } from 'vue-router';

const routes = [
  { path: '/data', component: DataComponent }
];

const router = createRouter({ history: createWebHistory(), routes });

This code sets up a Vue router with a route that matches '/data' and loads a component to handle it.

Execution Table

Step	Action	Input/Request	Route Matched	Handler Action	Response Sent	Client UI Update
1	User sends request	GET /api/data	Matches '/api/data'	Fetch data from API	JSON data sent	UI shows new data
2	User sends request	GET /api/unknown	No match	Return 404 error	Error message sent	UI shows error message
3	User sends request	POST /api/data	Matches '/api/data'	Save data to server	Success message sent	UI shows confirmation
4	End	No more requests	N/A	N/A	N/A	No UI change

💡 Execution stops when no more user requests are sent.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
request	null	GET /api/data	GET /api/unknown	POST /api/data	null
routeMatched	false	true	false	true	false
response	null	JSON data	404 error	Success message	null
uiState	empty	shows data	shows error	shows confirmation	stable

Key Moments - 3 Insights

Why does the server return a 404 error for some requests?

Because the request path does not match any defined route, as shown in execution_table row 2 where 'GET /api/unknown' has no routeMatched.

How does the Vue app know when to update the UI?

The Vue app updates UI after receiving a response from the server, as seen in execution_table column 'Client UI Update' after each successful response.

What happens if the server receives a POST request on a GET-only route?

If the route handler supports POST, it processes the data; otherwise, it may return an error. In the example, POST /api/data is handled and sends a success message (row 3).

Visual Quiz - 3 Questions

Look at the execution table, what is the response sent at step 1?

A 404 error

B Success message

C JSON data sent

D No response

💡 Hint

Check the 'Response Sent' column in row 1 of the execution_table.

At which step does the route not match any defined path?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Route Matched' column for 'false' value in the execution_table.

If the user sends a GET request to '/api/data', what will the UI show?

A Error message

B New data

C Confirmation message

D No change

💡 Hint

Refer to 'Client UI Update' column in execution_table row 1.

Concept Snapshot

Server routes handle user requests by matching paths.
Handlers process data and send responses.
Vue app updates UI based on server responses.
Routes must be defined to avoid 404 errors.
POST and GET requests can have different handlers.

Full Transcript

When a user sends a request, the server checks if the request path matches any route. If it matches, the server runs the handler to fetch or save data and sends a response back. The Vue app listens for this response and updates the UI accordingly. If no route matches, the server sends a 404 error. Different HTTP methods like GET and POST can trigger different actions on the same route.

Practice

1. What is the main purpose of server routes in a Vue app using Nitro?

easy

A. To style the frontend components

B. To handle backend requests and send responses

C. To manage client-side state only

D. To create animations on the page

Solution

1. Step 1: Understand server routes role

   Server routes act as backend endpoints that receive requests from the frontend.

2. Step 2: Identify their function in Vue Nitro

   They process these requests and return data or responses, enabling communication between frontend and backend.

3. Final Answer:

   To handle backend requests and send responses -> Option B

4. Quick Check:

   Server routes = backend communication [OK]

Hint: Server routes handle backend requests, not frontend styling [OK]

Common Mistakes:

• Confusing server routes with frontend styling
• Thinking server routes manage only client state
• Assuming server routes create animations

2. Which of the following is the correct way to define a server route in a Vue Nitro project?

easy

A. app.get('/api', () => 'Hello')

B. const route = () => { console.log('Hello') }

C. export default defineEventHandler(() => { return { message: 'Hello' } })

D. function serverRoute() { return 'Hello' }

Solution

1. Step 1: Recognize Nitro server route syntax

   In Vue Nitro, server routes export a default function using defineEventHandler that returns data.

2. Step 2: Check each option

   export default defineEventHandler(() => { return { message: 'Hello' } }) uses defineEventHandler and returns an object, which is correct. Others either lack export, use wrong syntax, or are not Nitro style.

3. Final Answer:

   export default defineEventHandler(() => { return { message: 'Hello' } }) -> Option C

4. Quick Check:

   Use defineEventHandler for Nitro routes [OK]

Hint: Look for export default with defineEventHandler [OK]

Common Mistakes:

• Missing export default
• Not using defineEventHandler
• Using Express.js style instead of Nitro

3. Given this server route code in Vue Nitro:

export default defineEventHandler(() => { return { status: 'ok', count: 5 } })

What will the frontend receive when calling this API?

medium

A. Undefined

B. A string 'ok5'

C. An error because of missing await

D. { status: 'ok', count: 5 }

Solution

1. Step 1: Analyze the returned object

   The route returns an object with keys status and count, so the response is JSON with those values.

2. Step 2: Understand Nitro response behavior

   Nitro automatically serializes the returned object to JSON for the frontend.

3. Final Answer:

   { status: 'ok', count: 5 } -> Option D

4. Quick Check:

   Returned object = JSON response [OK]

Hint: Returned object becomes JSON response automatically [OK]

Common Mistakes:

• Expecting string concatenation
• Thinking await is needed for sync return
• Assuming undefined if no explicit JSON

4. What is wrong with this Vue Nitro server route code?

export default () => { return { message: 'Hi' } }

medium

A. Missing defineEventHandler wrapper

B. Return value must be a string

C. Export default is not allowed

D. Arrow function syntax is invalid

Solution

1. Step 1: Check Nitro route requirements

   Vue Nitro requires server routes to export a default function wrapped with defineEventHandler.

2. Step 2: Identify missing part

   The code exports a function but does not use defineEventHandler, so it won't work as a proper Nitro route.

3. Final Answer:

   Missing defineEventHandler wrapper -> Option A

4. Quick Check:

   Always wrap route with defineEventHandler [OK]

Hint: Always use defineEventHandler for server routes [OK]

Common Mistakes:

• Forgetting defineEventHandler
• Thinking return must be string
• Confusing export default rules

5. You want to create a server route in Vue Nitro that returns a list of users filtered by a query parameter `role`. Which code correctly accesses the query and returns filtered users?

hard

A. export default defineEventHandler(event => { const role = getQuery(event).role; return users.filter(u => u.role === role) })

B. export default defineEventHandler(() => { return users })

C. export default defineEventHandler(event => { const role = event.node.req.url.split('role=')[1]; return users.filter(u => u.role === role) })

D. export default defineEventHandler(event => { const role = event.query.role; return users.filter(u => u.role === role) })

Solution

1. Step 1: Understand query access in Nitro

   Vue Nitro provides a helper getQuery(event) to safely get query parameters from the request.

2. Step 2: Check each option for correct query usage

   export default defineEventHandler(event => { const role = getQuery(event).role; return users.filter(u => u.role === role) }) uses getQuery(event).role correctly. export default defineEventHandler(event => { const role = event.node.req.url.split('role=')[1]; return users.filter(u => u.role === role) }) manually parses URL which is error-prone. export default defineEventHandler(() => { return users }) ignores query. export default defineEventHandler(event => { const role = event.query.role; return users.filter(u => u.role === role) }) uses event.query which is not standard.

3. Final Answer:

   export default defineEventHandler(event => { const role = getQuery(event).role; return users.filter(u => u.role === role) }) -> Option A

4. Quick Check:

   Use getQuery(event) to read query params [OK]

Hint: Use getQuery(event) to access query parameters [OK]

Common Mistakes:

• Parsing URL manually instead of getQuery
• Using event.query which is undefined
• Ignoring query parameters