Should webservices be used to create entire websites?

Question

I’ve been working with ASP.Net MVC for the past couple of years. I've got really used to develop using this pattern. Regarding the front-end, so far JQuery has been more than enough for what I need.

However, as time goes by, I’m hearing more and more that AngularJS is the way to go, and that JQuery is becoming ‘a little’ obsolete.

That’s why I’ve been studying some options to integrate AngularJS on my current project. There are some important facts to take into account:

• Angular makes more sense for SPAs (Single Page Application) than it does for non-SPAs;

• Angular is a Framework, JQuery is a library;

• On the ASP.Net MVC paradigm, we usually send to the client plain HTML. In Angular projects, the data is usually sent to the client via JSON;

• Angular and Razor don’t go well with each other. Razor is an abstraction to help programmers render complex (and sometimes not so complex) HTML. With angular, the view will not be created on the server-side, it will rather be created on the client-side from a model transmitted by JSON (ex.);

• Angular goes hand in glove with Web API (or any other web-service), while JQuery goes hand in glove with ASP.Net MVC controllers;

Conclusion: Correct me if I’m wrong, but it seems that the server-side of the majority of applications using Angular are composed of nothing but web-services.

My question is: Should webservices be used to create entire websites? Apparently, that’s exactly what’s happening with the new wave of angular-based applications.

Answer 1

To answer your question Should webservices be used to create entire websites? YES... if a SPA that talks to server-side resources is a requirement.
Whether that is a good requirement depends on the answer to other questions like:
Do we really need a SPA?
Do we have the developer skills to build a SPA? If not are we willing to hire or skill up existing developers and take on that cost?
Can we afford the extra development?

The cost involved in the extra development depends on how "heavy" your controllers are. If you have a clean architecture with a well defined domain model and services (not web services) and the controllers just orchestrate between the service and view, then building out a WebAPI shouldn't be too difficult. If your controllers are filled with business logic you need to either convert them to a WebAPI in which case you have to change views at the same time and a side-by-side development goes out the window, or you duplicate, or you refactor. I recommend refactor but that won't be trivial.

To some of your other points. You can absolutely use Angular on a per page basis to move that page to an ajax based communication rather than a full post and refresh. You can also just as easily use JQuery for this though with a plugin like jQuery Forms. Using JQuery has the benefit of leveraging existing knowledge and frankly is more straightforward. Angular, because it is opinionated does promote a standard way of doing things so it does mean your javascript codebase should remain more structured, as it is its own little client app contained within the mvc app. Another benefit here is that this way you are a big step closer to a SPA if that became a real requirement.

A closing thought here, and this could factor into a decision to take this plunge. When you create a SPA, you are creating a javascript/html client that interacts with your exposed API. Other clients could also use the same API like a mobile app or a partner site.

Often the desire to go SPA is because as a developer you want to learn the "new wave", and that is a good thing. Just make sure whoever is fitting the bill knows what they in for and is happy to do it.