Self-hosting with Node.js in NextJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this Next.js server component when self-hosted with Node.js?

Consider this simple Next.js server component that fetches data and renders it. What will be the rendered output when accessed via a Node.js self-hosted server?

NextJS

import React from 'react';

export default async function Greeting() {
  const data = await Promise.resolve({ name: 'Alice' });
  return <h1>Hello, {data.name}!</h1>;
}

A Error: Cannot use await in this context

B <h1>Hello, undefined!</h1>

C <h1>Hello, Alice!</h1>

D <h1>Hello, !</h1>

💡 Hint

Think about how Next.js server components handle async data fetching.

Next.js server components support async functions and await data fetching. The component resolves the promise and renders the name 'Alice' inside the <h1> tag.

❓ lifecycle

intermediate

Which lifecycle behavior is true for Next.js API routes when self-hosted with Node.js?

When you self-host a Next.js API route on Node.js, which statement about its lifecycle is correct?

A The API route runs once at server start and caches all responses.

B The API route runs only once per user session.

C The API route runs only on client-side navigation events.

D The API route runs on every request, creating a new instance each time.

💡 Hint

Think about how serverless functions behave in a Node.js environment.

Next.js API routes are functions that run on every HTTP request, creating a new context each time. They do not cache responses by default.

🔧 Debug

advanced

Why does this self-hosted Next.js app fail to start with Node.js?

Examine the following server start script. Why does it fail with a syntax error?

NextJS

import { createServer } from 'http';
import next from 'next';

const app = next({ dev: false });
const handle = app.getRequestHandler();

createServer((req, res) => {
  app.prepare().then(() => {
    handle(req, res);
  });
}).listen(3000, () => {
  console.log('Server running on http://localhost:3000');
});

A TypeError because 'app.prepare' is not a function.

B SyntaxError because 'import' cannot be used in CommonJS without 'type: module'.

C Runtime error because 'handle' is undefined.

D No error; the code runs correctly.

💡 Hint

Check the Node.js module system compatibility with ES modules.

Using 'import' statements requires the Node.js environment to support ES modules, typically by setting 'type: module' in package.json or using .mjs files. Otherwise, a SyntaxError occurs.

📝 Syntax

advanced

Which option correctly configures a Next.js custom server with Express for self-hosting?

Choose the correct code snippet to create a custom Express server that handles Next.js pages.

A

const express = require('express');
const next = require('next');

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();
  server.all('*', (req, res) => handle(req, res));
  server.listen(3000);
});

B

import express from 'express';
import next from 'next';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();
  server.get('/', (req, res) => handle(req, res));
  server.listen(3000);
});

C

import express from 'express';
import next from 'next';

const app = next({ dev: true });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();
  server.use((req, res) => handle(req, res));
  server.listen(3000);
});

D

import express from 'express';
import next from 'next';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();
  server.get('*', (req, res) => handle(req, res));
  server.listen(3000);
});

💡 Hint

Consider which HTTP methods and routes should be handled to serve all Next.js pages.

Option A uses CommonJS syntax with 'require', handles all HTTP methods with 'server.all', and routes all paths with '*', which correctly serves all Next.js pages.

🧠 Conceptual

expert

What is the main advantage of self-hosting a Next.js app with Node.js over using Vercel's platform?

Choose the best explanation for why a developer might choose to self-host a Next.js app using Node.js instead of deploying on Vercel.

A Self-hosting allows full control over the server environment and custom backend integrations.

B Self-hosting automatically scales the app globally without configuration.

C Self-hosting eliminates the need to write API routes or server components.

D Self-hosting guarantees zero downtime without any additional setup.

💡 Hint

Think about flexibility and control versus managed services.

Self-hosting gives developers full control over the server, environment, and backend integrations, which is not always possible on managed platforms like Vercel.

Practice

1. What does self-hosting a Next.js app with Node.js mean?

easy

A. Running Next.js only in the browser without Node.js

B. Using a third-party service to host your Next.js app

C. Building the app without a server

D. Running your Next.js app on your own server using Node.js

Solution

1. Step 1: Understand self-hosting concept

   Self-hosting means you run the app on your own server, not a third-party service.

2. Step 2: Connect self-hosting with Node.js

   Next.js apps use Node.js to serve the app on your server, giving you control.

3. Final Answer:

   Running your Next.js app on your own server using Node.js -> Option D

4. Quick Check:

   Self-hosting = Running on own server [OK]

Hint: Self-hosting means running on your own server [OK]

Common Mistakes:

• Confusing self-hosting with using cloud services
• Thinking Next.js runs only in the browser
• Believing no server is needed for Next.js

2. Which command correctly starts a Next.js app in production mode with Node.js?

easy

A. next start

B. node next

C. next dev

D. npm run build

Solution

1. Step 1: Identify production start command

   After building, next start runs the app in production mode with Node.js.

2. Step 2: Check other commands

   next dev is for development, npm run build builds but doesn't start, node next is invalid.

3. Final Answer:

   next start -> Option A

4. Quick Check:

   Production start = next start [OK]

Hint: Use 'next start' to run production server [OK]

Common Mistakes:

• Using 'next dev' for production
• Trying to run 'node next' directly
• Confusing build and start commands

3. Given this Node.js server code for Next.js, what will happen when you run it?

import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  http.createServer((req, res) => {
    handle(req, res);
  }).listen(3000, () => {
    console.log('Server running on http://localhost:3000');
  });
});

medium

A. Throws an error because 'next' cannot be imported this way

B. Starts a Next.js server on port 3000 serving production build

C. Starts a development server with hot reload

D. Server runs but does not handle Next.js requests

Solution

1. Step 1: Analyze server setup

   The code imports Next.js, sets dev to false (production), prepares app, then creates an HTTP server that uses Next.js request handler.

2. Step 2: Understand server behavior

   The server listens on port 3000 and serves the production Next.js app correctly.

3. Final Answer:

   Starts a Next.js server on port 3000 serving production build -> Option B

4. Quick Check:

   Node.js server with Next.js handler = production server [OK]

Hint: dev: false means production server starts [OK]

Common Mistakes:

• Thinking import syntax is invalid in Node.js
• Assuming dev: false means development mode
• Believing server does not handle Next.js requests

4. You wrote this code to self-host your Next.js app but get no confirmation message:

import next from 'next';
import http from 'http';

const app = next({ dev: true });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  http.createServer((req, res) => {
    handle(req, res);
  }).listen(3000);
});

What is the likely cause of the issue?

medium

A. You must build the app before running with dev: true

B. Using dev: true disables the HTTP server

C. You forgot to add a callback to listen()

D. You cannot use 'http' module with Next.js

Solution

1. Step 1: Check listen() usage

   The listen method works without a callback, but missing callback means no confirmation message that the server started.

2. Step 2: Rule out other options

   dev: true enables development mode (no build needed), doesn't disable HTTP server, and http module is compatible with Next.js custom servers.

3. Step 3: Confirm the issue

   You forgot to add a callback to listen() identifies the missing callback, which prevents the confirmation log like 'Server running...' seen in working examples.

4. Final Answer:

   You forgot to add a callback to listen() -> Option C

5. Quick Check:

   Missing listen callback = no start confirmation [OK]

Hint: Add listen callback to confirm server start [OK]

Common Mistakes:

• Thinking dev: true disables server
• Believing http module is incompatible
• Assuming build is required for dev mode

5. You want to self-host a Next.js app with Node.js and add a custom API route that logs requests before handling them. Which code snippet correctly adds this feature?

hard

A. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
console.log(`Request URL: ${req.url}`);
handle(req, res);
}).listen(3000, () => {
console.log('Server running on http://localhost:3000');
});
});

B. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
handle(req, res);
console.log(`Request URL: ${req.url}`);
}).listen(3000);
});

C. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
res.writeHead(200);
res.end('Logged request');
console.log(`Request URL: ${req.url}`);
}).listen(3000);
});

D. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
console.log(`Request URL: ${req.url}`);
}).listen(3000);
});

Solution

1. Step 1: Identify correct request logging order

   Logging the request URL before calling handle(req, res) ensures the log happens before Next.js processes the request.

2. Step 2: Check response handling

   import next from 'next';
   import http from 'http';
   
   const app = next({ dev: false });
   const handle = app.getRequestHandler();
   
   app.prepare().then(() => {
     http.createServer((req, res) => {
       console.log(`Request URL: ${req.url}`);
       handle(req, res);
     }).listen(3000, () => {
       console.log('Server running on http://localhost:3000');
     });
   });

   calls handle after logging, letting Next.js handle the response properly. Other options either log after response or do not call handle.

3. Step 3: Confirm server start callback

   import next from 'next';
   import http from 'http';
   
   const app = next({ dev: false });
   const handle = app.getRequestHandler();
   
   app.prepare().then(() => {
     http.createServer((req, res) => {
       console.log(`Request URL: ${req.url}`);
       handle(req, res);
     }).listen(3000, () => {
       console.log('Server running on http://localhost:3000');
     });
   });

   includes a listen callback to confirm server is running, which is good practice.

4. Final Answer:

   Code snippet with console.log before handle(req, res) -> Option A

5. Quick Check:

   Log before handle() for correct request processing [OK]

Hint: Log requests before calling handle() to capture all requests [OK]

Common Mistakes:

• Logging after response ends, missing some requests
• Not calling handle(), breaking Next.js routing
• Omitting server start confirmation callback