

I’m not informed on all the details, but a key difference between the async_trait macro and a native async keyword is that async_trait gives you that boxed, trait object type. IIUC the thinking is native support should not automatically box futures, which implies it shouldn’t use dyn either. Using Box and dyn is an easy way to make sure the code works no matter what type of future a method returns. But the trade-off is some runtime overhead from heap allocation (due to Box), and dynamic dispatch (due to dyn).
According to areweasyncyet.rs:
async fn in trait method not stabilized yet
- Workaround is available as an attribute macro: async-trait










When I’ve done this it’s generally done with JWTs where each micro service is configured with a trusted public key that is used to authenticate the JWT. The JWT can be sent to the client when they log in, and used to authenticate all API requests (forwarding the JWT as necessary for service-to-service requests). It’s also possible to have a gateway mint JWTs after using some other means to authenticate client requests.
Sometimes service-to-service requests don’t have a client request in context to pull a JWT from. In those cases you need another authentication mechanism, like a different signed token, or a shared secret.