Switching dashboard JobStorage at runtime to support viewing different environments from a single client application

We’d like to be able to dynamically switch a JobStorage (SqlServerStorage) in the dashboard at runtime. The idea is to use the same client app (dashboard) to view multiple environments (DEV, QA, PROD) instead of installing a version of the dashboard per environment.

I came across issue #168 that allowed passing a JobStorage instance instead of using JobStorage.Current. The problem I am facing is that JobStorage instance is being passed to the middleware during application startup only, and there seems to be no way to “inject” another instance once middleware had been configured. So the same instance is effectively being used on the dashboard for entire application lifecycle.

My goal would be to build another screen in the client app that is hosting the dashboard, where I can pick an environment (dev, qa, prod). Each environment would have a corresponding connection string that I would use to create a JobStorage. Ideally, once I pick the environment, I would then inject a new JobStorage that can be used by the dashboard, thus allowing the user to switch between environments. I’ve tried forcing a new JobStorage with GlobalConfiguration.Configuration.UseSqlServerStorage(connectionString); which internally sets JobStorage.Current with new instance but for obvious reasons this did not work, since the middleware had already been configured to use another instance that was passed during initialization.

One way I could see it working is to update the middleware to accept some sort of JobStorageFactory in Hangfire/src/Hangfire.Core/Dashboard/Owin/MiddlewareExtensions.cs to get “current” JobStorage that will be passed to OwinDashboardContext but then why not pass JobStorage.Current instead.

Is there a preferred way to achieve what we need?

I think the easiest way is to implement your own “proxy” JobStorage which will detect the correct environment at runtime and forward calls to the underlying JobStorages.

Or you may register different areas for environments, each having its own instance of Dashboard middleware and own JobStorage.

I like the idea of a “proxy” JobStorage. Thanks for a great suggestion!