1. Embrace the Single Responsibility Principle (SRP)

Each microservice should do one thing and do it well. Avoid creating "mini-monoliths."

• Why: Simplifies development, testing, deployment, and scaling of individual services. Changes in one service are less likely to impact others.

• How: Clearly define the bounded context for each service. For example, an e-commerce application might have separate services for users, products, orders, and payments.

2. Design for Statelessness

Whenever possible, your Node.js microservices should be stateless.

• Why: Stateless services are easier to scale horizontally, replace, and load balance. State can be offloaded to dedicated state stores (databases, caches).

• How: Avoid storing session data or any request-specific state in the service's memory. If state is needed, retrieve it from an external store (e.g., Redis, PostgreSQL, MongoDB) on each request or use techniques like JWTs for session information.

// Bad: Storing session in memory
 const sessions = {};
 app.post('/login', (req, res) => {
   const sessionId = generateSessionId();
   sessions[sessionId] = { userId: req.body.userId };
   res.cookie('sessionId', sessionId).send('Logged in');
 });

// Good: Using JWT (stateless)
 app.post('/login', (req, res) => {
   const user = authenticateUser(req.body.username, req.body.password);
   if (user) {
     const token = jwt.sign({ userId: user.id }, process.env.JWT_SECRET, { expiresIn: '1h' });
     res.json({ token });
   } else {
     res.status(401).send('Authentication failed');
   }
 });

3. Centralized Configuration Management

Externalize your configuration. Don't hardcode connection strings, API keys, or environment-specific settings.

• Why: Allows for different configurations across environments (dev, staging, prod) without code changes. Enhances security by keeping secrets out of the codebase.

• How:

  • Use environment variables (e.g., process.env.DATABASE_URL).

  • Employ configuration management tools like HashiCorp Consul, AWS Parameter Store, or Azure App Configuration.

  • Use .env files for local development (e.g., with the dotenv package).

// config.js
import dotenv from "dotenv";
dotenv.config(); // Loads .env file into process.env

export const config = {
  port: process.env.PORT || 3000,
  databaseUrl: process.env.DATABASE_URL,
  apiKey: process.env.API_KEY,
  // ... other configurations
};

4. Implement Comprehensive Logging and Monitoring

In a distributed system, understanding what's happening is critical.

• Why: Essential for debugging, tracing requests across services, and identifying performance bottlenecks.

• How:

  • Structured Logging: Use JSON or another machine-readable format. Libraries like pino or winston are excellent. Include correlation IDs to trace requests across multiple services.

  • Centralized Logging: Ship logs to a central logging platform (e.g., ELK Stack, Splunk, Datadog).

  • Monitoring & Alerting: Track key metrics (CPU, memory, latency, error rates) using tools like Prometheus/Grafana, Datadog, or New Relic. Set up alerts for critical issues.

// Using pino for structured logging
import pino from "pino";
const logger = pino({
  level: process.env.LOG_LEVEL || "info",
  // Add a correlationId hook if using a request context
});

// logger.info({ orderId: '123', userId: 'abc' }, 'Order processed');

5. Expose Health Check Endpoints

Each microservice should expose a health check endpoint.

• Why: Orchestration tools (like Kubernetes) and load balancers use these to determine if a service instance is healthy and ready to receive traffic.

• How: Create an HTTP endpoint (e.g., /healthz or /status) that checks the status of critical dependencies (database connections, external service availability) and returns a success (e.g., 200 OK) or failure status.

// Example health check in an Express app
app.get("/healthz", (req, res) => {
  // Perform checks (e.g., database connectivity)
  const isHealthy = checkDatabaseConnection() && checkExternalService();
  if (isHealthy) {
    res.status(200).send("OK");
  } else {
    res.status(503).send("Service Unavailable"); // 503 Service Unavailable
  }
});

6. Utilize Asynchronous Communication

For non-blocking operations and inter-service communication where an immediate response isn't required, use asynchronous patterns.

• Why: Improves resilience (if a service is temporarily down, messages can be queued) and decoupling. Prevents cascading failures.

• How: Use message brokers like RabbitMQ, Kafka, AWS SQS, or Google Pub/Sub. Node.js excels at handling these asynchronous workflows.

7. Design Consistent and Versioned APIs

Whether you choose REST, GraphQL, or gRPC, ensure your APIs are well-defined, consistent, and versioned.

• Why: Makes services easier to consume and evolve independently.

• How:

  • REST: Use standard HTTP methods, status codes, and clear resource naming. Version APIs (e.g., /v1/users).

  • GraphQL: Consider GraphQL Federation if you have many services contributing to a unified data graph (as discussed previously).

  • gRPC: For high-performance internal communication, especially if you have polyglot services.

  • Use tools like OpenAPI (Swagger) for REST API documentation and contract definition.

8. Implement Robust Error Handling

Gracefully handle errors and provide meaningful error responses.

• Why: Prevents service crashes and helps consumers understand issues.

• How:

  • Use try...catch for synchronous code and .catch() for Promises.

  • Implement global error handlers in your framework (e.g., Express error-handling middleware).

  • Return appropriate HTTP status codes and error messages.

  • Avoid leaking sensitive stack traces in production.

9. Prioritize Security

Security is paramount, especially in a distributed environment.

• Why: More services mean more potential attack surfaces.

• How:

  • Authentication & Authorization: Secure service-to-service communication (e.g., OAuth 2.0, JWTs, mTLS).

  • Input Validation: Validate all incoming data (payloads, query params, headers). Libraries like joi or zod are helpful.

  • Rate Limiting & Throttling: Protect services from abuse.

  • Secrets Management: Use tools like HashiCorp Vault or cloud provider KMS.

  • Regular Dependency Scans: Use npm audit or tools like Snyk to find and fix vulnerabilities in dependencies.

10. Containerize Your Services (Docker)

Package your Node.js microservices into Docker containers.

• Why: Ensures consistency across environments, simplifies deployment, and works well with orchestration platforms like Kubernetes.

• How: Write efficient Dockerfiles. Use multi-stage builds to keep image sizes small.

# Dockerfile example (simplified)
FROM node:18-alpine AS builder
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
# RUN npm run build # If you have a build step

FROM node:18-alpine
WORKDIR /usr/src/app
COPY --from=builder /usr/src/app/node_modules ./node_modules
COPY --from=builder /usr/src/app/dist ./dist # Or copy source if no build
COPY --from=builder /usr/src/app/package.json ./
EXPOSE 3000
CMD [ "node", "dist/server.js" ] # Or your entry point

11. Comprehensive Testing Strategy

• Why: Ensures reliability and allows for confident refactoring and deployments.

• How:

  • Unit Tests: Test individual modules/functions in isolation (e.g., using Jest, Mocha).

  • Integration Tests: Test interactions between your service and its direct dependencies (e.g., database, external APIs).

  • Contract Tests: Verify that services adhere to their API contracts (e.g., using Pact). This is crucial for inter-service communication.

12. Choose Lightweight Frameworks

While Express.js is very popular and flexible, consider even more lightweight frameworks if your microservice is very focused.

• Why: Smaller footprint, faster startup times.

• How: Frameworks like Fastify are known for high performance and low overhead. For very simple services, you might even use the native http module, though a minimal framework often provides useful abstractions.

Conclusion

Building Node.js microservices effectively requires a shift in mindset from monolithic development. By focusing on these best practices, you can create a distributed system that is scalable, resilient, maintainable, and leverages the strengths of Node.js. Remember that these are guidelines; adapt them to your specific project needs and team capabilities.

Enter Object.groupBy() and Map.groupBy() – two new static methods that provide a more declarative and concise way to achieve this common task. [8, 11] They take an iterable (like an array) and a callback function. The callback function determines the key under which each element should be grouped.

The Power of Grouping, Simplified

Imagine you have an array of product objects, and you want to group them by their category.

Before Object.groupBy():

const products = [
  { name: "Laptop", category: "Electronics", price: 1200 },
  { name: "Shirt", category: "Apparel", price: 50 },
  { name: "Keyboard", category: "Electronics", price: 75 },
  { name: "Jeans", category: "Apparel", price: 80 },
  { name: "Mouse", category: "Electronics", price: 25 },
];

// Using reduce (a common pre-ES2024 approach)
const productsByCategoryOld = products.reduce((acc, product) => {
  const key = product.category;
  if (!acc[key]) {
    acc[key] = [];
  }
  acc[key].push(product);
  return acc;
}, {});

console.log(productsByCategoryOld);
/*
Output:
{
  Electronics: [
    { name: 'Laptop', category: 'Electronics', price: 1200 },
    { name: 'Keyboard', category: 'Electronics', price: 75 },
    { name: 'Mouse', category: 'Electronics', price: 25 }
  ],
  Apparel: [
    { name: 'Shirt', category: 'Apparel', price: 50 },
    { name: 'Jeans', category: 'Apparel', price: 80 }
  ]
}
*/

This works, but it requires a bit of boilerplate to initialize the arrays for each group.

With Object.groupBy():

Now, let's see how Object.groupBy() simplifies this:

const products = [
  { name: "Laptop", category: "Electronics", price: 1200 },
  { name: "Shirt", category: "Apparel", price: 50 },
  { name: "Keyboard", category: "Electronics", price: 75 },
  { name: "Jeans", category: "Apparel", price: 80 },
  { name: "Mouse", category: "Electronics", price: 25 },
];

const productsByCategoryNew = Object.groupBy(products, (product) => product.category);

console.log(productsByCategoryNew);
/*
Output (note: the prototype of the resulting object is null):
{
  Electronics: [
    { name: 'Laptop', category: 'Electronics', price: 1200 },
    { name: 'Keyboard', category: 'Electronics', price: 75 },
    { name: 'Mouse', category: 'Electronics', price: 25 }
  ],
  Apparel: [
    { name: 'Shirt', category: 'Apparel', price: 50 },
    { name: 'Jeans', category: 'Apparel', price: 80 }
  ]
}
*/

Much cleaner, right? The Object.groupBy() method returns a null-prototype object where keys are the group identifiers (in this case, "Electronics" and "Apparel") and values are arrays of the elements belonging to that group. [11]

When to Use Map.groupBy()?

The Map.groupBy() method is very similar but returns a Map instance instead of a plain object. [11] This can be advantageous when:

• You need to use non-string keys: Map keys can be any value (objects, functions, etc.), whereas plain object keys are always coerced to strings (or Symbols).

• You need to preserve insertion order (for keys): Maps remember the original insertion order of keys.

• You need built-in size property and other Map methods: Map objects have a handy .size property and methods like .has(), .get(), .set(), .delete(), etc.

Here's the same example using Map.groupBy():

const products = [
  { name: "Laptop", category: "Electronics", price: 1200 },
  { name: "Shirt", category: "Apparel", price: 50 },
  { name: "Keyboard", category: "Electronics", price: 75 },
  { name: "Jeans", category: "Apparel", price: 80 },
  { name: "Mouse", category: "Electronics", price: 25 },
];

const productsByCategoryMap = Map.groupBy(products, (product) => product.category);

console.log(productsByCategoryMap);
/*
Output:
Map(2) {
  'Electronics' => [
    { name: 'Laptop', category: 'Electronics', price: 1200 },
    { name: 'Keyboard', category: 'Electronics', price: 75 },
    { name: 'Mouse', category: 'Electronics', price: 25 }
  ],
  'Apparel' => [
    { name: 'Shirt', category: 'Apparel', price: 50 },
    { name: 'Jeans', category: 'Apparel', price: 80 }
  ]
}
*/

// You can then easily iterate or access elements:
console.log(productsByCategoryMap.get("Electronics"));

Why is this a "Very Useful Tweak"?

1. Readability: The intent of the code becomes much clearer. Object.groupBy(items, callback) immediately tells you what's happening.

2. Conciseness: It significantly reduces the amount of boilerplate code needed for a common operation.

3. Reduced Errors: Less manual logic means fewer opportunities for small mistakes in setting up the accumulator or managing arrays.

4. Standardization: It provides a standard, built-in way to perform grouping, leading to more consistent codebases. [8]

Browser Support and Transpilation

As Object.groupBy() and Map.groupBy() are part of ECMAScript 2024, modern browsers are quickly adopting them. [1, 8] For older environments, you'll likely need to rely on transpilers like Babel along with polyfills to use this feature. [5] However, as you build projects for 2025 and beyond, you can expect to use these natively more and more.

Conclusion

While seemingly small, Object.groupBy() and Map.groupBy() are excellent examples of how JavaScript continues to evolve to make developers' lives easier. [1, 8] They address a frequent need with an elegant and efficient solution, allowing you to write cleaner, more maintainable code. So, next time you need to group data, remember these handy additions!

Enter Array.prototype.with(index, value), a new method introduced in ECMAScript 2023 (ES14). It provides a clean, direct, and immutable way to get a new array with an element at a specific index replaced with a new value. [2, 6]

The Old Way vs. The New Way

Let's say you have an array of tasks, and you want to update the status of a specific task without mutating the original array.

Before Array.prototype.with():

const tasks = [
  { id: 1, text: "Learn JavaScript", status: "done" },
  { id: 2, text: "Write an article", status: "in-progress" },
  { id: 3, text: "Deploy to production", status: "todo" },
];

const taskIndexToUpdate = 1;
const newStatus = "done";

// Common approach using map:
const updatedTasksMap = tasks.map((task, index) => {
  if (index === taskIndexToUpdate) {
    return { ...task, status: newStatus };
  }
  return task;
});

console.log("Original tasks (map):", tasks);
console.log("Updated tasks (map):", updatedTasksMap);
/*
Original tasks (map): [
  { id: 1, text: 'Learn JavaScript', status: 'done' },
  { id: 2, text: 'Write an article', status: 'in-progress' },
  { id: 3, text: 'Deploy to production', status: 'todo' }
]
Updated tasks (map): [
  { id: 1, text: 'Learn JavaScript', status: 'done' },
  { id: 2, text: 'Write an article', status: 'done' }, // Updated
  { id: 3, text: 'Deploy to production', status: 'todo' }
]
*/

// Another approach using slice and spread (more verbose for single element):
const updatedTasksSlice = [
  ...tasks.slice(0, taskIndexToUpdate),
  { ...tasks[taskIndexToUpdate], status: newStatus },
  ...tasks.slice(taskIndexToUpdate + 1),
];
console.log("Updated tasks (slice):", updatedTasksSlice);

While these methods work and preserve immutability, they require a bit more boilerplate, especially the slice method for a single update. The map approach iterates over the entire array, which is fine for many cases but less direct if you know the index.

With Array.prototype.with():

Now, let's see how with() simplifies this:

const tasks = [
  { id: 1, text: "Learn JavaScript", status: "done" },
  { id: 2, text: "Write an article", status: "in-progress" },
  { id: 3, text: "Deploy to production", status: "todo" },
];

const taskIndexToUpdate = 1;
const newStatus = "done";

// Using .with()
const updatedTasksWith = tasks.with(taskIndexToUpdate, {
  ...tasks[taskIndexToUpdate], // Spread the existing task to only update status
  status: newStatus,
});

console.log("Original tasks (with):", tasks); // Unchanged!
console.log("Updated tasks (with):", updatedTasksWith);
/*
Original tasks (with): [
  { id: 1, text: 'Learn JavaScript', status: 'done' },
  { id: 2, text: 'Write an article', status: 'in-progress' },
  { id: 3, text: 'Deploy to production', status: 'todo' }
]
Updated tasks (with): [
  { id: 1, text: 'Learn JavaScript', status: 'done' },
  { id: 2, text: 'Write an article', status: 'done' }, // Updated
  { id: 3, text: 'Deploy to production', status: 'todo' }
]
*/

Notice how tasks.with(index, newValue) clearly expresses the intent: "give me a new array based on tasks, but with the element at index changed to newValue." The original tasks array remains untouched. [2, 6]

Why is Array.prototype.with() a "Very Useful Tweak"?

1. Guaranteed Immutability: Its primary purpose is to return a new array, reinforcing immutable patterns. This helps prevent bugs related to shared mutable state. [2]

2. Readability & Conciseness: The code arr.with(index, value) is very declarative and easy to understand at a glance compared to manual slicing or mapping for a single element replacement.

3. Reduced Cognitive Load: You don't have to mentally parse more complex constructions like slice/concat or a map function just to change one item.

4. Method Chaining: Like other modern array methods that return new arrays (e.g., map, filter), with() can be easily chained.

5. Consistency: It joins other new immutable array methods like toSorted(), toReversed(), and toSpliced(), providing a more consistent API for immutable operations. [6]

Important Considerations

• Shallow Copy for the New Value: If the newValue you provide to with() is an object or array, with() itself doesn't deep clone it. If you're updating an object within the array (like in our tasks example), you still need to ensure you're providing a new object for that element (e.g., using spread syntax { ...oldObject, propertyToChange: newValue }) if you want to avoid mutating the original nested object. The with() method handles the immutability of the array itself.

• Index Out of Bounds: If the index is out of bounds, with() will throw a RangeError, similar to how trying to assign to an out-of-bounds index with strict mode might behave, but more explicit. [2]

Browser Support and Polyfills

As an ES2023 feature, Array.prototype.with() is available in the latest versions of modern browsers and Node.js. [2, 6] For older environments, you'll need to use a transpiler like Babel along with a polyfill (e.g., from core-js) to use it. [5]

Conclusion

Array.prototype.with() is a welcome addition for JavaScript developers who value immutability and clean code. It simplifies a common array manipulation pattern, making your code more readable, less error-prone, and more aligned with functional programming principles. It's a small change that can make a big difference in the clarity and robustness of your array operations!

What is an AI Prompt?

An AI prompt is essentially an instruction or a query you provide to an AI model to elicit a specific response. Think of it as a carefully worded request that guides the AI towards generating the desired output. The quality of the AI's output is heavily dependent on the quality of the prompt. "Garbage in, garbage out" very much applies here.

Why are Good Prompts Crucial?

Well-crafted prompts lead to:

• More Accurate Results: The AI better understands your intent.

• Increased Efficiency: Less time spent re-prompting or correcting AI outputs.

• Relevant Outputs: Get code, explanations, or solutions that are directly applicable to your needs.

• Creative Solutions: Good prompts can help AI "think outside the box" in useful ways.

Best Practices for Crafting Effective AI Prompts

Here are some best practices to help you write prompts that get the AI working for you:

1. Be Specific and Clear:

   • Avoid ambiguity. Clearly state what you want.

   • Bad: "Write some JavaScript code."

   • Good: "Write a JavaScript function that takes an array of numbers and returns the sum of all even numbers in that array."

2. Provide Context:

   • The more relevant context the AI has, the better its response. This includes the programming language, frameworks, libraries, existing code snippets, or specific constraints.

   • Bad: "Fix this error."

   • Good: "I'm getting a 'TypeError: Cannot read property 'map' of undefined' in my Node.js Express route. Here's the relevant code snippet: [your code snippet]. What could be causing this?"

3. Define the Desired Output Format:

   • Specify if you want code, a list, a JSON object, a markdown table, an explanation, etc.

   • Example: "Generate a JSON object representing a user with 'id', 'username', and 'email' fields. The 'id' should be a UUID."

4. Use Role-Playing:

   • Instruct the AI to act as a specific persona. This can significantly shape the tone and style of the response.

   • Example: "You are an expert Node.js performance engineer. Explain three common performance bottlenecks in an Express.js application and suggest solutions for each."

5. Iterate and Refine:

   • Your first prompt might not be perfect. Don't be afraid to tweak it based on the AI's response. Experiment with different phrasings and levels of detail.

6. Specify Constraints and Requirements:

   • Include any limitations, such as "use only ES6 features," "do not use external libraries," "the function should be pure," or "ensure the solution is optimized for memory usage."

   • Example: "Write a Node.js function to read a large CSV file line by line without loading the entire file into memory. Do not use any external npm packages other than the built-in fs and readline modules."

7. Use Examples (Few-Shot Prompting):

   • Provide one or more examples of the input and desired output. This helps the AI understand the pattern you're looking for.

   • Example:

       Convert the following comments to JSDoc format:
     
       Comment:
       // takes two numbers and returns their sum
       // num1: the first number
       // num2: the second number
       JSDoc:
       /**
        * Takes two numbers and returns their sum.
        * @param {number} num1 - The first number.
        * @param {number} num2 - The second number.
        * @returns {number} The sum of num1 and num2.
        */
     
       Comment:
       // simple function to greet a user
       // name: the user's name, should be a string
       // returns a greeting string
       JSDoc:
       [AI completes this part]
     

8. Control for Tone and Style:

   • Specify the desired tone (e.g., "explain this simply," "provide a formal explanation," "write in a friendly tone").

   • Example: "Explain the Node.js event loop like I'm five years old."

9. Break Down Complex Tasks:

   • If you have a complex problem, break it down into smaller, manageable sub-tasks and prompt the AI for each part.

Useful AI Prompt Examples for JavaScript/Node.js Developers

Here are some practical examples you can adapt:

1. Code Generation

• Generating a Utility Function:

    Prompt:
    Write a JavaScript ES6 function called `debounce` that takes a function `func` and a `delay` in milliseconds.
    The `debounce` function should return a new function that, when called, will only execute `func` after `delay` milliseconds have passed without any new calls to the debounced function.
    Include JSDoc comments for the function and its parameters.
  

• Generating an Express.js Route:

    Prompt:
    Create a Node.js Express GET route for `/api/users/:id`.
    This route should:
    1. Extract the `id` parameter from the request.
    2. Assume there's an asynchronous function `findUserById(id)` that returns a Promise resolving to a user object or null if not found.
    3. If the user is found, respond with a 200 OK status and the user object as JSON.
    4. If the user is not found, respond with a 404 Not Found status and a JSON message: `{ error: "User not found" }`.
    5. If `findUserById` throws an error, respond with a 500 Internal Server Error status and a JSON message: `{ error: "Internal server error" }`.
    Use async/await.
  

2. Code Explanation/Documentation

• Explaining a Code Snippet:

    Prompt:
    Explain the following JavaScript code snippet, focusing on the use of closures and its practical implications:
  

    function createCounter() {
      let count = 0;
      return function() {
        count++;
        return count;
      };
    }
    const counter1 = createCounter();
    console.log(counter1()); // 1
    console.log(counter1()); // 2
  

• Generating JSDoc Comments:

    Prompt:
    Generate JSDoc comments for the following JavaScript function. Ensure all parameters and the return value are documented, including their types.
  

    async function fetchUserData(userId, apiToken) {
      if (!userId || !apiToken) {
        throw new Error('User ID and API token are required.');
      }
      try {
        const response = await fetch(`https://api.example.com/users/${userId}`, {
          headers: { 'Authorization': `Bearer ${apiToken}` }
        });
        if (!response.ok) {
          throw new Error(`API request failed with status ${response.status}`);
        }
        return await response.json();
      } catch (error) {
        console.error('Failed to fetch user data:', error);
        return null;
      }
    }
  

3. Debugging Assistance

• Identifying Potential Bugs:

    Prompt:
    I have this Node.js code that's supposed to update a document in MongoDB using Mongoose, but it's not working as expected. The `updatedAt` field isn't changing. What could be wrong?
  

    // Assuming 'Item' is a Mongoose model
    async function updateItemName(itemId, newName) {
      try {
        const item = await Item.findById(itemId);
        if (!item) {
          console.log('Item not found');
          return null;
        }
        item.name = newName;
        // Is something missing here for the 'updatedAt' field if it's not automatically handled by timestamps:true?
        await item.save();
        return item;
      } catch (error) {
        console.error('Error updating item:', error);
        return null;
      }
    }
  

4. Test Case Generation

• Generating Unit Tests (e.g., with Jest):

    Prompt:
    Write Jest unit tests for the following JavaScript function. Cover edge cases, including empty input, invalid input types, and a typical valid case.
  

    function calculateTotalPrice(items) {
      if (!Array.isArray(items)) {
        throw new TypeError('Input must be an array.');
      }
      return items.reduce((total, item) => {
        if (typeof item.price !== 'number' || typeof item.quantity !== 'number') {
          throw new TypeError('Each item must have a numeric price and quantity.');
        }
        return total + (item.price * item.quantity);
      }, 0);
    }
  

5. Code Refactoring/Optimization

• Refactoring for Readability or Performance:

    Prompt:
    Refactor the following JavaScript code to use modern ES6+ features (like async/await instead of .then().catch(), and arrow functions where appropriate). Also, suggest any potential performance improvements if applicable.
  

    function calculateTotalPrice(items) {
      if (!Array.isArray(items)) {
        throw new TypeError('Input must be an array.');
      }
      return items.reduce((total, item) => {
        if (typeof item.price !== 'number' || typeof item.quantity !== 'number') {
          throw new TypeError('Each item must have a numeric price and quantity.');
        }
        return total + (item.price * item.quantity);
      }, 0);
    }
  

6. Generating Boilerplate

• Creating a package.json:

    Prompt:
    Generate a basic `package.json` file for a new Node.js project named "my-api-service".
    It should include:
    - `express` as a dependency.
    - `nodemon` and `jest` as development dependencies.
    - A `start` script that runs `node server.js`.
    - A `dev` script that runs `nodemon server.js`.
    - A `test` script that runs `jest`.
    Set the main entry point to `server.js`.
  

• Creating a Dockerfile for a Node.js App:

    Prompt:
    Write a multi-stage Dockerfile for a production Node.js Express application.
    It should:
    1. Use an official Node.js Alpine image (e.g., node:18-alpine).
    2. Copy `package.json` and `package-lock.json` first and install dependencies to leverage Docker caching.
    3. Copy the rest of the application code.
    4. If there's a build step (e.g., `npm run build` for TypeScript), include it in a builder stage.
    5. The final image should only contain production dependencies and the built application code.
    6. Expose port 3000.
    7. Set the default command to start the application (e.g., `node dist/server.js` or `node server.js`).
  

7. API Design/Documentation

• Generating OpenAPI (Swagger) Snippets:

    Prompt:
    Generate an OpenAPI 3.0 specification snippet in YAML for a POST request to `/items`.
    The request body should be a JSON object with a required `name` (string) and an optional `description` (string).
    A successful response should be a 201 status code with the created item object in the response body, including an `id` (string, UUID format).
  

8. Learning and Exploration

• Understanding Concepts:

    Prompt:
    Explain the concept of streams in Node.js. What are their benefits, and provide a simple example of using a readable stream to process a file.
  

Tools and Platforms

You'll typically use these prompts with:

• AI Coding Assistants: GitHub Copilot, Tabnine, Amazon CodeWhisperer, etc. (often integrated into your IDE).

• Chat-based LLMs: ChatGPT, Gemini, Claude, etc. (via their web interfaces or APIs).

• LLM APIs: OpenAI API, Google AI (Gemini API), Anthropic API, etc., for programmatic access in your own tools or applications.

Conclusion

Mastering the art of AI prompting is like learning a new way to communicate with an incredibly powerful assistant. For JavaScript/Node.js developers, this skill can significantly accelerate development, improve code quality, and aid in understanding complex systems. By following these best practices and experimenting with different prompting techniques, you can effectively harness the power of AI to become a more productive and efficient developer. Start prompting, start iterating, and unlock new levels of coding prowess!

The Lingering Challenge of Graceful Exits

Traditionally, Node.js developers have relied on process.on('SIGINT', ...) and process.on('SIGTERM', ...) to catch termination signals. While functional, this approach has several drawbacks:

1. Manual Coordination: Developers are responsible for manually tracking open connections, ongoing asynchronous operations, and ensuring they complete before exiting. This can be complex and error-prone.

2. Boilerplate: Every application requiring graceful shutdown needs similar, often verbose, signal handling logic.

3. Inconsistent Library Support: Third-party libraries might not always offer straightforward ways to participate in a custom shutdown sequence.

4. Timeout Management: Implementing a reliable timeout for the shutdown process itself requires additional logic.

These challenges can lead to abrupt terminations, data corruption, or resource leaks, especially in complex microservices or stateful applications.

Introducing Enhanced Process Lifecycle Hooks in Node.js 25

Node.js 25 (specifically, starting from v25.1.0, released earlier this year) introduces a more robust and developer-friendly mechanism for managing the application lifecycle, particularly around shutdowns. This isn't a new module but rather an enhancement to the existing process object, making it intuitive and easy to adopt.

The core of this new feature revolves around two main additions:

1. process.addShutdownHandler(handlerFunction): Registers an asynchronous function to be executed when the application is requested to shut down.

2. process.registerCriticalTask(promise, description): Informs Node.js about a critical asynchronous task that must complete before the application fully exits.

Let's explore how these work.

process.addShutdownHandler(async (signal, exitCode) => { ... })

This new method allows you to register multiple asynchronous handlers that will be invoked when Node.js initiates a graceful shutdown. This can be triggered by:

• Receiving SIGINT (e.g., Ctrl+C) or SIGTERM signals.

• A call to process.exit() if no exit code is provided or if it's called in a way that implies a graceful attempt first (behavior under discussion for future refinements, but signals are the primary trigger for now).

Key characteristics:

• Asynchronous: Handlers can be async functions and return Promises. Node.js will wait for these promises to resolve (or reject).

• Concurrent Execution: Registered shutdown handlers are executed concurrently, allowing for faster cleanup if tasks are independent.

• Signal Information: The handler receives the signal (e.g., 'SIGINT') and the proposedExitCode that Node.js intends to use.

• Order: While execution is concurrent, registration order is maintained for invocation initiation, though completion depends on each handler's async nature.

process.registerCriticalTask(promise, description)

Often, your shutdown handlers might initiate cleanup tasks (like closing a database pool), but other parts of your application might also have ongoing work (e.g., finishing writing a large file, completing an outbound API call) that needs to finish.

process.registerCriticalTask(promise, description) allows any part of your application to signal that a specific asynchronous operation is critical and the shutdown should wait for it.

• promise: The Promise representing the critical operation. The shutdown process will wait for this promise to settle.

• description (optional): A string describing the task, useful for debugging and logging, especially if a task delays shutdown excessively.

Node.js will keep track of all registered critical tasks. During a graceful shutdown, after invoking shutdown handlers, it will wait for all these critical tasks to complete before finally exiting.

The Graceful Shutdown Process Flow

1. A shutdown signal (SIGINT, SIGTERM) is received.

2. Node.js emits a 'beforeShutdown' event on process (a new informational event).

3. All registered shutdown handlers via process.addShutdownHandler() are invoked concurrently.

4. Node.js waits for all shutdown handler promises to settle.

5. Node.js then waits for all promises registered via process.registerCriticalTask() to settle.

6. A configurable global shutdown timeout (e.g., process.SHUTDOWN_TIMEOUT_MS, defaulting to something like 30 seconds) applies to the entire process from step 3. If the timeout is exceeded, Node.js will force exit.

7. The application exits with the appropriate exit code.

Practical Implementation: Before and After

Let's illustrate with a common scenario: an HTTP server that needs to stop accepting new connections, finish processing existing requests, and close its database connection.

Before: Manual Signal Handling (Simplified)

// server.js (Old Way)
const http = require('http');
const { Pool } = require('pg'); // Example DB

const pool = new Pool({ connectionString: 'postgresql://user:pass@host:port/db' });
const server = http.createServer((req, res) => {
  // Simulate some work
  setTimeout(() => {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('Hello World\n');
  }, 100);
});

let isShuttingDown = false;

function gracefulShutdown(signal) {
  if (isShuttingDown) return;
  isShuttingDown = true;
  console.log(`\nReceived ${signal}. Shutting down gracefully...`);

  server.close(() => {
    console.log('HTTP server closed.');
    pool.end(() => {
      console.log('Database pool closed.');
      process.exit(0);
    });
  });

  // Force shutdown after a timeout
  setTimeout(() => {
    console.error('Could not close connections in time, forcing shutdown.');
    process.exit(1);
  }, 10000); // 10s timeout
}

process.on('SIGINT', () => gracefulShutdown('SIGINT'));
process.on('SIGTERM', () => gracefulShutdown('SIGTERM'));

server.listen(3000, () => {
  console.log('Server listening on port 3000');
});

This approach works but involves manual state (isShuttingDown), nested callbacks, and manual timeout management.

After: Using Enhanced Process Lifecycle Hooks (Node.js 25+)

// server.js (New Way with Node.js 25+)
const http = require('http');
const { Pool } = require('pg'); // Example DB

// Hypothetical: Configure global shutdown timeout (e.g., in an init file)
// process.SHUTDOWN_TIMEOUT_MS = 20000; // 20 seconds

const pool = new Pool({ connectionString: 'postgresql://user:pass@host:port/db' });
const server = http.createServer((req, res) => {
  // Simulate some work
  const workPromise = new Promise((resolve) =>
    setTimeout(() => {
      res.writeHead(200, { 'Content-Type': 'text/plain' });
      res.end('Hello World\n');
      resolve();
    }, 100)
  );
  // Register this request handling as a critical task
  process.registerCriticalTask(workPromise, `Request to ${req.url}`);
});

// Shutdown handler for the HTTP server
process.addShutdownHandler(async (signal, exitCode) => {
  console.log(`\nReceived ${signal} (exit code ${exitCode}). Closing HTTP server...`);
  await new Promise((resolve, reject) => {
    server.close((err) => {
      if (err) {
        console.error('Error closing HTTP server:', err);
        return reject(err);
      }
      console.log('HTTP server closed.');
      resolve();
    });
    // Optional: Stop accepting new connections immediately
    // server.closeIdleConnections(); // if available
  });
});

// Shutdown handler for the database pool
process.addShutdownHandler(async (signal) => {
  console.log(`(${signal}) Closing database pool...`);
  await pool.end();
  console.log('Database pool closed.');
});

// Example of a long-running task not directly tied to a handler
const someBackgroundTask = async () => {
  console.log('Background task started...');
  await new Promise(resolve => setTimeout(resolve, 2000)); // Simulate work
  console.log('Background task finished.');
};
// If this task needs to complete during shutdown, register it:
const backgroundTaskPromise = someBackgroundTask();
process.registerCriticalTask(backgroundTaskPromise, 'Critical background processing');


server.listen(3000, () => {
  console.log('Server listening on port 3000. Try Ctrl+C to test shutdown.');
});

// You can also listen to the informational event
process.on('beforeShutdown', () => {
  console.log('Node.js is preparing for a graceful shutdown.');
});

In the "After" example:

• No manual signal catching (process.on('SIGINT', ...)).

• Cleanup logic is encapsulated in async shutdown handlers.

• Individual request processing can be registered as critical tasks, ensuring they complete.

• Node.js core manages the overall shutdown timeout and orchestration.

Key Benefits

The introduction of these enhanced lifecycle hooks brings several advantages:

1. Standardization: Provides a unified, built-in mechanism for graceful shutdown across the Node.js ecosystem.

2. Simplicity & Readability: Reduces boilerplate code significantly, making application logic cleaner and easier to understand.

3. Improved Reliability: Offers better guarantees that critical operations complete before exit, reducing data loss or corruption risks.

4. Composability: Libraries can easily participate in the shutdown sequence by registering their own handlers or critical tasks without conflicting with application-level logic.

5. Centralized Timeout Management: Node.js handles the overall shutdown timeout, preventing indefinite hangs.

Considerations and Future Scope

• Handler Errors: If a shutdown handler rejects, Node.js will log the error but continue processing other handlers and critical tasks. The application will still attempt to shut down gracefully.

• process.exit(code) Behavior: The interaction of process.exit(code) with these new hooks is an area of ongoing discussion. The primary focus for now is signal-initiated shutdowns. Forcing an immediate exit will likely still bypass these hooks.

• Worker Threads: The integration with worker threads and how they participate in this lifecycle is an important consideration for future enhancements. Currently, these hooks are primarily for the main thread.

Getting Started

This feature is available in Node.js 25.1.0 and later versions (part of the "Current" release line as of May 2025). To use it, simply update your Node.js runtime and start leveraging process.addShutdownHandler() and process.registerCriticalTask() in your applications.

No special flags are needed; it's a core enhancement to the process global.

Conclusion

The enhanced process lifecycle hooks in Node.js 25 mark a significant step forward in building robust, production-grade applications. By standardizing and simplifying graceful shutdown, Node.js empowers developers to write more resilient services with less effort. This feature addresses a long-standing need in the community and is a testament to Node.js's continued evolution towards better developer experience and operational excellence.

As you migrate or build new applications on Node.js 25, incorporating these new hooks should be a priority for ensuring your services can handle termination signals gracefully and reliably. The future of Node.js application resilience looks brighter than ever.

Imagine you have an application and your users from different timezones and you need to send a message every day at 6:00 o'clock for each user to say Good Morning! ☕️, very simple right? let's see...

The First Try

The first and obvious solution is to run a cronjob 0 6 * * *

The code above will run every day at 6:00 and send a message to each user, which is what we need, right!? yes and no 😅

Yes, because only the users on the same server timezone will receive a message at the expected time.

No, because the users in the other timezone will receive a message at the wrong time.

How to fix this?

The idea popped into my mind after I saw this answer on StackOverflow, and because I'm using MongoDB in my project, I'll explain my approach to how I solved this issue.

The code above runs every half hour and queries all users who have time at 6:00 by using MongoDB date query.

Done 😉

btw, you should store the timezone of the user in the database.

sw_vers: Print macOS operating system version information, More information: https://ss64.com/osx/sw_vers.html.

uname: Print kernel name.

Combine them together and get this result sw_vers && uname -v on macOS/Linux or ver on Windows OS