Split tide into smaller crates #220
Conversation
There was a problem hiding this comment.
Thank you @wafflespeanut! This is good work.
I was previously waiting on some sign offs to get into the implementation details of this split. But now that we have, I think this is a good place for us to start asking the hard questions:
- What exactly goes into tide-core.
- What goes into tide.
- What goes into the crates.
Relevant comments for some goal insights:
The key with tide-core, is that we want to keep this as minimal as possible and only exposes what the developers of tide extensions need (though I think for the moment, to keep things simple we can only focus on middleware authors atleast for the first phase).
With that in mind, (being extremely ideal for the first pass):
MiddlewareandContextare things that absolutely have to go into the core.IntoResponse(or TryInto<Response> impls) is a bit tricky - Ideally this moves across tohttp-serviceitself since it provides no value to tide specifically andResponseis a type owned byhttp-servicewhich makes perfect sense since it's a http generic response and is best handled there itself so other crates which only want to usehttp-servicecan use them directly. So, what do we want to do about it during the split?Erroris the next bit. Here, (being idealistic again), I'd think this is candidate forhttp-serviceas well, since all it does is wrapResponse<Body>and provide a http generic error. It makes sense this goes where-everIntoResponsegoes.EndpointandEndpointResultare the next question. Do middleware/extensions need them in way or is it just end users?- Next comes the question of
Server,App- Is there any reason for them not to stay in justtide? - Stuff like
cookiesandformI think can go directly into their crates and be exposed from tide, or if there is no need for a crate - intotidedirectly.
@wafflespeanut - I know you were a bit keen to get this merged. But I think it's a good idea for this PR to be a bit more involved and answer atleast some of the above questions right. :) .. Would love to hear your thoughts from your experience on moving all these types around so far!
(Sorry if this suddenly ends up looking like a lot more than it seemed off the bat - we should be able to knock this off one by one quickly)
/cc @rustasync/maintainers
|
We should discuss this in the relevant RFC, as we've already arrived at a consensus for I agree that I also believe that chopping an epic issue into smaller tasks and landing small units of work is much more effective compared to blocking all tasks related to an RFC on one individual. If we land this now, then relatively smaller tasks like say, moving some type to One other (purely selfish) reason to land this is that restructuring PRs are fragile. It's already broken twice and it's analog work to go through the newly landed commits to ensure that a rebase was done properly. I'm pretty sure if we boot up another discussion now, then by the time we arrive at a consensus, it's gonna break a few more times again. In addition to being minimal,
|
|
@wafflespeanut - I'm in a bit of time crunch, but I'll address some of the non technical bits really quickly.
I get the feeling you may have misunderstood.
The ultimate goal here is to gather the reviews, and then make sure the PR is something that can be structured into the limitations of your interest and time, while not compromising on the quality -- if it isn't already. PS. Also, if you could, I think it'd be great for you bring this PR up, as the rustasync weekly meeting fortunately is in a couple of hours! (I'd guess it'll help speed this up). |
|
I'm sorry if I'm misunderstanding something. If there's a compelling reason to make any changes in this PR, I'd be happy to do that! Re-iterating my argument, this PR aims to address one thing without introducing any breaking changes and if we all agree on what it does and how we can work on the changes introduced by it incrementally, then we can move on to the next task, instead of waiting on the PR to address everything related to the split as it's inefficient IMO. In short, I'm only worried about making this PR address tasks that could otherwise be done incrementally (in subsequent PRs, which is also easier once we have the initial structure). Rebasing and keeping up with the changes isn't tricky (it's just boring analog work), I'm not worried about it and I'm definitely not suggesting that as a reason to merge this PR. :) |
|
Fixed and rebased! |
|
Looks good to me, thanks for your work! |
|
Thank you all for reviewing! |
|
I'm a bit busy this weekend, and I've not been able to make time to think through more clearly some of potential directions of what I expressed above just yet. If everyone else is cool with the PR, I'll jump back into the extraction bits post merge :) Only thing I'd like to strongly insist and make sure is that |
|
|
The following changes have been made (so far):
tideintotide-coreContextExtand middleware intotide-cookiesand feature-gated.Description
This is a follow-up to #219 and so it's based on top of the commits introduced in the other PR.
Motivation and Context
Based on the discussion from #162
How Has This Been Tested?
It's a refactor which only affects the existing structure. It doesn't break anything.
Types of changes
Checklist: