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

One big benefit I've always perceived with using NodeJS on the server is the potential for sharing bits of code between the server and client side (ex. input validation). Now that I'm actually developing using NodeJS one difficulty that I've found is determining the responsibility and context in which each body of code is executed. Below I'll list a few of the difficulties I've had in hopes gain some enlightenment on conventions or guidance that I may be overlooking that could help elevate these issues.

我一直认为在服务器上使用NodeJS有一个很大的好处，那就是可以在服务器端和客户端之间共享代码(例如，输入验证)。现在我正在使用NodeJS进行开发，我发现一个困难是确定执行每段代码的职责和上下文。下面我将列举一些我所经历过的困难，希望能对我可能忽略的一些惯例或指导有所启发，这可能有助于提升这些问题。

Build-Time Code

构建时的代码

Build time code for projects that use Gulp, Grunt, or vanilla NPM in a way that follow the basic documentation are generally pretty easy to follow. Most smaller projects tend to keep all of the code within a single file and the file tends to be named a conventional name like gulpfile.js, however with bigger projects I've seen these scripts begin to be split out. I've seen some cases where the gulp file is split into multiple files and placed under a separate directory. Even worse I've found cases where the gulpfile.js file isn't even named as such causing new developers to hunt around to find where the gulpfile is located and once it is located the gulp command always has to be run with the specific --gulpfile option.

为使用Gulp、Grunt或普通的NPM(按照基本文档的方式)的项目构建时间代码通常非常容易遵循。大多数较小的项目倾向于将所有代码保留在一个文件中，而文件往往被命名为一个传统的名称，比如gulpfile。然而，在我看到的更大的项目中，这些脚本开始被拆分。我曾见过一些案例，其中gulp文件被分割成多个文件并放在一个单独的目录下。更糟糕的是，我还发现了一些关于gulpfile的案例。js文件甚至没有这样命名，这导致新开发人员到处寻找gulpfile的位置，一旦找到了gulp命令，就必须使用特定的——gulpfile选项来运行。

Run-Time Server-Side Code

运行时服务器端代码

The entry point for basic node applications appear to simply require pointing out a specific JavaScript file when running the node command (ex. node script.js). For web server applications, such as those using Express, I've noticed that by convention the entry point file is often called server.js and can usually be found in the root directory of the application. In some other cases however such as when running the web server in a developer environment I've seen gulp tasks take on the responsibility of launching Node. In these cases there seems to be multiple ways to include the entry point but one example I've found is just starting up the webpack complier followed by a require statement for the entry point script. Figuring out how to incorporate normal guidance on how to accomplish a typical node debug command is non-trivial in this type of setup. Besides the entry point of the application, there doesn't seem to be any general guidance on directory structure for NodeJS/Express applications that keeps server-side specific code in it's place to help locate it and to keep it separate from build-time and client-side code.

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

The server-side story becomes even more complex in cases where the server side code is used both for the purpose for serving up static content, server-side generated views (such as with MVC), as well as for providing an API to the client side. My preference is to separate API from the application project but I get the feeling from others that there is a sense of overcomplexity involved in doing so where I see it as a reasonable separation of concerns.

在服务器端代码用于提供静态内容、服务器端生成的视图(如MVC)以及为客户端提供API的情况下，服务器端描述变得更加复杂。我倾向于将API从应用程序项目中分离出来，但我从其他人那里得到的感觉是，这样做会产生一种过度复杂的感觉，我认为这是一种合理的关注点分离。

Run-Time Client-Side Code

运行时客户端代码

Since client-side code can often have various entry points based on the first page that is requested this can be tricky. However because of the general transparency of URLs with how they map to resources for typical cases it as well as how powerful the debugging tools have become in modern browsers, it isn't too much trouble following the follow of the scripts. The difficult instead for the client side code comes more for typical build processes which generally end up copying the files around and placing them into a production like structure under a different name. An example would be a project that has a folder called src or js that holds client-side and server-side code intermingled except for that only a portion of the files happen to be included in a build task which transforms and often concatenates the files and places them in a distribution folder. Common names of these distribution folders that I've seen are dist, public, www, and wwwroot. Often if not always these directories are at the root of the project which at least makes it a bit easier to locate without having to interrogate the build scripts.

由于客户端代码通常基于请求的第一个页面具有不同的入口点，所以这可能比较棘手。但是，由于url的一般透明性，以及它们如何映射到资源的典型情况，以及调试工具在现代浏览器中变得多么强大，遵循下面的脚本不会有太大的麻烦。相反，对于典型的构建过程来说，客户端代码更加困难，通常最终会复制文件，并将它们以不同的名称放到一个类似于产品的结构中。一个例子将是一个项目,有一个名为src文件夹或者js包含客户端和服务器端代码混合除了,只有部分文件是包含在一个构建任务通常转换和连接文件夹中的文件,并将它们分布。我看到的这些分发文件夹的常见名称有dist、public、www和wwwroot。通常情况下，这些目录是项目的根目录，这至少使查找变得更容易一些，而不必询问构建脚本。

My hope is that there is some general guidance on how to put all of this together in a sane way perhaps by an authoritative source mainly to give guidance to those like myself who may want start off on the right foot. As a side effect perhaps being able to reference some sort of standard even if it is a loose one may also reduce the amount of boilerplate a team has to invent and discuss as they get started. Within each of the contexts listed above there will obviously be some technology specific conventions such as those followed for AngularJS, Meteor, or ReactJS on the client-side. The conventions I'm looking for are more specific to separating the main highlevel contexts in end-to-end JavaScript applications where the language and platform no longer become obvious way to differentiate between each.

我的希望是，对于如何以一种理智的方式将所有这些整合在一起，我有一些一般性的指导，也许是通过权威的来源，主要是为了指导那些像我这样想要以正确的方式开始的人。作为一个副作用，也许能够引用某种标准，即使它是一个松散的标准，也可以减少团队在开始时必须发明和讨论的样板文件的数量。在上面列出的每个上下文中，显然都有一些特定于技术的约定，比如客户端上的AngularJS、流星或堆。我正在寻找的约定更具体地用于分离端到端JavaScript应用程序中的主要高层上下文，在这些应用程序中，语言和平台不再是区分它们的明显方式。

1 个解决方案

#1

Build-Time Code

构建时的代码

IMHO if you have so much build-time code that it's more than say 1000 lines and requires more than a handful of files, something has gone off the rails. Either you don't know how to make good use of existing packages from npm or you don't understand how to refactor generic code and publish as independent npm packages. If you feel like you need guidance about a project's build-time code because it is so large and complex, my suggestion is to modularize and split out into separate projects - each published independently to npm. Also just check your overall approach. What are you doing that is so custom and requires so much machinery?

IMHO如果你有这么多构建时的代码，超过1000行，需要更多的文件，有些东西就会脱轨。或者您不知道如何充分利用npm现有的包，或者您不知道如何重构通用代码并将其作为独立的npm包发布。如果您觉得您需要关于项目构建时代码的指导，因为它太大、太复杂了，我的建议是将其模块化并划分为单独的项目——每个项目都独立地发布到npm。也要检查你的整体方法。你在做什么，如此定制和需要这么多机器?

Run-Time Server Side Code

运行时服务器端代码

Please see my other answer to ExpressJS How to structure an application?

请查看我对ExpressJS的另一个回答:如何构造应用程序?

Generally I'd rather see client side code and server side code either completely separate npm packages (separate git repos, separate package.json files, published independently) (if they are large enough) or otherwise co-mingled in the same module and grouped by coupling (all the code relating to a feature kept together including front and back end code), especially if your code base has a substantial amount of code that works in both environments.

通常，我宁愿看到客户端代码和服务器端代码或者完全独立的npm包(单独的git repos，单独的包)。json文件,独立出版)(如果它们足够大)或者合在同一模块和分组的耦合(相关的所有代码功能保持在一起包括前端和后端代码),特别是如果你的代码库有大量的代码,在这两种环境中工作。

I have an open-source full-stack node/JS application called mjournal that keeps browser code and node code alongside each other. You can have a look and see if it feels logical to you and easy to understand where code lives. It is by no means a popular approach, so many folks will dislike it, but it feels good to me personally since I've embraced "group by coupling" as a general principle.

我有一个名为mjournal的开源全栈节点/JS应用程序，它可以让浏览器代码和节点代码保持在一起。您可以查看一下，看看它对您来说是否符合逻辑，并且容易理解代码位于何处。这绝不是一种受欢迎的方法，很多人会不喜欢它，但我个人感觉很好，因为我已经把“通过耦合的方式进行分组”作为一个普遍的原则。

Figuring out how to incorporate normal guidance on how to accomplish a typical node debug command is non-trivial in this type of setup

在这种类型的设置中，了解如何合并关于如何完成典型节点调试命令的常规指导是非常重要的

Yeah, that's nonsense. Your app should start with npm start or something like node server.js. Elaborate gulp/grunt setups that confuse new developers are unnecessary complexity you should just eliminate.

是的,那是胡说八道。应用程序应该以npm start或node server.js开头。使新开发人员感到困惑的精心设计的咕哝式设置是不必要的复杂性，您应该消除它。

The server-side story becomes even more complex in cases where the server side code is used both for the purpose for serving up static content

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

In my experience, the code to serve up static content boils down to 5 lines or less, so no big deal. If you have a non-microscopic amount of code dealing with serving static content, again something has gone way off the rails.

在我的经验中，提供静态内容的代码可以归结为5行或更少，所以没什么大不了的。如果您有一个非微观的代码处理服务静态内容，那么同样的事情已经偏离了rails。

Run-Time Client Side Code

运行时客户端代码

My hope is that there is that there is some general guidance on how to put all of this together in a sane way perhaps by an authoritative source mainly to give guidance to those like myself who may want start off on the right foot.

我的希望是，对于如何以一种理智的方式将所有这些整合在一起，有一些一般性的指导，也许是由一个权威人士提供的，主要是给那些像我这样想从正确的起点出发的人一些指导。

There are some people in the node community that have adopted the "convention over configuration" approach in use by Ruby on Rails, EmberJS, and some other large projects. If you like that approach, check out tools that use it like SailsJS, EmberJS, Yeoman generators, etc.

在节点社区中，有一些人在Ruby on Rails、EmberJS和其他一些大型项目中采用了“约定优于配置”的方法。如果您喜欢这种方法，请查看使用它的工具，如SailsJS、EmberJS、Yeoman generator等。

But in general, looking for a "standard" is not how the node.js/javascript/web community rolls. Small npm packages. File layouts that are forced into obviousness due to smallness. I feel your frustration here as front-end toolchains are so complex, but ultimately it's because JavaScript in the browser took too many decades to create a reasonable module system. Things may start to standardize in the next few years now that ES6 modules are an official spec, but with so much code already written in CommonJS and it's terrible precursors like RequireJS/AMD, we'll be dealing with them probably for the foreseeable future.

但一般来说，寻找“标准”并不是节点的方式。js / javascript /网络社区卷。小npm包。由于文件小而被迫变得明显的文件布局。我在这里感到您的失望，因为前端工具链是如此复杂，但归根结底，这是因为浏览器中的JavaScript花费了太多的时间来创建一个合理的模块系统。在接下来的几年里，ES6模块可能会开始标准化，因为ES6模块是一个正式的规范，但是有这么多代码已经在CommonJS中编写，而且它是像RequireJS/AMD那样的可怕的前驱体，我们将在可预见的将来与它们打交道。

1 个解决方案

#1

更多相关文章

随机推荐