Measuring FeathersJS Hook Latency Before Placement Decision

Direct answer

To measure a hook’s latency, wrap its body with a high‑resolution timer (e.g., process.hrtime.bigint()) and store the elapsed time in context.meta; alternatively, run the service with the hook enabled and disabled under identical load and compare p50/p95 response times. For a hook that logs and updates a cache, place the cache update in the after phase of create when you need the final record; if the cache write must be awaited before sending the response, this adds latency, otherwise you can fire‑and‑forget it. Splitting the logic into two hooks (logger and cache updater) is safer and lets you order them independently.

Measurement steps (confirmed)

1. Create a wrapper function that records process.hrtime.bigint() before and after the hook call.
2. Compute elapsed milliseconds and assign to context.meta.hookLatency.
3. Register the wrapper as the first and last hook in the phase you want to measure, or use a dedicated timing hook that only writes to context.meta.
4. If you prefer not to instrument each request, run a load test (e.g., autocannon) with the hook enabled and then disabled; the difference in p50/p95 latency approximates the hook’s cost.

Placement facts and trade‑offs

• The before phase runs before the database write, so context.result is not yet available.
• The after phase runs after the write, providing context.result (including generated IDs).
• FeathersJS documentation does not prescribe a default placement; common practice puts cache updates in after to use the final record.
• If the cache write must be awaited before the response, placing it in after adds network latency; you can make it fire‑and‑forget with error handling to avoid blocking the response.
• Placing the cache write in before risks writing a cache entry that may become stale if the database write fails.

Splitting logic – likely explanation

Separating concerns into two hooks improves clarity and safety:

• Logger hook – lightweight, can be placed early in before (or early in after) to record request metadata; it can be fire‑and‑forget if logging is non‑critical.
• Cache updater hook – placed in after where context.result is available; await it only if strong consistency is required, otherwise fire‑and‑forget with error handling.

Example registration:

app.service('items').hooks({
  before: { create: [logHook] },
  after:  { create: [cacheHook] }
});

To finalize the recommendation, please confirm whether the cache update must be awaited before the response is sent (i.e., strong consistency) or can be performed asynchronously.