Why production setup matters in Express - Challenge Your Understanding

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens if you use express's default error handler in production?

Consider an Express app running in production mode using the default error handler. What will the user see if an error occurs?

Express

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

app.get('/', (req, res) => {
  throw new Error('Oops!');
});

app.listen(3000);

A The user is redirected to a custom error page automatically.

B The server crashes and stops responding to requests.

C The user sees a detailed stack trace and error message in the browser.

D The user sees a generic error message without stack trace details.

💡 Hint

Think about what Express does by default when no custom error handler is set.

By default, Express's error handler shows detailed error stack traces only in development mode. In production, it shows a generic message. However, if NODE_ENV is not set to 'production', the detailed error is shown even in production.

❓ state_output

intermediate

What is the effect of disabling 'x-powered-by' header in Express production?

In Express, what is the effect of calling app.disable('x-powered-by') in a production setup?

Express

const express = require('express');
const app = express();
app.disable('x-powered-by');

app.get('/', (req, res) => {
  res.send('Hello');
});

app.listen(3000);

A It removes the 'X-Powered-By' header from HTTP responses, hiding Express usage.

B It disables all HTTP headers for security reasons.

C It enables detailed error messages for debugging.

D It forces HTTPS connections automatically.

💡 Hint

Think about what the 'X-Powered-By' header does in HTTP responses.

The 'X-Powered-By' header reveals the server technology (Express). Disabling it helps reduce information leakage to attackers.

📝 Syntax

advanced

Which middleware setup is correct for production static files in Express?

Choose the correct way to serve static files efficiently in production with Express.

A app.use(express.static('public', { maxAge: '1d' }));

B app.use(express.static('public', { cacheControl: false }));

C app.use(express.static('public', { maxAge: 0 }));

D app.use(express.static('public', { etag: false }));

💡 Hint

Think about how to enable browser caching for static files.

Setting maxAge to '1d' tells browsers to cache static files for one day, improving performance in production.

🔧 Debug

advanced

Why does this Express app crash in production but not in development?

Given this Express app code, why does it crash in production but works fine in development?

Express

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

app.get('/', (req, res) => {
  setTimeout(() => {
    throw new Error('Delayed error');
  }, 100);
  res.send('Hello');
});

app.listen(3000);

A The app crashes because res.send is called twice.

B The app crashes because the port 3000 is already in use.

C Uncaught errors in asynchronous callbacks crash the app; no error handler catches them.

D The app crashes because setTimeout is not supported in production.

💡 Hint

Think about how Express handles errors thrown inside asynchronous code.

Errors thrown inside asynchronous callbacks like setTimeout are not caught by Express error handlers and cause the Node.js process to crash unless handled explicitly.

🧠 Conceptual

expert

Why is setting NODE_ENV to 'production' critical in Express apps?

Why must you set the environment variable NODE_ENV to 'production' when deploying an Express app?

A It automatically enables HTTPS and security headers.

B It enables Express to optimize performance and disable verbose error messages.

C It forces the app to use a production database connection string.

D It disables all middleware except static file serving.

💡 Hint

Consider what changes Express makes based on NODE_ENV.

Setting NODE_ENV to 'production' tells Express to run in optimized mode, disabling detailed error messages and enabling performance improvements.