Decoupling Cross-Cutting Concerns with FeathersJS Service Hooks

The Problem: Bloated Service Methods

When building a FeathersJS API, it is tempting to place all logic inside the service methods (like create or patch). However, as an application grows, you often find the same patterns repeating across every service: verifying a user's session, validating input schemas, hashing passwords, or logging request metadata. When this "cross-cutting" logic lives inside the service method, the actual business logic gets buried, and updating a validation rule requires changing code in multiple files.

Thesis: Hooks as a Middleware Pipeline

FeathersJS service hooks allow you to intercept method calls before they reach the service or after the service has finished. By treating these hooks as a composable pipeline, you can isolate infrastructure concerns (like authentication) from domain logic (like saving a record to a database). This keeps your services "lean" and ensures that security or logging policies are applied consistently across the entire application.

The Hook Context

Every hook receives a context object (often shortened to hook), which is the single source of truth for that request. Key properties include:

• hook.method: The name of the service method being called (e.g., 'create').
• hook.data: The payload sent by the client. This can be modified in before hooks to sanitize or transform data.
• hook.params: Metadata about the request, including the authenticated user object and query parameters.
• hook.result: The data returned by the service. This is only available in after hooks.

Worked Example: Input Validation and Sanitization

In this example, we assume a FeathersJS v4/v5 environment. We want to ensure that any data sent to a messages service is trimmed of whitespace and contains a required text field before it ever hits the database adapter.

// src/hooks/validate-message.js
module.exports = {
  async validateMessage(context) {
    const { data } = context;

    if (!data || !data.text) {
      // Throwing an error here short-circuits the request
      // The service method will not be executed
      throw new Error('Message text is required');
    }

    // Sanitize the input by trimming whitespace
    context.data.text = data.text.trim();

    return context;
  }
};

To apply this hook, register it within the service configuration. In a standard Feathers app, this is typically done in the service file:

// src/services/messages/messages.service.js
const { validateMessage } = require('../../hooks/validate-message');

module.exports = function (app) {
  app.use('/messages', new MessageService());

  app.service('messages').hooks({
    before: {
      create: [validateMessage],
      patch: [validateMessage]
    }
  });
};

Verification and Testing

To verify the hook is functioning correctly, you can perform the following checks using a REST client (like curl or Postman):

1. Test Validation: Send a POST request to /messages with an empty body. The response should be an error indicating "Message text is required", and no record should be created in the database.
2. Test Sanitization: Send a POST request with { "text": " Hello World " }. Retrieve the record via a GET request to confirm the stored value is "Hello World" (trimmed).
3. Test Bypass: Call a different method (like find). The hook should not execute, as it is only registered for create and patch.

Trade-offs: The "Hidden Logic" Trap

While hooks provide excellent separation of concerns, they introduce a layer of indirection. Because the logic is no longer inside the service method, a developer looking at messages.service.js might not immediately realize that data is being modified or validated before it arrives.

Limitations to consider:

• Execution Order: Hooks run in the order they are defined in the array. Placing an authorization hook after a heavy validation hook can lead to unnecessary processing for unauthorized users.
• Event Loop Blocking: Hooks are part of the request-response cycle. Performing heavy synchronous computation (like large file parsing) inside a hook will block the Node.js event loop, delaying all other concurrent requests.

Actionable Implementation Strategy

To integrate hooks into your workflow without creating a debugging nightmare, follow these guidelines:

1. One Concern Per Hook: Do not create a single validateAndLogAndAuth hook. Create three separate hooks and chain them in the service configuration.
2. Prefer Before Hooks for Security: Always place authentication and authorization hooks at the very beginning of the before array.
3. Use After Hooks for Side Effects: Use after hooks for non-critical tasks like sending a notification email or updating a search index, ensuring the primary database transaction has already succeeded.
4. Document the Pipeline: Since hooks are "invisible" to the service method, maintain a clear naming convention (e.g., validateUserSchema) so the pipeline is readable in the service configuration.