6 ms·

It's more efficient to do number crunching on the front end whenever possible. The only reason you would do number crunching on the back end is if the informat

It's more efficient to do number crunching on the front end whenever possible. The only reason you would do number crunching on the back end is if the information is private OR sending the low entropy information over IO is too costly OR the algorithm is to costly to run on the client side. In most apps only the first issue applies. The later two issues arise when you try to integrate your app with analytics or data science. So essentially for the most basic web app, most of the "number crunching" should live on the client side and the server is just storage.

edgyquant 6y ago
Sure but I was merely saying that the backend is more data focused (and should have worded that better) while the front end is more about displaying and interacting with that data.
IneffablePigeon 6y ago
I don't really agree those are the only reasons. We keep as much of our logic on the server as possible - partly for the reasons you state, but also because - as a team, we generally prefer working in C# to JS - there's benefit to having all your business logic in one place. It's easier to concentrate it in the back end than in the front end - minor: we can roll back our server instantly, rolling back our client requires a user page refresh
jamil7 6y ago
Not sure I agree, supporting multiple platform clients or having the ambition to support multiple clients usually means for me it's easier to do as much server side as possible.
- neonological 6y ago
  Easier to develop for but in terms of raw computation costs and speed, client side wins. If you want the maximum tradeoff for ease of development then having all of the UI rendered on the server is the ultimate solution in terms of ease of development.
  - jamil7 6y ago
    True, I responded to the wrong aspect of your original comment.
ryanbrunner 6y ago
Some other reasons to do computation / business logic on the server: - You can trust a server. Privacy is part of this, but there's other concerns as well - as an example, I would never trust a client to tell me how much an item costs on a purchase flow without double checking on the backend, because generally speaking I have less control over the front end and there's not much stopping someone from sending faulty data. - The server is a guranteed environment. You know what's on your server, what its capabilities are. If something works in your tests, it's more likely to work in production. On the client, you're dealing with different browsers, capabilities, etc. Sometimes this doesn't matter much, sometimes it does. - You can guarantee your server is always running the latest version of your code. That's generally not true on the client (or at least you need to put in a lot of effort to ensure that's the case). - The server can scale in ways that clients can't. You can add more servers, you can add background workers, etc. Some of these analogues exist on the client, but you're fundamentally performance bound if your user is on an ancient phone or something, you can hardly spin up another phone and have it do calculations in the background. - If you have different clients (mobile devices, APIs, etc.) you need to duplicate those calculations if they are being done on your client - which is a cost both in terms of duplicating the logic in the first place, and a potential avenue for issues if those calculations drift apart from each other. - Generally speaking, it's easier (but by no means trivial!) to deal with race conditions and concurrency issues if the work is being done on your server (if only because you can be aware that that work is happening).
- neonological 6y ago
  >- You can trust a server. Privacy is part of this, but there's other concerns as well - as an example, I would never trust a client to tell me how much an item costs on a purchase flow without double checking on the backend, because generally speaking I have less control over the front end and there's not much stopping someone from sending faulty data. The price of a product would go into "storage" which means it's a server side calculation. Client side calculations that don't touch storage can stay on that side. So essentially thing of it this way... If something needs IO back to the server it means it needs to go into storage so that piece of data is a backend computation. If the data does not need to be rerouted to storage, the entire computation can live on the front end. >- The server is a guranteed environment. You know what's on your server, what its capabilities are. If something works in your tests, it's more likely to work in production. On the client, you're dealing with different browsers, capabilities, etc. Sometimes this doesn't matter much, sometimes it does. For computations it doesn't matter. Incompatibility issues are usually html/css related. >- The server can scale in ways that clients can't. You can add more servers, you can add background workers, etc. Some of these analogues exist on the client, but you're fundamentally performance bound if your user is on an ancient phone or something, you can hardly spin up another phone and have it do calculations in the background. The client side can scale in ways that the server can't. That's why you need to offload as much as possible to client side. If you have 1000 connections to one server, that's 1000 computers available for compute. >- If you have different clients (mobile devices, APIs, etc.) you need to duplicate those calculations if they are being done on your client - which is a cost both in terms of duplicating the logic in the first place, and a potential avenue for issues if those calculations drift apart from each other. Client side computation costs are essentially free. These are computers being hit by thousands of connections where every piece of processing power counts. You can offload stuff to the client side that can never be put in a web app. >- Generally speaking, it's easier (but by no means trivial!) to deal with race conditions and concurrency issues if the work is being done on your server (if only because you can be aware that that work is happening). I'd say it's easier on the front end. JS gets rid of a lot of issues related to concurrency due to it's concurrency model (lockless and single threaded). Additionally, concurrency issues arise mostly from shared state and shared State is more of a back end thing. Even in most web apps concurrency issues are delegated to the database where it's mostly only deadlocks that can leak over to the web app.

edgyquant 6y ago

Sure but I was merely saying that the backend is more data focused (and should have worded that better) while the front end is more about displaying and interacting with that data.

IneffablePigeon 6y ago

I don't really agree those are the only reasons. We keep as much of our logic on the server as possible - partly for the reasons you state, but also because - as a team, we generally prefer working in C# to JS - there's benefit to having all your business logic in one place. It's easier to concentrate it in the back end than in the front end - minor: we can roll back our server instantly, rolling back our client requires a user page refresh

jamil7 6y ago

Not sure I agree, supporting multiple platform clients or having the ambition to support multiple clients usually means for me it's easier to do as much server side as possible.

neonological 6y ago
Easier to develop for but in terms of raw computation costs and speed, client side wins. If you want the maximum tradeoff for ease of development then having all of the UI rendered on the server is the ultimate solution in terms of ease of development.
- jamil7 6y ago
  True, I responded to the wrong aspect of your original comment.

ryanbrunner 6y ago

Some other reasons to do computation / business logic on the server: - You can trust a server. Privacy is part of this, but there's other concerns as well - as an example, I would never trust a client to tell me how much an item costs on a purchase flow without double checking on the backend, because generally speaking I have less control over the front end and there's not much stopping someone from sending faulty data. - The server is a guranteed environment. You know what's on your server, what its capabilities are. If something works in your tests, it's more likely to work in production. On the client, you're dealing with different browsers, capabilities, etc. Sometimes this doesn't matter much, sometimes it does. - You can guarantee your server is always running the latest version of your code. That's generally not true on the client (or at least you need to put in a lot of effort to ensure that's the case). - The server can scale in ways that clients can't. You can add more servers, you can add background workers, etc. Some of these analogues exist on the client, but you're fundamentally performance bound if your user is on an ancient phone or something, you can hardly spin up another phone and have it do calculations in the background. - If you have different clients (mobile devices, APIs, etc.) you need to duplicate those calculations if they are being done on your client - which is a cost both in terms of duplicating the logic in the first place, and a potential avenue for issues if those calculations drift apart from each other. - Generally speaking, it's easier (but by no means trivial!) to deal with race conditions and concurrency issues if the work is being done on your server (if only because you can be aware that that work is happening).

neonological 6y ago
>- You can trust a server. Privacy is part of this, but there's other concerns as well - as an example, I would never trust a client to tell me how much an item costs on a purchase flow without double checking on the backend, because generally speaking I have less control over the front end and there's not much stopping someone from sending faulty data. The price of a product would go into "storage" which means it's a server side calculation. Client side calculations that don't touch storage can stay on that side. So essentially thing of it this way... If something needs IO back to the server it means it needs to go into storage so that piece of data is a backend computation. If the data does not need to be rerouted to storage, the entire computation can live on the front end. >- The server is a guranteed environment. You know what's on your server, what its capabilities are. If something works in your tests, it's more likely to work in production. On the client, you're dealing with different browsers, capabilities, etc. Sometimes this doesn't matter much, sometimes it does. For computations it doesn't matter. Incompatibility issues are usually html/css related. >- The server can scale in ways that clients can't. You can add more servers, you can add background workers, etc. Some of these analogues exist on the client, but you're fundamentally performance bound if your user is on an ancient phone or something, you can hardly spin up another phone and have it do calculations in the background. The client side can scale in ways that the server can't. That's why you need to offload as much as possible to client side. If you have 1000 connections to one server, that's 1000 computers available for compute. >- If you have different clients (mobile devices, APIs, etc.) you need to duplicate those calculations if they are being done on your client - which is a cost both in terms of duplicating the logic in the first place, and a potential avenue for issues if those calculations drift apart from each other. Client side computation costs are essentially free. These are computers being hit by thousands of connections where every piece of processing power counts. You can offload stuff to the client side that can never be put in a web app. >- Generally speaking, it's easier (but by no means trivial!) to deal with race conditions and concurrency issues if the work is being done on your server (if only because you can be aware that that work is happening). I'd say it's easier on the front end. JS gets rid of a lot of issues related to concurrency due to it's concurrency model (lockless and single threaded). Additionally, concurrency issues arise mostly from shared state and shared State is more of a back end thing. Even in most web apps concurrency issues are delegated to the database where it's mostly only deadlocks that can leak over to the web app.