5 ms·
I have one question regarding how the Router works. I worked with the new Node.js framework called Koa.js. It has an interesting way of dealing with middleware
by sntran 12y ago
I have one question regarding how the Router works.
I worked with the new Node.js framework called Koa.js. It has an interesting way of dealing with middlewares (would be Plug in Elixir world, I assume). Request and response are passed through the middleware chain downstream, and each of them can take the response from previous middleware(s), modify it if needed, and pass to the next.
Either the response reaches the last middleware, or one of middlewares returns immediately, the response goes back "upstream" through the middlewares again. Then it is replied to the client.
During the flow, each middleware can also yield to the next one, so that it can handle the updated response when it goes upstream.
Imagine the cache middleware. Request comes in, this middleware checks if there is a cache of that request. If not, it yields to the next middlewares that will retrieve and transform the data, then cache the response body before returning to client.
For me, this flow offers a lot of flexibility in request and response handling. Is there anything similar to Phoenix?
From what I understand, once a Plug chooses to reply, the response ends at that Plug.
- chrismccord 12y agoYes, this is similar to Plug, but we only have a "connection". There is no distinction b/w request/response. A series of Plugs form a transformation layer on the connection where plug middleware can transform the connection, send a response etc. "Yielding to the next plug" is just a matter of returning the connection. There is no explicit yield. You either halt the connection (don't invoke further plugs) or continue the stack by returning the conn unhalted. Where your "upstream" concept fits is a connection can have callbacks bound that are invoked just before the response is sent, this is where a cache plug would cache the response. Plug avoids the issue of separating request/response because for things like streaming, sending a response does not mean that the stack is done with the request. Rack has this issue with streaming and José put a great deal of thought into Plug around the lessoned learned from Rack style APIs. You can read about his thoughts here: http://blog.plataformatec.com.br/2012/06/why-your-web-framework-should-not-adopt-rack-api/ http://blog.plataformatec.com.br/2012/06/why-your-web-framew... > From what I understand, once a Plug chooses to reply, the response ends at that Plug. In Phoenix, we halt the connection when you use most of our functions that send a response, because there is little you can do afterwards. The Plug response API itself never halts when a response is sent.
- sntran 12y agoThank for explaining. Is there a document of all available connection's life cycle hooks somewhere I can lookup? And can different Plugs attach different callback to same hook?
- chrismccord 12y agoRight now, the Plug repo and docs is the best resource. Yep, different plugs can attach any number of `register_before_send` callbacks on the connection.