This is different in behavior to being a wrapper around the whole router because there are several methods that allow you to route
_without_pipelines
That all makes some sense to me. If it were my design, I'd wrap things in pipelines explicitly, and there'd be an easier way to wrap the top level router. I'm not sure I can make a stronger argument for that than "aesthetics."
BorrowBags exist to make a collection of disparate things share a (longer) lifetime, right?
Where it gets weird is that a PLHC is a collection of Pipelines, which are themselves collections of Middleware,
(well... there's some
construct going on in there, and Pilelines -> PipelineInstances and NewMiddlewareChain -> MiddlewareChain but that confuses the issue)
When a pipeline gets
called during a request, we instantiate what amounts to a list of lists, and then do a depth first walk with the (state, request) pair, and then walk back with the result.
I mean really, it's all function composition, not list walking, and the weirdest part (which I'm still trying to get my head around) is how
PipelineHandleChains compose with MiddlewareChains since both convert a cadr-style list into function composition, with (state,request) running down the side.
Finally, I don't understand why it has to be, but the MiddlewareChain itself is declared
unsafe
So my primary research question now is: could the PLHC refer directly to Middleware - or some new middleware-type that's available to be implemented directly, but there's an adapter for old style Middleware
So I think it should be refactorable.
Unless anyone understands different?
So you're basically asking for a web server that replies to POST requests? You can definitely do that with gotham
Might be a call for a new trait like AsyncHandler or something that has a blanket Handler implementation
iirc async-trait is just a convenience macro, so using it or not should be independent from gotham?
should work fine
Or is
async just Pin<Future<T>>?
no that's just a limitation of traits where you cannot return
impl Future
afaik
async fn foo() -> Result translates to fn foo() -> impl Future<Output = Result> with no boxing involved, and the concrete type being inferred by the compiler (and which is also some autogenerated private type)
So my scenario is this:
Client --{POST}--> GothamServer --{GET}--> some other server with the information I need to answer the client
yes that's certainly possible. gotham would be the part that communicates with the client, and then you'd use a client library like reqwest or surf to make your get request inside the handler
@mzr: Probably not out of the box. I'd suggest looking at
bind_server (source) to see (a) if it would be enough, (b) how it's dont internally.
Hi,
Their is something I don't understand in
the-benchmarker/web-frameworks#3690
Their is something I don't understand in
Cargo.lock, should not in fix / expose feature from hyper ? I have no rust skill but hyper is in 0.14 so we need to fix version in Cargo.tomlthe-benchmarker/web-frameworks#3690
@waghanza: gotham re-exports the hyper crate, so I strongly advise you use
gotham::hyper and don't depend on your own version of hyper
@jugglerchris: I don't think the diesel middleware currently supports this, so for now your best bet is probably to create a temporary file and use that as the database. Feel free to open an issue/PR to improve this
Next question... what do people use for the session middleware backend? I guess it's probably not much effort wrapping a
gotham_middleware_diesel table, but I guess I'd expect someone to have done so already. :-) (In the absence of a pre-existing one the MemoryBackendwill realistically be fine for my one-off application for a child's distributed birthday party)
it looks like travis currently refuses to run on our repository - does anyone know why that is?