我正在使用brunch构建单页 Web 应用程序。该应用程序与我想使用 node.js/express 编写的后端 CRUD API 进行通信。对我来说，自然的事情似乎是在我的应用程序的子目录中构建服务器，与 app 并行。这样做的优点是可以将所有代码集中在一个屋檐下，并且允许我通过 brunch watch --server 启动一切。
我开始这样做，然后我开始担心。如果我有通过 npm install --save-dev some-server-dependency 安装的服务器端依赖项，这些依赖项是否会嵌入到我的单页应用程序的 javascript 中？这似乎会不必要地增加我的应用程序的大小。如果没有发生这种情况，brunch 如何知道 vendor.js 中包含哪些依赖项？
这导致了更普遍的问题:在与客户端代码相同的项目中开发 API 是否是一种不好的做法？如果是这样，是否有任何用于构建服务器端 API 的 brunch 等效项？
最佳答案
这是一个不错的做法，并且有 Brunch 骨架示例可以做同样的事情。您已经提到，您要将服务器端代码放在与 app 不同的目录中，因此只要该其他目录不在 brunch 配置的 paths.watched 中，那么您的后端代码就不会包含在串联的前端代码中。 You can even have shared code在客户端和服务器应用程序之间，这对于输入验证之类的事情非常有用。
在某些情况下，您最终可能希望将服务器端代码分解为单独的代码，但您所描述的方法应该使您可以轻松完成该任务(如果/当那时到来时)。
为了回答有关 Node 应用程序的 brunch 等效项的最后一个问题，有几种工具可以在您编辑其代码时自动重新启动 Node 进程，例如 nodemon , supervisor ，和node-dev 。由于 Brunch 不会为您处理这部分( future 的版本可能会添加此功能)，因此每当您主动攻击服务器端代码时，您可能需要使用这些工具之一分别运行 brunch watch 和服务器。
关于javascript - 将服务器 API 作为 brunch 应用程序的一部分构建是一种不好的做法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27119464/