有时，当我创建基本的 Web 工具时，我会从 NodeJS 后端开始，通常使用 ExpressJS 创建 API 服务器。当命中某些路由时，服务器会使用连接的实时状态从 EJS 渲染 HTML 来进行响应，然后将其发送到浏览器。
此应用程序通常会公开公共静态资源的目录，并为这些资源提供服务。我想这会给这种形式的网络应用程序带来很大的开销，但我不确定。
其他时候我会从 API 开始（可能是完全相同的 NodeJS 结构，没有 HTML 渲染，只有状态管理和 API 暴露），我将构建一个 Angular2 或其他 HTML 网页来连接到 API，加载在加载信息中，并填充页面中的数据。
这些页面往往依赖大量 AJAX 调用和 jQuery，以便在触发一堆异步回调后刷新角度组件。在这个结构中，我将使用像 Apache 这样的 Web 服务器来提供所有文件并定义路由，而网页中的 JS 将完成其余的工作。
两者的整体优势和劣势是什么？为什么我应该使用一种策略而不是另一种策略？它们是否可行且取决于规模和用途？我想负载均衡器的水平扩展在这两种情况下都可以工作。
没有什么好或坏的方法可供选择。您上面描述的每种方法都有一些优点，您需要决定哪一种最适合您的项目。
您可能会考虑的一些要点：
服务器端处理
安全性 - 您不必公开敏感信息（API 令牌、登录名等）。
更多控制 - 您将更好地控制如何使用资源
“更好”的客户端支持 - 某些客户端 (IE) 不支持与其他客户端相同的功能。在服务器上渲染 HTML 而不是在客户端操作它将为您提供对客户端的更多支持。
在服务器上预渲染资源比在客户端处理异步方法更简单。
SEO、社交共享等 - 您的服务器如何发送资源，这就是机器人如何看待它们。如果您在服务器上预渲染所有内容，机器人将能够抓取您的网站、对其进行标记等。如果您在客户端上执行此操作，它只会看到未处理的页面。话虽如此，有一些方法可以解决这个问题。
客户端处理
等待时间。在客户端做一些事情会缩短你的加载时间。但要注意不要做太多事情，因为 JS 是单线程的，重的东西会阻塞你的 UI。
CDN - 您可以从 CDN 提供静态资源（HTML、CSS、JS 等），这比直接从服务器应用程序提供静态资源要快得多
测试 - 在测试 UI 时很容易模拟后端服务器。
客户端是特定应用程序/设备等的前端。您在客户端中放入的逻辑越多，您需要在不同客户端之间复制的代码就越多。因此，如果您计划拥有移动应用程序，最好有一组可供调用的 API，而不是将您的逻辑包含在客户端中。
安全性 - 客户端上运行的任何内容都可以被客户端完全读取。无论你如何缩小、压缩、加密所有内容，足智多谋的人总是能够对你的代码做任何他们想做的事。
我没有故意在每一点上标记赞成/反对，因为这取决于你来决定哪一个。
这个列表可以一直列下去，我不想考虑更多的点，因为它非常主观，最终取决于开发者和应用程序。
我个人倾向于选择“客户端发出ajax请求”方法或两者的混合——在服务器上预渲染一些东西，客户端负责休息。但要小心后者，因为如果实施不正确，它会破坏你的自动化测试、IDE 集成等。
最后一点 - 您应该始终在服务器上进行关键验证。永远不要依赖客户的数据。