Server-side HTML rendering:
- Fastest browser rendering
- Page caching is possible as a quick-and-dirty performance boost
- For "standard" apps, many UI features are pre-built
- Sometimes considered more stable because components are usually subject to compile-time validation
- Leans on backend expertise
- Sometimes faster to develop*
*When UI requirements fit the framework well.
Client-side HTML rendering:
- Lower bandwidth usage
- Slower initial page render. May not even be noticeable in modern desktop browsers. If you need to support IE6-7, or many mobile browsers (mobile webkit is not bad) you may encounter bottlenecks.
- Building API-first means the client can just as easily be an proprietary app, thin client, another web service, etc.
- Leans on JS expertise
- Sometimes faster to develop**
**When the UI is largely custom, with more interesting interactions. Also, I find coding in the browser with interpreted code noticeably speedier than waiting for compiles and server restarts.
You might also consider a hybrid model with a light backend implementation using a front-end/back-end templating system like mustache.
About Offloading processing to client side:
Can the client machines handle the business logic processing smoothly? Does other applications (outlook, VS, eclipse, etc) suffer because of the heavy silverlight application?
If the client machines have trouble running the silverlight application, then you need to take some processing to server side, maybe do some conversions from the raw data and send more streamlined data (e.g. JSON/XML) to the clients.
If the silverlight application works fine without impeding your users' work, then it's perfectly OK to offload the business logic to clients since you are saving server side resources.
To answer your questions:
Is it going to be faster?
It will be faster on client side but slower on server side. You might need to upgrade the VMs.
Do I need to scale immediately?
Your server will be processing more data than it used to, so you might have to scale if you see its getting slower.
Is Fetching the data only once on the server then caching it something
like redis than doing the computations according to user requests
better solution?
If different user requests fetch the exact same data into the server multiple times, and if fetching is a slow operation, then it is a very good idea to cache it. Based on the amount of data you might use storage systems like Redis.
If clientside approach is good, do I need to switch to Javascript and
Javascript client side MVC frameworks like AngularJS?
If you have a standardized set of client machines, then Silverlight is good. You might have to think about javascript based clients if you have Linux, Mac, or Windows systems without Silverlight. Plus, Silverlight and other RIA frameworks are much faster than javascript when you are implementing heavy business logic on the client side.
Best Answer
Your REST API will be easier to use by others if you provide string IDs instead of translated strings. Using an API which returns
"E_NOT_AUTHORIZED"is more straightforward than if it returns some human-language, and even localized string.Also, you might want to change the localized strings in future versions, which would be a breaking API change. With the string ID approach, you still return
"E_NOT_AUTHORIZED", keeping your API compatible.If you use a framework like Angular.js, it is easy to implement language hot-switching if you use the string ID approach. You just load another stringtable, and all strings automagically change their language because you just use some filter logic in your templates, like
{{errorStringID | loc}}.Another consideration: To reduce your server load, keep your back-end as simple as possible. You will be able to serve more clients with the same number of servers. Deliver your stringtables through a CDN, and do the localization in the front-end.