Does business logic really belong on the server?

Question

A typical stack for a web application is a database, a server with server-side code, and a user with a browser with HTML/CSS/JavaScript.

Before extensive AJAX, MVC in which the controller was the server-side code rulled. A server had to route answer requests for Dynamic web pages (i.e. templated html solutions like JSP and ASP). The server to coordinate the calls to the database and decide which dynamic page to use to answer the page request. The result of all of this is that server ended up containing the business logic, even though business logic isn't strongly tied to the idea of serving pages.

Now that we are moving to "Web 2.0" a server servers static pages that use JavaScript to fill themselves and change what they are presenting. The can be in the JavaScript. The JavaScript often implements a RESTful service meaning that it is specifying database query.

So the server is left to the roles of serving actual files and answering AJAX calls. And answering AJAX calls is merely session management and providing security. And really, what a user should even be able to see is data that should be specified in the database.

So from there, should the server be relegated to the role of a dumb intermediary that only occasionally does something like send out an email or fire off a webservice? Could business logic all live in JavaScript (when it is not secret) or live in stored procedures when it is?

Will it make sense to maybe even combine servers and databases or make ERP solutions like SAP function as servers?

Answer 1

Business logic almost always has to run on a server you control, for security reasons. If by "server" you mean "web server", then I agree, it doesn't need to have almost any business logic. But you almost always need an application server with the business logic, whether that's inside a database or a web server or is separate and called by the web server.

There are real world applications where the web server does nothing but expose the API of the application server via web services or JSON.

Even prior to Web 2.0 and AJAX it really wasn't considered a best practice to mix your business logic with ASP pages. It was considered better to have an independent business logic and to have the server portion of the presentation logic be in ASP, JSP, or whatever. So the real change from web 2.0 is that the presentation layer can be entirely in javascript. I kind of prefer that, personally.

Answer 2

The JavaScript often implements a RESTful service meaning that it is specifying database query.

This is where you got it wrong. REST is not CRUD.

The resources exposed by REST are not your database records; they're fully managed objects that behave according to your business logic. When the server receives a POST or PUT, it shouldn't just validate and store. It has to perform anything that's appropriate for the application.

Simple example: a twitter-like app receives tweets as POST messages on a given container. The server then analyzes the context ("who are you?", "which channel is this?") and content ("any hashtags?", text indexes, etc.) and stores all this in the respective queues. Probably adds a reference directly to all your followers.

That's a lot of work beyond simply adding the resource to the container, it's all defined by your business logic. And it belongs on the server.

Answer 3

My concerns with this approach may be due to misunderstanding of your design, so please feel free to shoot me down.

however, think about the scaleability, maintanability and security of the product.

If your product grows massively, the database becomes the bottleneck, so whilst "performance" suggests putting business logic into stored procedures, it puts additional CPU load on your database server, bringing forward the day when the server reaches max capacity. Unlike webservers, ACID databases do not easily scale up by using parallel hardware. If your product will never be that successfull, this is not an issue.

The thought of maintaining business logic in javascript running on webbrowswers, where different browsers will requrire different javascriopt, multiple versions of browsers, etc... Why make this issue any more complicated than it already is?

As Javiar has said though, using a REST approach as a database API for your product is really not sensible. Its a benefit of a REST interface is that other people will then think of different ways to use and query your REST interface. However this is public post business logic resources and not low level table record resources. The thought of making such low level data queries available over the HTTP api sounds like a security nightmare.

Answer 4

While there are many schools of thought on this, and certainly no one way can be called "the right way" universally, while all others are "the wrong way" universally, there are a number of reasons to isolate business logic on the server side, and access those objects and services through a RESTful service.

The short answer is that it's mostly about risk management, and performance monitoring and improvement.

In detail:

The number 1 paramount reason is security. Clients should never be trusted to submit anything other than garbage to the server, and by keeping the security aspects server side, you isolate the potential risk of a rogue user damaging your system. Remember, Javascript is completely client side, and trivially changeable, so you CANNOT TRUST THE OUTPUT.

The number 2 reason is separation of concerns. Your javascript programmer may not be an expert on security, and your security guru may not be that great at Javascript. By isolating the business logic from the presentation logic, you avoid crossing these concerns, as the javascript will not be allowed to access resources beyond its permission levels, and be given errors, the handling of which is within the prevue of the Script Programmer. Likewise, the Security guy won't be debugging Javascript to see how security is maintained.

The number 3 reason is performance. Business logic can potentially be demanding of server and database resources. By keeping that logic isolated from your UI elements, you can then scale out just that portion of your application, making it that much easier to address bottlenecks. Additionally, it's much easier to isolate which business process is loading your system or database backends if the business processes are executed on the server.

A corollary here is that often several business processes will use the same data, and so you can implement caching on the server side to reduce overall system load that might not be possible/secure to give clients side code access to.

Finally, I would propose that in order to maintain ACID standards, Business Logic really does need to be on the server. I remember maintaining a billing product that ran in the web browser, with only a database connection to the server. If the daily billing (which could take an hour or more on a good day!) were interrupted, say, by the browser being closed or crashing, it could take several hours to sort out the mess it made of the database, which was left in an inconsistent state. Remember, this also involved credit cards, so the billing records had to be checked against the processor too!

Server side business logic is mostly trivial to ensure ACID updates, as there any frameworks for any language to maintain transactions, either at an application or database level. If you're doing this via multiple updates from a web client... you're going to get inconsistent state at some point, and it's likely going to affect your application.

While it can be tempting to think of RESTful services as simply a way to access the database, you shouldn't fall into this trap, as it's a good recipe for disaster. The object model you expose via a RESTful service can be related to your database, but should really encapsulate your business logic instead of just using it as a CRUD engine.