Java – Microservices Architecture separating backend and front end

Treat Web services the same as any other data access:

To approach client side MVC architecture, without frameworks, we treated Web services in the same manner as we did localStorage and the local IndexedDB database. All code that involves requests to remote servers or that query a database or that read/write to localStorage happen in the model layer as DAO objects.

These were written using either the prototype pattern, the module pattern, or in some cases a combination of the two, using a modified factory pattern to treat objects as singletons in production but allowing us to "reset" them when unit testing so we keep tests self-contained.

They're generalized so that no application logic exists in this layer, and most of the code at this level can essentially be reused across future applications.

The services layer encapsulates the DAO layer, keeping the specific storage technology separate from the controller logic. Thus, pushing data to a remote server is seen as the same as inserting data into IndexedDB.

Used raw XMLHttpRequest to interface with Web services:

We chose not to use jQuery AJAX. Instead, we wrote a wrapper around XMLHttpRequest. There's no right or wrong answer here, but choosing not to use jQuery here allows us to stay focused on the rule of having no DOM manipulations in this layer. By wrapping the AJAX logic inside a prototype class, we set certain default headers, since most of what Web services deals with in our case is application/json data.

However, we did make an exception for jQuery Deferred. It didn't seem to make sense to write our own Observer implementation simply to be purists, and our logic behind this decision is that future professional programmers who work on this project with us have a better chance of understanding $.Deferred than some hand-rolled implementation. Many developers, on the other hand, we argued would have been exposed to XMLHttpRequest at some point in time, so being a purist here seemed less risky from the perspective of communicating to other developers what a piece of code does.

Analysis:

Earlier, I mentioned rules. We wrote up a series of "rules" designed to keep the code maintainable. For instance, rule #1 is that jQuery DOM manipulations only happen in a "view" layer. So the only jQuery we use in other layers is the $.Deferred object and nothing else.

We use $.Deferred throughout the application to keep certain logic in the layers where that belongs. For instance, we keep a persistent $.Deferred observer in the DOM click handlers in order to "notify" the controller that a click event has occurred so the controller can then delegate to other layers of the application to get/set, fetch/store, or perform other actions.

Using TDD as a development methodology, we've created small functions, where the largest is never more than a page, and most layers have a great deal of test coverage.

After a few months, the jury is still out on whether we should have used a framework, as much of what we've done could be generalized further into a reusable framework. We've learned quite a bit trying this, and I'm hoping this experience helps others who wish to develop client-side applications that involve a lot of asynchronous operations.

To give credit where it's due, I took inspiration from the following people:

• Ben Nadel's article on A Better Understanding of MVC Model View Controller
• My colleague Varun Vairavan, who has written some tools for AngularJS and node-webkit, and who was heavily involved in many of these technical decisions based on his experiences with Backbone.js and AngularJS.
• Joel Spolsky's Law of Leaky Abstractions, which we personally dealt with when using a specific JavaScript framework.
• Ben Nadel's Using jQuery Deferred To Create Compound Objects From Multiple Asynchronous Data Sources

For further reading on going framework-less, see Joe Gregorio's Zero Framework Manifesto

Both controller layer and service layer expose certain interfaces. Interfaces define contracts on how the interface should be used. Contract usually means which arguments (and its types and values) are expected, which exceptions can be thrown, which side effects are created etc.

Now, your validation is essentially enforcement of the contract of controller update() method and service layer update() method. Both of them have very similar contract so it would be natural if the validation (enforcement of the contract) would be common too.

One possible way to do that is to separate the validation of this contract and have it called in both layers. This is usually most clear - each class/method enforces their own contract, but is often unpractical because of performance (accessing database) or other reasons.

Other possibility is to delegate this validation to the service layer while explicitly defining the behavior in case of failed validation in the service layer contract. Service layer will typically return some generic validation error (or throw exception) and controller layer will want to react in some specific way to the error - in this case we will return 400 Bad request to signal, that incoming request was invalid.

In this design, there's a danger of too much coupling between business logic in service layer (which should be quite generic) and controller (which handles integration logic).

Anyway, this is quite controversial question and 100 people will answer with 100 answers. This is just my take on it.