onResponse res instead of res.stream

[Swizz]

onResponse res instead of res.stream

[Uzlopak]

I assume that res.stream is used for higher throughput. Maybe we should implement an option to select if res or stream is passed through.
This would empower others to get what they need.

[mcollina]

Given that we had a regression for 204 recently, could you include a reproduction for the 204 problem you are mentioning?

I'm not sure I understand your use case. I think your code would be easier to read and maintain if you just used undici.request directly to orchestrate your APIs?

[Swizz]

Hi, thanks for your inquiry.

Here is a repo that try to reproduce our use case : Swizz/reply-from-dummy
Because of a legacy codebase, we are still using node 14 and fastify v2 in production.

By running npm run start, you will be provided a swagger interface at /docs.
All routes are described in the readme, and more comments in the code will enlight you about what we are trying to achieve. The special routes /post/100 will mimic the 204 behavior.

We tried to use undici, but you did a great job on reply-from to relay directly headers such as authentication or request status for errored routes that saved us for a lot of headaches.

But we would totally understand if your are against such changes because opening to more features could add you maintenance on subjects your package was not intented for.

[mcollina]

I'm extremely surprised that the latest version of this module works with such an old version of Fastify.

Composing multiple endpoint into out is somewhat out of the one of @fastify/reply-from. I'd recommend to use undici directly and forward the headers.

If you are using OpenAPI, you can check out the automated client we created in Platformatic. It has facilities to forward headers etc.

https://docs.platformatic.dev/docs/reference/client/introduction/#openapi

If you need professional help with the migration or anything similar, feel free to ping me via email, happy to have a chat.