The web has triggered a lot of change in recent years and architectures have been moving forward in order to fulfill new requirements. The first web applications had limited interactivity through forms and parameters, and all of the processing was done in server side and the pages were returned to the user. Technology has changed. Internet connections are faster, browsers have greater capacity and standards have evolved. These things have led to greater potential in creating more powerful web applications.
In this post, we will dig into one of the most recent trends in web application, web services based applications. We will be looking at both their benefits and challenges to help you decide when to use it or not as your main architecture in your web applications.
First, we will analyze the traditional architectures and then will present what a web services based application is, highlighting the differences between them. Finally, we will discuss the benefits and challenges that come along with this architecture.
Traditional web applications
At the beginning of the web, interactivity was scarce. Usually the user sent some parameters through forms or the URL in order to get a specific response back from the server. The server returned the page in HTML and the browser was in charge of rendering the HTML code, but not more than that.
Finally, the introduction of AJAX had a big impact on web applications because it allowed changes in small parts of the page without reloading it, with the possibility to go back to the server to fetch additional information.
Web services based architectures
In this case, instead of having the server return the HTML for every request, the server just returns one page that contains the UI logic to go back to the server through the web services, fetch the needed information and display it on the page. So, more than a page, what the server returns in the initial call is a UI application that can be executed by the browser.
It might sound, at first, a lot like AJAX calls because, in fact, there are many AJAX calls involved in this architecture, including the ones that hit the web services. The difference comes when we consider web services as something organized and structured, having authentication, standard request/response formats, etc. Usually AJAX calls in traditional web applications just refresh some parts of the UI and the responses are very specific to the UI problem to solve.
On the other hand, web services provide a way to control the underlying system, using standard data formats that can be used in contexts different than that specific web application. It can be used by another web application, a batch process, or a desktop application.
Having a good understanding of the differences between web applications that use AJAX and those based on web services is important in order to see fully the benefits and challenges we’ll expose a bit later in this post.
Afterwards, when the user interacts with the application and we need to fetch information from the server, a call to the web services is made and the response is processed to alter the UI accordingly.
This post does not pretend to give you a lot of technical details about how to implement this architecture, but rather gives you information to make decisions on whether you should use it or not. That’s why we will be analyzing the benefits of using it:
Loose coupling between UI and logic
There is a clear separation between the UI and the logic. Although modern server side frameworks help on keeping the presentation aside from the logic of the application, the truth is that often the boundaries get blurred.
Having a web services layer will force you to separate those two concerns and keep everything related to the presentation on the UI, leaving the logic clean and reusable (more on this in the following items).
The fact that we can make calls to get any (or almost any) information using web services allows us to code the UI in a way where we can get chunks of data as they are needed, improving usability and user experience.
This might sound a lot like what we already were able to do with AJAX, but the main difference resides on the broad scope of web services that allow us to access a lot more functionality than isolated AJAX calls.
Reusing of web services in several applications
One of the advantages of making the web services independent of the UI is that they can be easily used by other applications, whether they are web or desktop ones.
Once you have a good web services layer, creating new UIs based on them is relatively easy. In our own experience we have seen an important reduction in time to market and response to change when using this architecture.
Mobile apps and cloud computing
This one is closely related to the previous item, but due to the popularity of mobile apps nowadays, we wanted to point it out.
Having web services that can be consumed by any application makes it very easy to create a mobile app for any device. You might need to rebuild the UI (depending on the technology you are using), but the logic remains the same.
Additionally, given the rise of cloud computing in last few years, it is a perfect companion to make the information on the cloud available to different devices, with different OS.
Integration with third party applications
One of the most important benefits of having a web services layer is that it enables the integration with other systems. This is very important in the enterprise context as they usually have their own solutions they need to integrate. Having a good set of web services will make this a lot easier.
There aren’t only benefits. There are some drawbacks, as well, to consider:
You have to pay a lot of attention to security. This means that you will need to invest more resources on making sure that authentication and authorization schemes are flawless, and also think about encryption and other means to protect your data. Failing to do this can be disastrous.
As a result of making web services unaware of the UI, it could trigger a lot of calls to the server when displaying information to the user.
In order to mitigate this issue you should provide ways to retrieve more information in one call or provide some traditional AJAX calls that pre-process the information from web services before returning it to the UI. For example, instead of making ten calls to web services, the UI can make just one call to the server, that server-side component makes ten calls to the web services, aggregates all the information and sends it back to the UI.
An extra layer in your architecture
At the end of the day, web services are a new layer in your architecture. If you are building a small and simple application, having a web services layer may not pay off.
So, if you don’t need to integrate with other apps, you don’t plan to have versions for different devices and OS, and you don’t have to re-use the logic/data, then you are better off without web services.