Roadmap to v2

[emirror-de]

This has been created to discuss new features, API changes, fixes and ideas for axum-gate v2.0.0

The living document and checklist can be found in #12.

[emirror-de]

@dinosath
In reference to #12 (comment)

I think it would be helpful to have optional crate features that provide boilerplate controllers for frameworks like axum or actix. I can help with this if its accepted

This is an interesting idea. In the very early stages of this library, I was trying to generalize the Gate struct but it has grown too complicated to be maintainable. However I am happy to support more frameworks and on first glance this might be not too complex. Re-implementing the Gate struct and its variants for actix middleware should be the most work to be done for this. I will have a closer look later this week in order to check how this could be realized. I appreciate your help and if you are happy you are welcome to implement this as soon as we defined the requirements.

[emirror-de]

Hey @dinosath, sorry for not responding earlier.

I thought about how to make this happen, resulting in a new repository webgates. This is due to limitation of the current name which is bound to axum.

So what I did is splitting axum-gate into (currently) three separate crates to increase modularity and exensibility. I also moved the core Gate variant domain logic into the webgates crate, enabling the creation of multiple adapter crates to support more frameworks. See the webgates-axum crate for the axum implementation.

You are very welcome to start working on the webgates-actix integration, I think the adapter traits and API can be seen as mostly stable. There is still much work left to do in terms of documentation and various quality checks within this crate, so expect some quirks in developer experience.

Side-note: I will continue axum-gate and adapt it to make it use the webgates-axum crate under the hood, but main development will be in there in the future.