Disable Cache about express-stormpath HOT 5 CLOSED

Hey @Solido, that's a good question.

Right now our underlying Node SDK requires some form of cache, which is an in-memory cache by default. This is done this way as our implementation puts all requests through a cache manager.

What you can do to 'workaround' this for now, is do something like this:

app.use(stormpath.init(app, {
  cacheTTL: 1,
  cacheTTI: 1,
}));

This will use the default in-memory cache, but will set the expirey times to 1 second (so it will expire quickly).

Hope that helps.

from express-stormpath.

@rdegges the Java SDK provides a DisabledCacheManager implementation that always returns null for cache lookups. This is an implementation of the Null Object design pattern: the CacheManager does not need to be null (checks for null on the CM do not need to be made, reducing cyclomatic complexity), but it is effectively disabled. The Node and Python SDKs should have the same concept to allow users to disable the cache entirely.

I guess you can move this issue to the SDK project instead of the Express one?

from express-stormpath.

Based on previous indications, my deduction was that I can use customData as a cold data storage like configuration but not as a live storage.

If I modified data from my web UI and/or from StormPath admin or others webservice connected to stormpath I loose the integrity of data. I understand this is out of scope of current implementation but I was expecting this from Stormpath to save me lot of lines of code.

To be even more clear about the point I only care about Custom Data, only them should be live.

Hope this explanation help to built an even more complete product !

from express-stormpath.

@lhazlewood indeed. I was actually going to talk with @robertjd about this when we're in office together on this =) But yes, we'll get this into the Node SDK so it gets bubbled up to this library.

@Solido this is a really great use case, btw. We should definitely support this (and will!).

In general, our approach with caching is to try to avoid as many API requests to our service as possible (this way, your app is faster and doesn't need to make as many HTTP calls).

By default, our libraries cache stuff for 5 minutes, which means if you get burst traffic / etc., your app will respond with whatever account / customData / whatever stuff was requested very quickly, despite ISP issues / etc.

Anyhow: thanks for the issue / feedback. This stuff is really useful to us here and helps make our software better =)

from express-stormpath.

Caching can be disabled through the Node SDK. We now pass config options through this library down to the Node SDK.

from express-stormpath.