Business logic in JavaScript. Fat client vs thin client

Question

Is it a good idea to implement business logic on the client side with JavaScript?

What kind of logic should be there? Validation Logic? Related to GUI?

What would you do if the same logic want to be used in another application (exposed) implementing it in JavaScript would mean you can't reuse that logic.

On the other hand having all logic on the server side would mean more requests to the server.

What do you think?

Shanaeshanahan

You have just asked, what i would like to know exactly! Thanks. – Garibay

Answer 1

You can create reusable Javascript modules so there's no intrinsic barrier to resuing logic in several different rich uis. However, as has already been pointed out, you probably end up with duplication between the JavaScript and whatever you're using on the server (Java, PHP ...) - in the case of validation that's a trade-off between giving a performant user experience and complexity due to duplication.

I can imagine scenarios where you would choose to duplicate more than just validation. Consider computing a total order value: do we really want to make a server-side round trip for that? Sorting a list - we tend to do that happily in JavaScript, but we sorting can get interesting, specialised comparator functoions? Drawing the boundary may be quite tricky, computing discounts and sales tax?

In the end it's a judgement call, followed by careful understanding of consequences. If you duplicate logic then can you devise a test strategy that ensures consistency? With low volume systems you may be inclined to favour more server interactions and less duplication, but you may well make different decisions for a larger or more demanding user-base.

Absa

Answer 2

One should never ever trust the client. Thus, any validation you do on the client side with JavaScript can only be to improve user convenience and usability. You always have to validate incoming data on your server later to make sure nobody injects data etc.

Ranunculus

Answer 3

It's convenient to implement validation logic in the javascript from a performance perspective, as the user doesn't have to wait for server calls, but you still have to validate all the data sent to the server.

If you don't, you will end up with malicious people corrupting your back system.

Carefree

Which means that you should keep the validation rules on both (client x server) sides. – Stempien

Answer 4

'Couple (possibly opiniated) notes from 2013:

Web applications shouldn't be developed differently than any other application.

Take any 2+ tier application (any normal client-server model would do); does it make sense to process things on the client or on the server?

Performance considerations

You have to take into account processing power, network latency, network bandwidth, memory and storage constraints. Depending on the application, you may choose different trade-offs.

A fat client will usually allow you to process more on the client and offload the server, serialize more efficient message payloads, and minimize roundtrips, all at the cost of processing power, memory efficiency, and possibly storage space.

Security considerations

Security is transient, regardless of the model used, each party (not just the server) will always have to verify and possibly sanitize the data it receives from the other to some extent. For many web applications, this means validating entities with business logic, but not always. This depends on what the data is, and who has authority over it (and it's not always the server).

Since the web browser already verifies a lot of information, the client-side considerations are fewer, but shouldn't be forgotten (especially in an client that makes XHRs or uses WebSockets, where there is less hand-holding).

Sometimes, this means that indeed both the server and the client will validate the same data. This is OK. If you develop software on both sides, you may extract your validation code to a module used by both the client and the server (like all these "common" modules in traditional software packages). Because your choice of language is limited on the client-side in a web environment, you may have to compromise. That being said, you can execute Javascript on the server, or compile many languages down to Javascript using things like Emscripten (also see amd.js), or even run native code in an uncertain future using things like NaCl/PNaCl.

Conclusion

I find that it helps to think about web application clients as 'immediately-installed', 'zero-conf' and 'continuously-updated' clients. We don't use this terminology for the web because these properties were always intrinsic to classical web-based software, but they weren't for classical native software. Similarly, we don't use terms like "Single-page applications" when developing native software because there was never any requirement to restart the entire application whenever we needed to switch to a new screen with classical software.

Embrace the convergence, and keep an open mind; people coming from different communities are going to learn a lot from each other in the coming years.

Erastus

Answer 5

One way of attempting to do what you're looking for is to use some type of web service/ web method acess and have your javascript make ajax calls to the methods, do the validation on the business logic and then send a return back to the front end.

Now the front end would be chatty with the server, but you would have the ablity to share that business logic validation with other appliations within the same domain easily. A second benefit of this approach is that all of the business logic and validation is on the server, and not exposed in a way where a malicous person could easily view or manipulate the code.

Good luck, and hope this helps some.

Anthurium

Answer 6

Javascript should be used to enrich the user's experience in the GUI but your site/webapp should still work without it.

Parameters sent to your server can be manipulated by the user. If you rely on Javascript to validate or create these values you're basically asking your users to try and do naughty things. (And they will)

Javascript for validation is fine, it will reduce the amount of requests to your server for users who use the application normally. But that still falls under enriching their experience. You still need to validate server-side for the 1% of l33t h@x0rs who will try to create problems.

Urien

Answer 7

I've done a lot of AJAX work in the past few years and my take on it is this:

• Put the business logic in the client to augment the more important server side validations. I've worked for some financial institutions and they always had very good security because it was done in depth. Client side validations, server side validations, framework security, etc..., but they always had it in each section of the applications. They never assumed anything was safe and they built their intranet apps as if they were internet apps.
• Other business logic can be put in as well, but keep the idea of a thin client at all times. The other main reason I would put business logic in the client is for performance.

For example, once I had a topmost dropdown that aftected five other controls below it on the page. Rather than doing a server-side trip for each of the controls I realized that the topmost control made one call and controlled the data display on all the subsequent controls in a cascading fashion. The other controls inter-operated between themselves with the same data, unless the topmost dropdown was changed. So I created a manager that cached/handled the data and the performance was excellent! Most of the user interactions were based on that initial dropdown selection, kind of an 80-20 rule of use. Most of the time they just made one selection and got what they wanted.

• Use Presentation Logic in the client. By this I mean if you have sorting on a dropdown that you can do in a GUI Widget via a property, then by all means do it. When I've worked with GWT in the MVP (Model View Presenter) paradigm you were never to put any business logic in the view, but you were allowed to put presentation logic there. It's not business logic perse, but in ties in well with the other.

Riata

Answer 8

Business logic should be as consumer agnostic as possible. When designed properly, your client and server code should be able to consume your business logic in a reusable fashion (assuming that both client and server can consume javascript).

Consuming your business logic from a client (browser, etc.) can prevent needless hits to the server, assuming a malicious user isn't bypassing your UI to hit your endpoints. This same business logic can then be consumed by your server as your last line of defense.

In addition, if designed properly, you can extend your business logic to encompass more complicated workflow logic that needs to perform well, run within a transaction context, etc; generally things that would be difficult to facilitate via the client.

There are many design patterns that you can rely on to help you design reusable business logic.

There are also micro-frameworks available, such as peasy-js, that help you to rapidly create business logic that is easily reusable, extendable, maintainable, and testable.

Kelsi