You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An upside to this is it lets you use pipe(), a downside is you don't know the capabilities of the receiving end (if it's HTTP/1.1, HTTP/2, etc). However, that responses use completely generic HTTP semantics instead of encoding-specific semantics could itself be seen as an upshot in some cases.
This is likely a poor way to do all Node.js HTTP responses, but it seems to me a framework should be able to do things this way.
I'm looking to discuss some of the limitations of Node.js that make this difficult, like in the http and stream modules. Is this a good topic for discussion?
The text was updated successfully, but these errors were encountered:
Would love yo have you on these conversations if you have input, and I think we are all looking at this same pattern as a good way forward. To consolidate the conversation, lets move this over to that issue to continue the conversation.
This is related to a comment I left on a gist that was posted somewhere here; I'm interested in the ability to return a ServerResponse object, instead of using a created one. I have a library, http-transform, that allows you to do this (more-or-less, see below).
An upside to this is it lets you use pipe(), a downside is you don't know the capabilities of the receiving end (if it's HTTP/1.1, HTTP/2, etc). However, that responses use completely generic HTTP semantics instead of encoding-specific semantics could itself be seen as an upshot in some cases.
This is likely a poor way to do all Node.js HTTP responses, but it seems to me a framework should be able to do things this way.
I'm looking to discuss some of the limitations of Node.js that make this difficult, like in the http and stream modules. Is this a good topic for discussion?
The text was updated successfully, but these errors were encountered: