Put code on client (JS) or server (C#)

Question

In an ASP.NET app, I've got to decide whether to put a complex piece of code on either the client in JS or on the server in C#.

I've considered performance (if on server, it would be a small callback), IP protection (all behavior is visible on the page), need for server interaction (none during the execution of this particular piece of code).

So the remaining question (that I'm aware of) is this:

Is it significantly easier, faster, better for testing and management, etc. to write the code in C# on the server than in JS on the client? Or is there not much difference?

---

The application is like a highly structured group discussion (presented as a single column, or list, of rows). The function in question involves building and formatting about a dozen different types of temporary rows used in adding to, editing and moving items in the list. The rows contain a few input fields which are filled by the user and then sent to the server. The inputs will have to be thoroughly screened for security on receipt at the server.

The specific algorithm for determining the content and format of the temporary rows has as inputs 1) the row that was selected as a starting point for add, edit, etc.; 2) parent-child relationships between the first selected row and the row being added; and 3) a few participant and group session state variables.

Answer 1

Is it significantly easier, faster, better for testing and management, etc. to write the code in C# on the server than in JS on the client?

It depends entirely on your Developmental ecosystem.

If you write and test lots of JavaScript code, then there might be some gain in doing so. If, however, you spend all your time cutting server-side, C# code and not so much in the JS world, then you're only slowing yourselves down.

However (and more importantly) ...

"The Client" [environment] is completely untrustworthy.

Anything and everything that the Server receives should be perused, checked and thoroughly scrutinised. Just because you sent the client an Html "select" control, you must re-check the value that the Client sends to you - you cannot guarantee that the HTTP data you're receiving even comes from the same client, let alone the same Control!

Answer 2

It's vitally important that all data is verified on the server when it comes from an untrusted client. (Doubly so with Javascript since hacking tools are built into browsers.) So the question is whether (and how) you should reuse the validation code on the server side or write separate validation code for the UI. Each has trade-offs.

Generalize

On the surface, getting errors from server side code is easy... just an AJAX POST away. However, matching string error messages to fields is brittle. Just listing the messages under the form is not as UXified as what's expected nowadays. So in order for your server-side validation to be useful for other purposes, it has to be structured properly. For instance, your errors could have identifiers that the UI can map to specific fields or messages. Sample errors:

["UsernameTooShort", "UsernameHasInvalidCharacters"]

In this case, either of the error identifiers are probably configured to cause the username control to light up red in the UI. You could wire up static messages in the UI to display for each of these (if present). You could send additional information with the error as needed by making it an object instead of a simple string.

[{"UsernameTooShort", "Username must be at least 8 characters."},
 {"UsernameHasInvalidCharacters", "You can't use '\' in the username"}]

You could display the messages associated with these errors directly instead of static messages while still knowing which control they should apply to, by their identifiers. You could even send context-specific data for specific messages. Either way, the errors are no longer simple strings, which will require some work on the server-side, versioning awareness because changing an identifier could break clients, etc.

Specialize

Now the alternative is to keep using your existing simple errors on the server, and use different methods in the UI. This has some disadvantages compared to above (not a complete list).

• DRY - Although technically the rule of 3 will likely apply here so it may not violate DRY
• Extra work - It's probably not more work considering what you have to do to make errors reusable on the server... however, it's work spread across different tech stacks.
• Divergence - Two implementations of the same validation can diverge over time quite easily without diligence.

It also has some advantages (not a complete list):

• Can be diverged intentionally -
  I have done this where I'm creating a new API and importing data which was not rigorously validated. I can't throw the data away, so it's nice to be able to make the server-side more lax to accommodate that and let the UI enforce more strict validations on updates and new data. Malicious users will still only be able to save data in no worse shape than what already exists.
• Each layer gets to validate in a way that makes sense for it. For the server it's often a binary choice of Pass/Fail (with message). For the UX, it's a bit more involved with control/style manipulation.
• Often the UI side will require extra validation code not on the server anyway due to technicalities of the platform. For example, control manipulation