9

Let's say 3-5 years ago (more or less) n-tier application on the server side - and some javascript/html/CSS for the UI was a basic approach for web development.

Nowadays we can see that traditional web development paradigm changes a lot. Each day I saw more and more application who do not have server side in traditional way. They just consume some services (data-service, auth-service, etc.) but the business logic placed on client side. Also already a lot of javascript frameworks creates for simplify development according such model (Angular, Backbone, etc.)

What are the main benefits and disadvantages of new model versus traditional approach?

Improve this question
1
  • 4
    Only a fool would only put their business logic on only the client. This approach means you'll have to duplicate much of the business logic in two places. Never trust the client.
    – Andy
    Apr 30, 2014 at 0:52

4 Answers 4

Reset to default
11

There are several advantages to this approach:-

  • Responsiveness, because the business logic is in the fat client you do not need to wait for a round trip over the network for every interaction.
  • Sophistication - having all the control and higher level logic in the client enables rich user interfaces (e.g. this site, or gmail) which would simply not be possible if every interaction required a round trip to the server.
  • Scalability, all this processing is taking place on your device, using your electricity. if you have a large number of users the saving in server side processing is significant.

There are a few downsides though.

  • Lack of control over the client environment. You do not know which browser on which OS or what screen size and processing power your client will have. You application may not work on every client.
  • Uneven response. Large client libraries need to be downloaded and upgraded every now and then which will be relatively slow, once downloaded the response is lightning fast, users, generally prefer a consistent response time even if it is a little slower.
  • Javascript -- love it or hate it you are stuck with it as your main development language. Your code becomes public which some companies hate (perhaps they are embarrassed by their code quality?).
  • Security -- your server side code is now largely just database services whose APIs are open to anyone studying your Javascript therefore you need to take extra care in securing these services.
Improve this answer
2
  • This is totally applicable to all n-tier development, not only web. I found myself using these same arguments when defending a fat WinForms client & Thin WCF server architecture a few years back.
    – Boris B.
    Oct 15, 2013 at 10:52
  • 4
    Security is not just a some downside, but it should be a no-go reason against putting business logic to client-side. Gmail has got responsive and sophisticated UI, but business logic still is part of backend, not client side. Could you imagine consequences, for example if the right, to send an email under/from specific email address, was evaluated on client side?
    – kravemir
    Oct 7, 2019 at 13:45
3

I think we are talking here about two kinds of logic:

application logic and business logic.

Application logic contains use cases. Business logic contains business rules. Application logic (and presentation logic) can be implemented on client-side. Business logic only on server-side.

Improve this answer
1
  • Thank you for answering a question on stack exchange! Your contributions are always welcome. I would recommend you answer the specific question posted by OP in terms of the differences in the development methodologies between traditional, vanilla HTML/CSS/JS server-side rendering vs using a framework for client-side rendering. This will be highly beneficial for users who find this question from search engines.
    – Rakshith Ravi
    Apr 4, 2020 at 11:23
2

In addition to what @James Anderson said, if you are working on a system that uses shared database tables, you want to avoid repeating the business rules on the server and on every type of client you choose to use. In some cases you have to, as the case is in validation, but other business rules should not be repeated if possible. Attempting to replicate the same rules in different languages is error prone. Also, sometimes you need to extract several pieces of data and pull this data to the client to perform your validation. This goes against responsiveness.

INMO, separation of concerns is to be considered a priority in design when responsiveness is not a critical issue.

One subject I avoided raising is "what do you do with clients that turn JS off?"...

Improve this answer
1

"Unbeknownst to you, your most-feared business enemy carefully constructed an entirely new body of software, which you had no part in developing."

This body of software, operating entirely (of course) on the client side, was engineered to interact perfectly with your server-side code, which your enemy had carefully analyzed. It exactly mimicked your "client-side code," but in fact it was completely a rogue.

Your enemy, however, fully-exploited the fact that your server-side code always assumed that it was "talking to a friend." Therefore, it trusted that "friend who was not a friend," which in fact it could not identify (and never thought to do so).

Welcome to the actual Internet. *"Trust ... but verify."

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.