Hoping to get some suggestions about the best way to approach this.
Some context:
- I have two applications: AppA and AppB. Both applications share the same model.
- AppA is the administration site for the shared model, while AppB is the client-facing application.
- AppA lives behind the firewall, while AppB is not, and is load balanced across a number of servers
- AppB will be used across multiple sub-domains, e.g., client1.AppB.com, client2.AppB.com
I want to create a settings management system within AppA (e.g., the internal admin site) for each of the clients that will be using AppB. Each client will have the same settings options, but of course different setting values depending on the desired configuration. Ultimately, depending on the configuration set in AppA, the settings in AppB need to be reflected correctly, based on the client accessing the site. So as an example, the “logo” setting for client1 needs to show up correctly when client1.appB.com is accessed, and so forth.
A few scenarios I’ve considered:
Per-Request:
I could obviously retrieve the settings on each request based on the environment/url. While this works, I’d like to avoid the overhead of querying/reading the settings on each and every request. This could be mitigated by caching, but that leads me to wonder how changes which occur in AppA could be effectively communicated to AppB in order to refresh the cache. Unfortunately, we do not have a good (read “any”) way of directly sending requests to the actual servers, so must leverage the load balancer to distribute the requests. We could do something like the “deploy.tag” method that we use for deployment, but I’ve had squirly behavior with that and would like to avoid it if possible.
Add to Config Settings
For other sites, I use the config settings and find this pretty effective. So for the above scenario, I’ve thought about creating a structure in config settings that could track per-client settings. I think this would also work well enough, but it still runs into the question of how changes to managed settings in AppA can get communicated to AppB in order to update the config settings…without the brute force of simply restarting the application (which is what we do now when changes in ColdBox.cfc are made).
I appreciate any thoughts or suggestions that anyone can contribute–thanks!
The following blog entries should get you started on how to do it simply connecting to the Couchbase cluster via our open source CacheBox provider. Minimally, you would want to talk your IT guys into spinning up 3 VMs (Windows, or Linux) with a minimum of 4GB ram and 4 Cores. Then, just make sure the battery of required network ports are open, and your application is ready to connect.