Server-side versus Client-side

Deciding which service access strategy to implement depends on several factors. If you are already building Web applications today you may already have an established pattern for data access on the Web. If so, you may want to continue with this strategy for consistency purposes. Fortunately, when implemented correctly, jQuery Mobile will integrate very well with either strategy and ultimately you can collectively choose which pattern is the best fit for your particular application needs. The following are supporting considerations for each type of strategy:

Client-side integration:

• Faster response times. Client-side integrations produce faster response times because they have fewer point-to-point server dependencies. For instance, we could have aggregated our Twitter data on the server-side but our response times would have decreased due to the additional server communication.CAUTION: While client-side integrations offer quicker response times, use caution when integrating with third-party API’s because it can be advantageous to encapsulate them on the server-side to better isolate your own pages from third-party modifications. For instance, Facebook’s RESTful API has changed frequently in the past and now it is actually deprecated.
• Faster to implement. Our Twitter example on the client-side was a very quick implementation because only our client-side markup required modifications. Implementing this task on the server side would require client-side and server-side components to be modified.

Server-side integration:

• More reliable. A server-side solution is more reliable than a client-side solution because you don’t have to be concerned with client-side JavaScript incompatibilities.
• More secure. When implementing client-side solutions you must be cautious of the API’s and type of data that is exposed. If you are integrating with API’s that exposed Personally Identifiable Information (PII), Personal Health Information (PHI), or Payment Card Industry (PCI) information a client-side solution would not be advisable.
• Cleaner page markup. We saw examples of this when comparing our pages that were implemented with server-side versus client-side access strategies. The pages used in our server-side access examples had no dependencies on custom JavaScript.
• Simpler unit testing of components. I am a believer in the idea that server-side unit testing is still simpler than client-side unit testing. However, after committing several QUnit tests on the jQuery Mobile project, I am beginning to believe that client-side unit testing can be very successful and reliable!

CopycopyHighlighthighlightAdd NotenoteGet Linklink