7 ms·

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

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.

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.