Perspective

Rub your eyes and look at what you are discussing: a WebApp and a Server that communicate across a network.

That is literally two separate applications with a network interface.

In fact you have just reinvented the Thick client. Just instead of installing it on Windows, and compiling it from C++ you are writing it in JavaScript and installing it in a browser tab.

What this means is that each application (the thick client, and the api server) both have need of a business logic layer.

Now if your server is written in javascript. You might be able to share some of that business logic. But you probably don't want to. The business concerns of the backend are different to those of the front end, so aside from the data objects for communications, or some of the more general utilities their probably isn't much worth sharing. Sharing introduces its own headaches, as both applications will want to head in their own directions.

Domain Logic

There is a balance between what can be done by the client and what can be done by the server.

• When its all in the server, the client is called a thin-client.
• When its all in the client, the client is just called an application, with maybe some networked services available
• When its balanced, the client is called a thick client.

If you are going for a thin client, the absolute minimum required information for presentation is given to the client a video stream would be ideal, and the raw inputs are passed back to the server.

If you are going for a complete local experience, then everything goes in the client. Only those things which cannot be done locally be that for secrecy, or some form shared service are kept in the server. Even better if the server isn't even responsible for distributing the client.

If you are going for a thick client, its a matter of taste and circumstance.

• At the very least the client needs the logic for handling the UI. Which includes responding to input, formatting, and layout.
• At the very least the server has to have the Secret/compute intensive/server storage features.
• Every other feature has to be traded off on whether it makes more sense in the client, or in the server.

A good way to figure this out is to pick a range of client devices. How much ram, cpu, etc resource they have available. Everything from the smallest device you will support up to the beefiest device you expect a client to have.

• Everything that can be put on a client, and fits in the smallest device belongs in the client.
• Everything that can be put in a client, and can be handled by the powerful device easily, and by the least powerful device but just takes longer, has a compelling argument for being in the client.
• Everything that can be put in the client, and can only be handled by the more powerful devices has an argument for going into a pro version, or staying on the server (maybe both).
• Everything else, even if it can go in the client is obviously to taxing/secret/impossible for the clients device. It has to stay in the server.