BFF v4: performance and session/token caching when using Server Side Sessions

[bamarch]

We're using Server Side Sessions in BFF v4

.AddEntityFrameworkServerSideSessions(options =>
{
    options.UseSqlServer(
        sqlServerOptions.ConnectionString,
        sqlOptions => sqlOptions.MigrationsAssembly(typeof(Program).Assembly.GetName().Name)
    );
})
.ConfigureEntityFrameworkSessionStoreOptions(options =>
{
    options.DefaultSchema = "BFF";
})

Reading https://docs.duendesoftware.com/bff/extensibility/tokens/ it seems that the access token is stored in the session

Since we are using Server Side Sessions, does that mean that every request requires at least one call to our Sql Server database?

Calls to that database are relatively expensive and our frontend app is chatty and makes lots of requests

Ideally we would configure session-caching (with tokens) in memory. Even adding a short cache period of 30s could greatly improve performance.

• Is there existing config that lets us configure session caching?
• If we disabled Server Side Sessions, would the tokens be stored client side in cookies... removing this issue?

Unforunately I think we could only user server side sessions if there is a caching feature, due to the performance impact, and we're keen to use (it is one of the features that we liked when choosing this product)

Thanks very much
Ben

[wcabus]

Unfortunately, there is currently no mechanism built-in to enable a caching layer on top of the existing EF Core backed UserSessionStore.
If you disable server-side sessions, then the cookies would indeed contain the access token again, but you would also lose the ability to revoke sessions when the user signs out (or is signed out) from the identity provider. Adding a caching layer would also increase the risk for a session to still be valid (in the cache) while it should've already been revoked.

You can however provide a custom implementation for the IUserSessionStore interface which adds a caching layer on top of a SQL-backed store.

[bamarch]

@wcabus if there is currently no mechanism built-in, is it likely there would be one in the future? 🙏🏻

we'll have to weigh up the pros/cons of disabling server-side sessions (whilst waiting for a built-in caching solution) vs writing our own custom implementation

[bamarch]

We decided that for now we don't need the server-side sessions enough to warrant the performance hit on every request, so we have disabled them

[jornhd]

I solved this problem by creating a decorating class, wrapping memory cache around the UserSessionStore calls.
I registered the decorator class using Scrutor.
This helped a lot with performace on page loads. Duende should consider adding short-lived caching on top of the db queries.