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?

  • 2
    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 '14 at 0:52

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.
  • 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 '13 at 10:52
  • 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 '19 at 13:45

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?"...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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