We have various client side applications which needs various parameters to call services. this is mainly service URLS and all. Right now we are injecting java object as a server response from asp.net. or asp. So server code does a response.write of javascript object which has all the vlaues.
I am planning to move the configs to node so that Javascript apps can directly call node and get config values as json Object.
Once I get the values to client , I can cache them until someone changes on the backend again.
Do you guys think if this is good approach.
How can i refresh the cache if someone changes the config value on the backend.
Any kind of input will be appreciated.
Considering that the asp.net service can respond with a JSON object too then I guess the real question is, "Why are you changing the service architecture". If you have the man power to change to node.js so that the full stack is in Javascript, then that's fine, but otherwise it seems like a bit of a waste unless there's something that node.js does that you need that asp.net does not. As someone who works with both, they are both suitable as a web service passing JSON to and from the client.
If you want your client app to update when changes are made in the backend, then it sounds like you want some sort of 'push' ability of the web service so it can tell the clients that new information is available. It is possible to do this with websockets via both technologies (asp.net/wcf or node.js), but it is up to you how you do this.