This project looks like a very nice lightweight way to implement policy in a Rust application; I really like the ergonomics of the builder. Despite being very different systems, the core permissions check being the same signature as a call to SpiceDB[0] (e.g. the subject, action, resource, and context) shows the beauty of the authorization problem-domain regardless of the implementation.<p>I would like to add some color that a policy engine is not all you need to implement authorization for your applications. Without data, there's nothing for a policy engine to execute a policy against and not all data is going to be conveniently in the request context to pass along. I'd like to see more policy engines take stances on how their users should get that data to their applications to improve the DX. Without doing so, you get the OPA[1] ecosystem where there are bunch of implementations filling the gap as an afterthought, which is great, but doesn't give a first-class experience.<p>[0] <a href="https://spicedb.io" rel="nofollow">https://spicedb.io</a><p>[1] <a href="https://openpolicyagent.org" rel="nofollow">https://openpolicyagent.org</a>
Is it standard to have 2k+ loc in a lib.rs file? I'm looking at Rust code and it seems that everything goes in there. People usually don't break that down?
command-f "license" :-(<p>I do see <<a href="https://github.com/thepartly/gatehouse/blob/v0.1.2/Cargo.toml#L5" rel="nofollow">https://github.com/thepartly/gatehouse/blob/v0.1.2/Cargo.tom...</a>> but my experience with package manager license declaration is that it is almost always "yeah, yeah, default, whatever" versus an explicit choice. They are also invisible to the GitHub license widget, which places the burden upon the user to go spelunking around in the code to know for sure
What is the advantage of having the policy checking be an async function? From a brief look (framework itself and one of the examples provided in the examples directory) it seems that you’d typically be doing all I/O operations up front before invoking the policy checker, and that doing the policy check does not itself involve any I/O.<p>I only looked over the code quickly so I’m probably overlooking something.<p>It would be neat to get the motivation for each of the functions that are async being async instead of just “normal” functions.
Very cool project. I’ve used the cedar crate for similar use cases in the past but it’s always bugged me that it requires writing the policies in yet another language.<p>Will definitely check this out.