Web Services vs Server Side Methods

Question

With all the front end development frameworks now available. I'd like to know if the generally accepted protocol is for a back end service to simply provide web services for the front end to consume?

For example: An application that may have displayed products in the past may have just generated the HTML on the server and sent it down to the client browser during the request. It seems like the preferred way now would be to send the page template to the client, then the front end would make the request to get the list of products and display them using (Angular, Ember, React...)

Are there any performance cost to writing all client/server communication as web services?

Answer 1

As you say "web services" (not single service) you will be subjecting your users to multiple network requests to populate your page. This can be a bad thing, http 1.1 introduced the idea of keeping the connection open to request every page element in a single connection as it was quite faster, not to mention more efficient on the server.

There's also a question of security if your data-providing web services are directly connected to your untrusted clients.

As a result of these, its better to architect your page to make a single request to a single server that may then request multiple data sources and aggregate them into a single data set for the client. Whatever might look beautiful to the developer means nothing to the user who is going to have to wait for one block of data to arrive, then watch the page populate another set - it will seem far slower than simply having to wait for the old-style HTML request (regardless of the actual speed).

Of course the best way nowadays would be to use a websocket and stream data to the client continuously. This would require a single server on the back-end to serve this (last thing you want is many sockets opened on your server to serve a single user, that won't scale well)

Answer 2

There's a time & place for everything. Sometimes the right answer is to offer a web service that's consumed by client-side code.

This gives you the benefit of clearly separating your presentation from your model and business logic. One example is that you could completely replace your web interface with a native app.

There is of course a drawback to using a web service. It's often more complicated to code up, and it requires 2 round trips to the server - one for the template and one for the data.

To answer your question

Are there any performance cost to writing all client/server communication as web services?

Yes - it takes a little more developer concentration to code up and maintain, and it requires 2 round trips to the server to get the template and data.

However, that extra cost is often a good investment and well worth the effort.

Answer 3

There is no generally accepted practice. There are different architectural patterns for web applications.

The server-side presentation pattern has the entire work of generating a page done on ther server side. The navigation in the application is between pages rendered entirely by the server. This is the oldest model as it has been supported as long as HTML itself.

The single page application has a server-provided application loader page that may be static. This page references a fully client-side application that will render pages and obtain content via XHR (large infrequent requests), EventSource (text-based server side events), Websocket (streamed, binary content), or WebRTC (realtime peer to peer audio/video) depending on need. This is a popular model for recent web applications.

There are also hybrids of both approaches that enable optimizations of page load time and resource consumption. An often overlooked aspect of web application development is power consumption on mobile devices. A particularly bad example of this is a periodic XHR to obtain updates. It will trigger the cellular radio to come on right after it has idled maximizing battery consumption and maximizing latency.

There are no straight forward absolute answers here. There are some principles with obvious wins though:

1. Make as few requests as possible
2. Send as little data as possible (use efficient representations and compression)
3. Take advantage of caching (set Cache-Control and Last-Modified, and Etag headers correctly)

My personal experience with switching from server-side presentation to a single page application was a substantial improvement in responsiveness. There are definitely downsides to having every data set on the page pulled down in a separate request. The downsides are directly related to how they violate the principles above. We had to learn to bundle data sets into fewer requests.

Interestingly with HTTP/2 the bundling is counter-productive because HTTP/2 supports multiple streams (standard requests or otherwise) on a single TCP connection. Don't spend a lot of energy optimizing for HTTP/1.1 in ways that will hurt your app for HTTP/2. This trade off is not completely straight-forward either as Khan Academy discovered.

In your case I would advise going with a client-side presentation framework. It gives you more flexibility in rendering timelines and request counts. More importantly it gives you an application that doesn't go to a white screen when the server processing a request chokes or disappears. You can actually handle that as an exception on the client-side and provide user feedback and retry mechanisms. I do not recommend server-side presentation frameworks except to facilitate more efficient delivery of single page applications.

Much more on this is available in Ilya Grigorik's High Performance Web Browser Networking.