Client-Side JavaScript Business Logic in .Net Solution Stack

Question

Fellow developers on other teams I interface with seemingly question my judgement calls as they pertain to the placement of coded business logic in a .Net MVC/Knockout web application currently under development. Granted, these types of questions have far reaching implications as they pertain to high-level architectural design patterns but warrant a detailed analysis nonetheless.

For example, let’s say we have a chunk of code that pulls data from a database, runs some calculation and then validates it against some user input. The argument consistently raised is such that the layers outside of the client browser (depicted below) should simply facilitate activities such as storing and passing data, security and other such activities that fall outside of implementing business logic. Then, within the browser, business rule validation and implementation.

[Client Browser/JS] <=> REST <=> [IIS/.Net MVC] <=> WCF/SQL <=> [WCF Endpoints & Databases]

Granted, there are numerous client-side JavaScript frameworks do promote this type of implementation pattern but I believe the intent with these assumes that the business rules and processes will always be executed client-side. Said another way; coupled to the browser.

In my particular circumstance I’ve come up with a few arguments against such an architecture and I want to make sure I’m not missing anything or being misleading.

1. Testing: While we can leverage testing frameworks such as Jasmine the level of effort involved with developing and integrating these types of test scripts is substantial compared to the TDD approach used with other back-end .Net development methodologies.

2. Debugging and Development: Similar to my testing argument; most mainstream browsers have great development and debugging plugins that make development far less frustrating and enjoyable today. However, these still do lack the richness in capability and ease of use when debugging domain/business objects on the back-end within Visual Studio.

3. Coupling: Domain/Business logic is tightly coupled to JavaScript runtimes. The browser in this case.

4. Code Security: This is one is pretty straightforward.

5. Cross-Browser Compatibility: While less of a problem today it does warrant some consideration.

Is there other high level items or constraints that I may be missing?

Answer 1

I write this from the perspective of a long-time .NET developer being pulled inexorably into the client-side JavaScript world, so I assume that I probably share some of the same biases as you. I only bring this up because I think a lot of your bullet points are probably biased by your experience and relative comfort with C# and .NET over JavaScript.

For instance:

1. Testing: While we can leverage testing frameworks such as Jasmine the level of effort involved with developing and integrating these types of test scripts is substantial compared to the TDD approach used with other back-end .Net development methodologies.

That is being challenged daily by the JavaScript community. There is a significant amount of effort that goes into a proper .NET TDD approach that I think you're glossing over here. Certainly no more so than the ever improving JavaScript testing frameworks. But, as you are presumably more familiar with the .NET-related tooling and practices, it seems what you're really concerned with is the learning curve associated with adopting JavaScript-related new tooling and practices. That's a valid concern, but not really the same as ".NET is better".

2. Debugging and Development: Similar to my testing argument; most mainstream browsers have great development and debugging plugins that make development far less frustrating and enjoyable today. However, these still do lack the richness in capability and ease of use when debugging domain/business objects on the back-end within Visual Studio.

It's hard to argue against the rich debugging capabilities of Visual Studio, so I won't. :-)

But, I would argue that the vast majority of the time (in my experience) only a small subset of the debugging capabilities of VS are ever being used. Most of what happens in the debugger is stepping through the code from breakpoint to breakpoint, inspecting flow and state along the way. One could argue that this can be done just as well in (well designed) JavaScript code on the client as it can in C# code on the server. Especially when using VS as the debugger.

3. Coupling: Domain/Business logic is tightly coupled to JavaScript runtimes. The browser in this case.

I'm not sure I agree with this. Well modularized JavaScript code does not need to coupled to the browser. Business-logic code (as opposed to DOM-manipulating code) can and should be written such that it can be executed and tested without the browser.

5. Cross-Browser Compatibility: While less of a problem today it does warrant some consideration.

I agree. When writing code for .NET on the server, you know and control what runtime environment your code is running under. With JavaScript, there may be subtle differences with some code between the different JS engines. I wonder how much of a real impact this would make, though. Have you come across an actual example of this or is it hypothetical at this point?

4. Code Security: This is one is pretty straightforward.

This is the big one, for me. And the deal-breaker. It's simply the case that code running in the browser (and not on the server) is out of your control, unless you can control the browser, too. A responsible app would have to double-check all of the business-logic performed on the client, since the integrity of the client should not be trusted. This would seem to me to lead to either a lot of duplicate code, or an untrustworthy app. This is less of a concern with an internal-only corporate app than with a site open to the public, but it should still be a concern nonetheless.

All of this is to say that, if I were on your team, I would agree with you. :-) But not for the reasons you provided, which wouldn't be very convincing to someone eager to embrace JavaScript and client-side programming. And those arguments are getting weaker by the day.

Answer 2

I think many of your main points are quite misguided; claiming that "yes browsers can do it but Visual Studio is better" is not going to convince your coworkers (who probably are more used to debugging JS than to working with VS). Also:

• number 3 is not an actual issue; you can write JS that does not rely in the browser version and that means no more restriction that you would have by writting it in C# (in fact it could be argued that you are restricting yourself more by using C#/CLR, since you can run JS on your server).

• number 5 is also senseless; even historically, most cross browser issues have been related with the implementation of the DOM (how to access a form, input field, which properties those support, etc.) than with the JS itself. A well written JS should have no issues.

The main factor is that, as always, you cannot trust the client. Unless the result of the business logic is only output for that client use, you cannot implement it because you cannot be sure if that result comes from your logic, or from other piece of software claiming to be your logic.

Imagine that your bank worked like that; when you logged in it would send your browser the status of your accounts at your last login and the list of transactions that have happened, so that the browser calculates the current amount in your accounts and sends that data back to the bank (who would store it in their DB). Does that sound right? Maybe someone would try to profit from this architecture?

Even in a schema where people would not profit, like SETI@home¹, some people "hacked" the legit program just to improve their statistics. If someone would benefit from feeding your system false business results, at some point someone will try. Moving the business logic to the browser just makes it insanely easy to do so.

Additionally, moving your logic to the customer will usually mean that your data will be harder to secure, since you will need to give access to almost everything to the browser so it can process the business logic. Getting the granularity that allows access to all that is needed but not a single bit more is going to be a lot of work.

¹: In case you do not remember, SETI@Home was a program that you installed in your computer to process data from a radiotelescope in its spare time; in the hope of finding a signal send by an extraterrestial life form.