Usage with fastify middleware
See original GitHub issueIs there a way to make sendResult
work with fastify middleware?
for example:
const app = fastify()
app.register(fastifyCors)
app.route({
method: ['GET', 'POST'],
url: '/graphql',
hanlder: async (req,res) => {
//...
const result = processRequest({...})
sendRequest(request, res.raw)
}
})
In the code above, I want fastifyCors to add access-control-allow-origin header to the response, but it won’t.
I’m not completely sure but is that because sendResult
is handling “RawResponse” rather than “Response” which is extended by fastify?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:6 (1 by maintainers)
Top Results From Across the Web
Middleware - Fastify
Fastify offers some alternatives to the most commonly used middleware, such as @fastify/helmet in case of helmet , @fastify/cors for cors , and...
Read more >fastify/middie: Middleware engine for Fastify. - GitHub
@fastify/middie is the plugin that adds middleware support on steroids to Fastify. The syntax style is the same as express/connect. Does not support...
Read more >Fastify middleware - access to query and params?
Fastify is asking developers to think more in terms of Hooks and less in terms of Middleware. This provides more flexibility and greater...
Read more >Middlewares - Fastify
Fastify out of the box provides an asynchronous middleware engine compatible with Express and Restify middlewares. If you need a visual feedback to...
Read more >How to Migrate Your App from Express to Fastify - SitePoint
The fastify-express plugin adds full Express compatibility to Fastify. It provides a use() method which we can use to add Express middleware ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Just to mention that we had a similar issue today, with
fastify-cors
. The headers set by this plugin was added to thefastify.reply
and not tofastify.reply.raw
, andsendNodeResult
was ignoring those.Doing that before calling
sendNodeResult
should work as a temporary workaround:I checked out how different plugins handle sending responses with
res.raw.write
:https://github.com/NodeFactoryIo/fastify-sse-v2/blob/b1686a979fbf655fb9936c0560294a0c094734d4/src/plugin.ts#L6-L21
The solution you proposed @dotansimha seems to be the correct one!
We should probably only give users the headers and the payload. The responsibility for glueing that to the framework of their choice should be more or less straightforward and can be guided with tutorials, recipes and example applications.
One of the main reasons why we added these helpers was boilerplate code we had to write over and over again for the multi-part protocol. Now we realize that we tried to own too much…
Instead of owning the whole pipeline we could only have helper functions for formatting the payload into the desired protocol and yield the string partials to the user:
Furthermore, I spotted that Fastify can handle stream payloads 🤔 https://github.com/fastify/fastify/blob/0439d5ffcab1709659353e8633a9a1ff36595c22/lib/reply.js#L426-L431
SO maybe the
result
returned fromprocessRequest
, could implement that interface (if it is a stream response and not only a single payload). Then for fastify we actually might not need to useres.raw
at all!From a user-land perspective the code would look like this:
There is still an open question for me: Should we even tell people what headers/protocols they should use? https://github.com/contra/graphql-helix/issues/161