Web Applications: Client-side domain logic

Question

We see more and more work for web-applications done on client side. UI manipulation, input-pre-validation (not as last resort of validation, of course), widgets, effects, etc, etc.

What if one decides to put domain logic on client side written in Javascript/GWT/anything else? The server just provides database infrastructure.

Does this sound viable to you? Any experiences, advice or opinions to this idea?

Edit: If you poke around, you'll realize that it is possible to write entire applications without a single line of php/python/java/whatever.

Answer 1

Those things are all nice, but remember that if someone disables javascript you'll need to be able to handle that and validate input on the server before your users mess with your database. So you could put whatever you want on the client side, but you'll need to also verify it on the server side.

Answer 2

This is not a viable idea in my opinion. There are a number of reasons for this.

1. What happens if the user doesn't have these client-side abilities because they have an older browser? The website will most likely not work.
2. Always, always perform all the same checks on the server for validation of input and rule checking as on the client. Otherwise, it leads to major security problems with your website. Users can bypass all the javascript checks and do whatever they want to your database.

All in all, while client-side code is really nice for providing users with a more application like feel than a web page feel, in order for the security and accessibility of the website, the two techniques need to be both implemented.

Answer 3

I would think that would not be viable, at least if you are aiming for consistency and speed. Putting a lot of logic into say Javascript would cause a lot of work for the Browser, which means a SLOW client. Also, Don't forget all browsers have their little quirks.

Answer 4

I respectfully disagree with the other posters here. In fact I have implemented just such a scrabble board game, using almost entirely client side logic. In fact, there are many things that I would like to do to make it even more client-side intensive. GMail does a tremendous amount of work on the client side.

However, there are some things that need to be managed on the serve side for practical reasons. For example the server needs to give the user some tiles and the user can then tell the server where he put those tiles and the server needs to verify those slots are empty because the server can never completely trust the client (the client can always be hijacked, if not through the script then by sniffing the HTTP traffic and modifying that).

There are a lot of technologies, some like ADO.NET Data Services to expose CRUD operations in the DB through a RESTful interface, and CouchDB to store/manage data objects directly through JavaScript. Also, rich client side libraries like jQuery or Moo Tools are really pushing the client to do more and more.

And if you think about it, flash is a lot about doing all the UI and interaction stuff on the client side. Some of the Adobe Flex applications are just awesome. I recently used one for Google analytics which renders the graphs, pivoting and all that on the client side. The server just serves the data. Even so Google Gears and Firefox (3.2 I believe?) now provide client side storage which makes disconnected application scenarios all that more interesting.

Answer 5

Depends on the application and how you want to use it and re-use the code.

Client side javascript is really specific to web browsers.

Domain objects and entities can be reused in other applications (desktops, web services, etc)

Not to mention when and if your app gets larger and larger, the download times will get longer and longer.

And of course, anyone can copy paste your code and clone your app in no time.

Answer 6

For any public (and non-public) web application it is only a matter of time before someone tries to check out your defenses. JavaScript validation will be the first to go. Since you can just disable it in browser, or even disable/enable it while working with your application to achieve the desirable effect.

You should have three levels of validation actually.

1. UI validation (optional): first-time check of user input. Quick response without server roundtrip -> user is happy + your servers are happy that you could free them from some amount of invalid requests already.

2. Server-side validation (required). Here goes all that validation again + business logic rules. You'll likely have to access some standard or third-party libraries to check/validate/do whatever you have to. Here you achieve your data integrity on the BL level.

3. Database-level validation (very desirable). Last perimeter of defense. Assurance of data integrity through the use of foreign key/unique key/etc. constraints + transaction-level protection from multiple parallel requests suddenly destroying your BL-level integrity.

That's how it should be if you want to do it right.