Most of these problems stems from moving too much to frontend, making the frontend tilt over. If you keep more logic in the backend much of these problems goes

Most of these problems stems from moving too much to frontend, making the frontend tilt over. If you keep more logic in the backend much of these problems goes away. Problem is that for every core concept moved to the frontend it still needs to exist in the backend, a representation of an article needs to exist both in the frontend and the backend, same for error handling, logging, authentication etc, but they are rarely identical, even if you would code them in the same language, because the frontend will always be a remote representation of what the backends implements. Thus the more you move the more you need to duplicate. Some views or components needs to be more interactive, true, but not every view, thus you solve the interactive part of those specific views or components in pragmatic way to minimize friction. One pragmatic solution is to use BFF, backend for frontends, where you have a specific API, both for reading and writing, for that component or view only. Now you can adapt those together to a better fit, including error handling. General and reusable (REST) APIs for driving a frontend is a bad idea, you should have specific APIs for each case, otherwise you end up doing asynchronous JOINS over HTTP. The next step to realize after that is that if you already have specific APIs for a components you can skip passing JSON all together and just return HTML, thus saving an entire JSON encode/decode roundtrip. JSON schema is trash btw, schemas does not fit JSON data well, structured data is better handled by something like XML. And what this shows is that using JSON for large data representation is a bad idea, but it is usually where you end up when doing heavy frontend.