如何使用NodeJS组织构建,服务器,客户端和共享JavaScript代码

Question

我一直认为在服务器上使用NodeJS的一大好处是可能在服务器端和客户端之间共享代码(例如输入验证).现在我实际上正在使用NodeJS进行开发,我发现的一个难点是确定执行每个代码体的责任和上下文.下面我将列出一些我曾经遇到过的困难,希望能够对我可能忽略的惯例或指导有所启发,这有助于提升这些问题.

构建时间代码

以遵循基本文档的方式构建使用Gulp,Grunt或vanilla NPM的项目的时间代码通常很容易理解.大多数较小的项目倾向于将所有代码保存在单个文件中,并且文件往往被命名为传统名称,如gulpfile.js,但是对于更大的项目,我看到这些脚本开始被拆分.我已经看到一些gulp文件被拆分成多个文件并放在一个单独的目录下的情况.更糟糕的是,我发现gulpfile.js文件甚至没有这样命名的情况导致新开发人员寻找gulpfile所在的位置,一旦找到它,gulp命令总是必须运行特定的- -gulpfile选项.

运行时服务器端代码

基本节点应用程序的入口点似乎只需要在运行node命令时指出特定的JavaScript文件(例如node script.js).对于Web服务器应用程序,例如那些使用Express的应用程序,我注意到按照惯例,入口点文件通常称为server.js,通常可以在应用程序的根目录中找到.在某些其他情况下,例如在开发人员环境中运行Web服务器时,我看到gulp任务负责启动Node.在这些情况下,似乎有多种方法可以包含入口点,但我发现的一个例子就是启动webpack编译器,然后是入口点脚本的require语句.在这种类型的设置中,弄清楚如何结合关于如何完成典型节点调试命令的正常指导是非常重要的.除了应用程序的入口点之外,似乎没有关于NodeJS/Express应用程序的目录结构的任何一般指导,这些应用程序将服务器端特定代码保存在其中以帮助定位它并使其与构建时间和客户端代码.

服务器端代码既用于提供静态内容,服务器端生成的视图(例如使用MVC),也用于向客户端提供API,服务器端故事变得更加复杂.侧.我倾向于将API与应用程序项目分开,但我从其他人那里得到的感觉是,这样做有一种过于复杂的感觉,我将其视为合理的关注点分离.

运行时客户端代码

由于客户端代码通常可以根据请求的第一页具有各种入口点,因此这可能很棘手.但是,由于URL的一般透明性以及它们如何映射到典型情况下的资源,以及调试工具在现代浏览器中的强大程度,因此遵循脚本并不会太麻烦.对于典型的构建过程而言,难以替代客户端代码,这通常最终会复制文件并将它们放置在不同名称下的生产类结构中.一个例子是一个项目,它有一个名为src或js的文件夹,它保存客户端和服务器端代码混合,除了只有一部分文件碰巧包含在构建任务中,该任务转换并经常连接文件和将它们放在分发文件夹中.我见过的这些分发文件夹的常用名称是dist,public,www和wwwroot.通常,如果不总是这些目录位于项目的根目录,这至少使得它更容易定位而无需询问构建脚本.

我希望有一些一般指导如何将所有这些结合在一起,或许是一个权威的来源,主要是为那些像我一样可能想要从右脚开始的人提供指导.作为副作用或许能够引用某种标准,即使它是一个松散的标准,也可能减少团队在开始时发明和讨论的样板数量.在上面列出的每个上下文中,显然会有一些技术特定的约定,例如客户端的AngularJS,Meteor或ReactJS遵循的约定.我正在寻找的约定更具体地分离端到端JavaScript应用程序中的主要高级上下文,其中语言和平台不再是区分每种语言和平台的明显方式.

Answer 1

构建时间代码

恕我直言,如果你有这么多的构建时间代码,它不仅仅是1000行并且需要的文件数量超过少数,那么有些东西已经脱轨了.您不知道如何充分利用来自npm的现有包,或者您不了解如何重构通用代码并发布为独立的npm包.如果你觉得你需要有关项目构建时代码的指导,因为它是如此庞大和复杂,我的建议是模块化并拆分成单独的项目 - 每个项目独立发布到npm.还要检查一下整体方法.你在做什么,这是如此习惯,需要这么多机械？

运行时服务器端代码

请参阅ExpressJS的其他答案如何构建应用程序？

一般来说,我宁愿看到客户端代码和服务器端代码完全分开npm包(单独的git repos,单独的package.json文件,独立发布)(如果它们足够大)或以其他方式混合在同一模块中并分组通过耦合(所有与功能相关的代码保持在一起,包括前端和后端代码),特别是如果您的代码库有大量代码可以在两种环境中工作.

我有一个名为mjournal的开源全栈节点/ JS应用程序,它将浏览器代码和节点代码保持在一起.您可以查看一下,看看它是否符合逻辑,并且易于理解代码所在的位置.它绝不是一种流行的方法,所以很多人都不喜欢它,但对我个人感觉很好,因为我已经接受了"通过耦合"作为一般原则.

在这种类型的设置中,弄清楚如何结合关于如何完成典型节点调试命令的正常指导是非常重要的

是的,那是胡说八道.您的应用应该从npm start等等开始node server.js.详细说明让新开发人员感到困惑的gulp/grunt设置是您应该消除的不必要的复杂性.

在服务器端代码用于提供静态内容的情况下,服务器端故事变得更加复杂

根据我的经验,提供静态内容的代码可以归结为5行或更少,所以没什么大不了的.如果你有一些非微观的代码来处理静态内容,那么有些东西已经不再适用了.

运行时客户端代码

我希望有一些关于如何将所有这些结合起来的一般性指导,或许是由一个权威的来源,主要是为那些可能想要从右脚开始的人提供指导.

节点社区中有一些人采用了Ruby on Rails,EmberJS和其他一些大型项目中使用的"约定优于配置"方法.如果您喜欢这种方法,请查看使用它的工具,如SailsJS,EmberJS,Yeoman发电机等.

但总的来说,寻找"标准"并不是node.js/javascript/web社区如何滚动.小npm包.文件布局由于体积小而被迫显而易见.我感到很沮丧,因为前端工具链非常复杂,但最终还是因为浏览器中的JavaScript花了太多时间来创建一个合理的模块系统.在ES6模块是官方规范的情况下,事情可能会在未来几年内开始标准化,但是已经在CommonJS中编写了如此多的代码,而且它是可疑的前驱,如RequireJS/AMD,我们将在可预见的未来处理它们.