Backend struct structure?

[HosMercury]

what should I add ( more ) in that struct
I see it is needed for the macros!

suppose I have posts routes/types
should I add posts to Backend?

I see adding this struct makes it overwhelming somewhat
BUT I don't know what is the alternative

[maxcountryman]

Can you go into a little more detail here and maybe provide an example? For instance, are you referring to the overall structure of our backend code or do you mean the user backend that this crate uses?

[HosMercury]

pub struct Backend {
    db: SqlitePool,
}

I am asking about that one

what is the actual role of it ?

[HosMercury]

also suppose i added another feature like (( posts )) ((products )) .. etc
is it required to add them somewhere to work with the macros!?

[maxcountryman]

I'm going to assume that's the Backend we define e.g. in users.rs from the SQLite example. If I'm right, then that is the definition of the user backend. In the SQLite example we use a struct to encapsulate the necessary things to authenticate and get a user from our user backend store (in this case, that's SQLite and in particular we need some way to talk to SQLite which is the pool, but it could be anything we like provided it can implement the AuthnBackend trait).

[HosMercury]

Other examples have other fields inside the Backend struct

[maxcountryman]

Because backends are arbitrary, there's no requirement regarding what the struct contains (or if it's a struct at all).

The only requirement is that AuthnBackend be implemented.

In practice that means we need to be able to satisfy its two methods: authenticate and get_user. So if our users authenticate with OAuth for example, we'll need some kind of compatible client and likewise if we wish to store users in our own database then some way to communicate with the database.

That said, it's up to the implementor to decide what's needed for their specific case.

We've designed things around a trait like this because it allows for virtually any kind of user backend storage, ranging from authentication services to OAuth to LDAP to a database. The only thing that must be true is some arbitrary type implements AuthnBackend.