Tide is designed to be a highly modular, extensible framework, and #156 pushes us further in that direction.

There are a set of core concepts and interfaces:

• The core routing system (App and Route)
• The Endpoint interface, including Context
• The Middleware interface

Beyond that, we have a number of implementations and extensions:

• Various "extractors", which are now implemented as extension traits that work on Context. See forms for example.

• Middleware implementations, such as logging.

• Response builders, like this one.

Tide's current design allow for a strong decoupling between the core interfaces and these various extensions, much like Flask. This raises some questions about how to approach development, as well as the UX for Tide.

Proposal: follow the Flask model (for now)

Since Tide is explicitly intended to foster re-usable, modular components that can work with other frameworks, it makes a lot of sense to take full advantage of the decoupling above. That would follow in Flask's footsteps, where there's an extensive ecosystem of independent extensions to the tiny core framework.

I propose that we:

• Limit the tide crate itself to the core interfaces and APIs, and perhaps some extremely common extractors (the ones that are currently directly provided on Context, like body_json.

• Move all other extractors, middleware, and response builders into small, separate crates -- and generally encourage a spirit of experimentation with lots of small crates trying out competing approaches.

• Provide a unified "guide to Tide's ecosystem" as an entry point to all these extensions. This could be as simple as a list of links to crate docs.

Eventually, as we gain more experience, I imagine that some of these extensions will become de facto standard, and we might want to consider moving them into core. Likewise, I expect we'll want some "bundling" crates that set up a middleware stack for you, to make it very easy to get going with Tide. But these things can come later.

This approach would make it feasible to get the Tide core to 1.0 status relatively quickly, with the expectation that the APIs would remain stable for a while (let's say six months at least). Meanwhile, the various middlware crates etc can be versioned independently, freeing them to make breaking changes without any coordination.

Open questions

One open question: if we do take this direction, do we want separate repos or just separate crates? I worry a bit that if we get too aggressive about separating repos right now, it will be hard to follow what's happening. So I personally lean toward at least starting by having the other crates live within the tide repo, with a shared issue tracker, until we start hitting scaling problems.

wdyt?