H3 integration

[pi0]

Hi, following up from h3js/h3#1113 ❤ I had a quick look over current plugin and have some suggestions to improve.

You can use single app.use for more performance. While onRequest/onResponse/onError are more convenient, you can merge them into a single middleware:

app.use(async (event, next) => {
  // [onRequest]
  try {
    const body = await next();
    // [onResponse]
    return body
  } catch (error) {
    // [onError]
    throw error
  }
})

Apitally only works with H3 v2 and currently doesn’t support nested apps due to limitations in H3.

This section from the docs, I think, should be fixed when you are migrating from global hooks to middleware. (they always run in the order of registration, and usually the main app should register the plugin anyway to catch everything same as Hono suggestion: "Add the Apitally middleware before any other middleware to ensure it wraps the entire stack.")

const requestBody = Buffer.from(await clonedRequest.arrayBuffer())

Is this line really necessary? Buffer.from is a Node.js specific API and can make platform support limit.

Also, request cloning and always reading body, imposes big performance penalty.

I would suggest if really necessary, expose it as something like event.context._readApitallyRequestBody = () => {...} (or better, expose another composable util instead of injection to the context)

---

(feel free to reach me out in discord if easier @pi0 or discord.h3.dev)

[itssimon]

Thanks so much for your suggestions! I'll work through them and will get in touch on Discord if I have any questions.

For nested app support I've also created these two issues:

• Improve matchedRoute for nested apps h3js/h3#1110
• List all routes, including those in nested apps h3js/h3#1111

[itssimon]

You can use single app.use for more performance. While onRequest/onResponse/onError are more convenient, you can merge them into a single middleware:

I'm not sure that this would work. With the single middleware approach I would only get the rawBody from the next() call, but not a Response object, which is constructed internally via the non-exported function prepareResponse() and passed into the onResponse hook.

Ideally we'd be able to intercept the final response just before it's sent (with headers and status code) and as far as I can tell, using onResponse is the best mechanism for that currently?

Is this line really necessary? Buffer.from is a Node.js specific API and can make platform support limit.

Even though Buffer is Node specific, it is also implemented in Bun and Deno. It's used elsewhere in this library too, so making it more standard-compliant would mean more widespread changes. Since it hasn't yet come up as a limitation for users, I might hold off on that until it does.

Also, request cloning and always reading body, imposes big performance penalty.

Request cloning was the only mechanism I could find in H3 to be able to read the request body in middleware without making it unavailable to the route handler, as it can only be read once. In Hono the HonoRequest class caches the request body, so it can be read again after the route handler has finished. I suppose that has different trade-offs, but avoids the duplication. Might be worth considering for H3?

Anyway, request body logging is disabled by default in the Apitally plugin. So the performance impact would only be felt by users who explicitly enable it.