lol just looked up tide and of course @yoshuawuyts is involved. i swear they're like 5 miles ahead of where ever i am
-
-
Replying to @whale_eat_squid @isntitvacant
Haha, hi! :D Also in case you missed it: a big Tide rewrite was PRd last Thursday https://github.com/rustasync/tide/pull/156 …. It'll hopefully smooth out some of the bumps Tide has, making it a lot easier to use. If you have any thoughts on it, we'd love to hear them!
1 reply 0 retweets 1 like -
Replying to @yoshuawuyts @whale_eat_squid
oh i was thinking in particular of this PR. such great work, & so well explained!

1 reply 0 retweets 1 like -
Replying to @isntitvacant @whale_eat_squid
Yay, glad to hear you're into the new design! I'll pass the feedback along to the rest of the team ^^
1 reply 0 retweets 1 like -
Replying to @yoshuawuyts @whale_eat_squid
Something I noticed while working on spife that _might_ be useful for tide: defining body processing as a middleware lifecycle (That way you could define separate middleware for handling JSON / multipart / body length & mix and match at the app level)
1 reply 0 retweets 1 like -
Replying to @isntitvacant @whale_eat_squid
Ohh, interesting! What kind of middleware are you referring to? The concept of extractors still lives on inside the Context argument. E.g. ctx.body_json() can convert the incoming body stream to a typed struct. And it can be extended with custom impls! Or is that different?
1 reply 0 retweets 0 likes -
Replying to @yoshuawuyts @whale_eat_squid
Hm, it's tricky (I'm still new to Rust so it might not translate!) In spife there's a middleware list; each mw can provide "lifecycle" functions – for "startup", "incoming request", and "handler accessed request body data". That last one is on `request.body` access.
1 reply 0 retweets 1 like -
The goal was to decouple "My application wants structured data" from "The framework knows how to decode the underlying request format" – the handler doesn't know if it's talking JSON, multipart, tarball, etc & doesn't care. Middleware can handle that (& fail with a 400 if not)
1 reply 0 retweets 1 like -
The nice thing about this was that you could separate concerns, e.g.: - mw #1 only enforces body length limits - mw #2 only handles json requests iff content-type was json - mw #3 only handles multipart, etc apps could mix and match based on requirements.
1 reply 0 retweets 1 like -
In (my rusty) rust, `ctx.body()` could return, say, a `Result<T, StatusCode>`, & each body middleware would have a chance to process the incoming stream of body bytes and/or cast it into T or forward onto the next body mw.
1 reply 0 retweets 1 like
Thanks so much for taking your explain this! If I'm understanding this correctly, then we're not far off from being able to provide all these things in a reusable manner in Tide. I guess in our case its split between Middleware and Context, but I think it translates!
-
-
(I'm also still getting used to the new Tide API, but afaik the only differences would be in *how* we achieve these abstractions in Tide. Because we very much are able to make all of what you mentioned reusable / pluggable :D)
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.