Comments (11)
I think you should have a ret
channel on the request, not the httpResponse
. On that ret
channel, graft-http will expect what you identified as "response" in your example, and body can be:
- a string
- a buffer
- (default) a stream, in that case it's piped to the
httpResponse
Does it make any sense?
from graft-http.
I think we should have the HTTP body parsed for JSON, ecc.. otherwise doing crazy things will be hardish. However we should be able to disable that by turning a flag, or something similar.
from graft-http.
Makes sense!
We can take a look at the content-type of the request and parse the body appropriately. The bridge function can accept a hash of options to disable this, which would just pass the request stream through.
from graft-http.
I'm also assuming that since graft-http will send the message right when the request comes in, the body will still be a stream, even if it is getting parsed as json, form data, etc. You would have to listen for data
or end
to get the data from the request. Maybe there is an option to wait for the request to be finished before sending the message.
from graft-http.
@tamagokun I'm not sure on that. Otherwise a validation step might be tricky, and that's going to be parsed anyway for doing anything serious.
from graft-http.
Or if we want the body parsed, it will wait until the request is finished before sending the message?
// parse: true
// graft sends message once request stream emits end. contents of body is string or object
graftHttp.use(service(), {parse: true});
from graft-http.
I definitely think so.
from graft-http.
how much of this is going to be re-inventing connect/express though ?
perhaps we should focus on adapting connect middleware to be used?
from graft-http.
Exactly. middleware micro-service. Something that could wrap up a connect middleware into a micro service that is consumable by graft. It would be great to create something that could achieve full interoperability with any http based middleware, but I haven't done any tests yet.
All of the routing and parsing we are discussing could be handled by piping the request through to other graft-compatible middleware rather than using options.
from graft-http.
Converting requests to/from messages: https://github.com/GraftJS/graft-http/blob/draft/lib/request.js
As I mentioned in #1, I need a better way to handle serializing the http request. Middleware and other things love to tack on properties to that and share them with other middleware, so I was imagining a black list of properties that we would throw away, and just keep the rest (plus a few convenience ones that aren't normally a part of http.IncomingMessage)
from graft-http.
This should be all set now. If message keys need to change at all, open a new issue.
from graft-http.
Related Issues (5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graft-http.