js spa rest backend business logic vs presention logic

Question

I am very confused about what should a SPA's REST backend do and expose. In most blog posts and books I read they depict the backend pretty much like a direct access to the DB, practically CRUD methods that allow access to the DB after authenticating the user.

However I don't see where to put the actual business logic.

For example in an arbitrary screen that uses multiple resources, according to the CRUD way, I should do an ajax call to get all the data I need, filter and combine the data from all the different resources and use it. However, the way I combine and filter the data is sort of business logic and may change without any connection to actual presentation (and vice versa).

Or when some button should start an async process in the server, which doesn't maps to CRUD nor to a DB table/collection

So my question is, what kind of services should a REST backend expose? and where do the business logic goes? Should it be just a DB gateway with authentication, and all the B.L. will be in the javascript front end?

Answer 1

Server should expose those REST services, which fullfil your need in front-end for the single page application. When an application is developed which acts as the client for the data available through REST services, there is quite often communication between the back-end and front-end team. Because of this and the demands from the front-end team, the REST back-end developers may decide to expose several services which may offer quite similar data or data, which could be composed from different calls to the REST service, solely to make the transactions cost less time and resources.

Both your web services and your front end have business rules, but the set is pretty much guaranteed to be different. The whole back-end REST middleware is there to provide an abstraction layer between you and the database engine. You should not really care whether the data comes from a file or a PostgreSQL database, as long as you are able to retrieve. It is there to provide a standard and set rules about which data you can see. On top of that, by providing an abstraction layer you are only exposing the actions you really want the public to see.

You should put the business logic which is tied to front-end to the front-end application and stuff like validation, login, ie. operations which need to be run against the database, in the back-end. For front-end many of the business rules could consist of user interface indicators, such as if number of products is less than 5, display the product with red headline and notification, that the stock is low.

But there will be cases where the business rules of front-end and back-end will overlap. This is so that operations, which can be immediately discarded on the front-end do not need to hit the back-end service.

Imagine a scenario where you were logged-in in an eshop application and had 1500 credits. You wanted to purchase a product which cost 2000 credits. It is quite obvious, that you do not really need to run the purchase transaction to the back-end service and an "Insufficient funds" notification may be dispatched right from the front-end, by simply comparing the two values, of your current credit and the product price.

But that does not mean the business rule (that a product is only purchasable if you have enough credits) should be removed from the back-end. By giving someone an access to an application, you are directly giving them access to the source code. A skilled programmer could hack the application, give him an infinite amount of credits and then the purchase order would pass. That's why the rule has to remain in back-end as well, to provide server side validation that the action was actually successful.

For most people, the front-end validation is enough, but there will always be someone who will try to exploit it and those need to be stopped by the server. How an entire system is designed is for a very long discussion and also depends on the system itself.

---

A little bit on why REST/SOAP services became so popular.

A few years ago when someone else needed to use data from your database, you would create a specific user, assign it permission to be able to run queries only against certain tables/views/procedures, so they couldn't do anything else. This was pretty fine, until you found out, your database server is under a heavy load. Now what? The user has already published the application, has hardcoded the connection string into it (which forwards to your database machine) and when you created a slave although he changed the connection string, nobody downloaded the update and your database server is still burning from all the load.

There is another problem with this, that the external client would actually have the direct access to the database itself, which, although he only had a user with limited permission, is really not great security-wise. What if someone decides to DDOS the server which works as your primary database? Of course, you could set up some DDOS protection on it, but then you are kind of mixing responsibilities of the machine, acting as a database and filter at the same time.

By introducing an abstraction layer, the API you expose usually forwards to a balancer, which is an entry point to an unlimited amount of servers. Now the client has only access to the balancer and through IP rewriting his request is redirected to an actual server and then the response is redirected back to him.

During this request-response process, there may be more layers, one could be responsible for the DDOS prevention and some of them may be cache. This allows you to scale very well by adding more and more servers when necessary without altering the clients who are already using your API, which is amazing.