如何使用服务器，客户端和共享代码来组织Node.js/webpack项目? [英] How to organize node,js/webpack project with server, client, and shared code?

问题描述

这似乎是一个非常普遍的情况，但是我还没有找到一个好的解决方案.我对现代Javascript还是有点陌生​​，所以如果我在这里和那里使用了错误的术语，请原谅我(或者更好的是，请纠正我).

我正在开发一个Web应用程序.它有一个服务器，它在node.js中以Javascript(ES6，我相信-使用导入/导出)运行，并使用express.js作为路由器(并由express-cli构建).它有一个客户端，也有Javascript，主要是Vue模块(由vue-cli构建).我承认我不太了解很多发出的样板构建代码express-cli和vue-cli，但是它确实有效.当我尝试找到该问题的答案时，谷歌为我找到的许多页面中都没有使用过任何框架的列表.

很明显，客户端和服务器将来回发送数据结构(各种类的实例)，我知道该怎么做.而且这些应该是相同的类定义.

我试图使webpack同时构建服务器和客户端，但是失败了，所以现在我将应用程序分为两个项目，每个项目都有自己的文件夹树，自己的package.json，自己的node_modules和我仅将webpack-dev-server用于客户端，将nodemon/babel用于服务器.第三个文件夹包含共享代码，该共享代码由客户端和服务器导入.我得到了足够好的效果以进行概念验证，但是让双方(和Visual Studio Code)认识到共享代码是它们的一部分，这确实是一个挑战，我敢肯定，我只是走错了路.

所以，我的问题是，目前认为构造和构建这种类型的客户端/服务器应用程序的最佳实践(或至少是一种良好实践)是什么?这个问题的理想答案将包括文件夹结构和足够的主要配置文件，以帮助我弄清楚如何编写我的.引用有关此主题的最新信息的可靠来源将使我感到非常满意.

我怀疑正确的答案包括将所有内容重新合并到一个项目中，并对webpack配置文件以及project.json进行一些巧妙的处理……但是到目前为止，这种聪明的作法至今仍令我难以理解.

谢谢！

解决方案

我认为，正确使用node.js(server)/vue.js(client app)文件夹是正确的2个独立的项目.

除了共享一些配置，实用程序和验证之外，应用程序和服务器通常没有什么重叠:它们通常做2件非常不同的事情，需要不同的构建工具，不同的运行时环境，有不同的安全性考虑，并且如果您考虑利用客户端代码库创建本机IOS/android ...应用程序的未来可能性，这两个代码库之间的差异只会增加.

对于我当前的项目，我具有一个文件夹结构，其中服务器位于项目根目录中，而客户端位于子文件夹/app 中.这是我如何构造Node.js/vue.js项目的简化概述:

 常量config.js(服务器环境，数据库连接，API密钥等)settings.js(业务逻辑)Price.js司机auth.jsdb-connect.jsemail.jssms.jssocket-io-server.js模型(猫鼬数据库模型)node_modules路线(快速路线)api.jsauth.js模式(用于自动验证的json模式)login-validation.jsregister-validation.js服务billing.jsvalidation.js应用程序(这是我的客户端子项目，共享一些服务器模块)公共(Webpack客户端捆绑包的输出，包括index.html)src(ES6源代码，图像，SASS/手写笔，字体等)的CSShtml(车把模板)index.hbshome.hbsaccount.hbs定价imgjsapi客户服务socket-io-client.jsstore.jsrouter.jsvuex-utils.jsdom-utils.js组件(Vue组件)Profile.vue付款方式index.js(Webpack的根目录和入口点)webpack.config.js.env.development.js.env.production.jspackage.jsonserver.js(node.js服务器根入口点) 

这绝不是说明性的.注意，我主要按功能组织了项目文件.这是指向建议围绕要素构造.

一个共享(客户端/服务器)模块文件夹具有优点和缺点.我可以看到的主要缺点是模块在开发过程中共享更改.因此，我的服务器代码库和模块位于项目根文件夹中，其中一些也由客户端应用程序导入.然后，项目根文件夹自然会托管一个共享的 package.json 和 node_modules 文件夹.

随着应用程序的发展以及获得的见识，可以根据需要进行重组(某些IDE使重构更容易).如果Visual Studio Code IDE或Webpack无法与您的文件夹结构配合使用，则可能是配置问题，或者该问题可能是由不正确的需求/导入路径引起的.IDE检查可能会帮助您发现这些错误，或者由于这些错误，您的IDE可能难以使用.

我的IDE(webstorm)和webpack v4在上面的文件夹结构或模块的位置上都没有问题(我已经以许多不同的方式重新构建了我的应用程序)，并且更加擅长于优化配置我的IDE和webpack

Webpack非常详细地描述了它的配置文件的位置，输入/输出路径，无论它是从项目根目录执行还是从/app文件夹执行，它都需要花费大量时间才能使其正常工作.但是，它将找到正确的需求/导入路径所引用的模块.这是我的webpack.config.js中设置文件输入/输出的部分.

  const sourcePath ='./src';module.exports = {入口: [sourcePath +'/js/index.js']，输出: {路径:__dirname +'/public'，//webpack输出文件的位置publicPath:'/'，//浏览器将请求Webpack文件的地址filename:'js/index.[contenthash] .js'，//输出文件名chunkFilename:'js/chunk.[contenthash] .js'//大块文件名}，...  

我已经找到了webpack.config.js，并在/app 子文件夹中执行了webpack.我的 package.json 脚本部分，用于启动node.js服务器并进行Webpack构建和构建.观看我的应用程序文件是:

 脚本":{"start":如果[$ NODE_ENV =='production'];则为node server.js；否则为nodemon server.js; fi"，"build":"cd ./app; webpack;"}， 

我可以使用以下哪个来启动节点服务器:

 >npm开始 

并让Webpack监视/重建我的捆绑包:

 >npm运行构建 

Visual Studio Code具有丰富的IntelliSense体验和一项称为自动类型获取"的功能，该功能应允许它支持您导入的模块，而无论它们位于何处.本文提供了有关为node.js配置VS Code的更多信息.>

This seems like a situation that must be incredibly common, but I've yet to find a good solution to it. I'm a little new to modern Javascript, so please forgive me (or better yet, correct me) if I'm using the wrong terminology here and there.

I'm developing a web application. It's got a server, running as Javascript (ES6, I believe - using import/export) in node.js, using express.js for a router (and built by express-cli). And it's got a client side, also Javascript, mostly Vue modules (and built by vue-cli). I admit I don't really understand a lot of the boilerplate build code express-cli and vue-cli emitted, but it does work. I am not using any of a long list of frameworks that are assumed in the many pages google found for me when I tried to find an answer to this question.

Obviously, the client and server will be sending data structures (instances of various classes) back and forth, which I know how to do. And these ought to be the same class definitions.

I made an attempt to make webpack build both server and client, and that failed, so now I've split the application into two projects, each with its own folder tree, its own package.json, its own node_modules, and I'm using just webpack-dev-server for the client and nodemon/babel for the server. A third folder contains the shared code, which is imported by the client and the server. I got this to work well enough for proof of concept, but getting both sides (and Visual Studio Code) to recognize that the shared code is part of them is turning out to be a challenge, and I'm pretty sure I'm just going down the wrong path.

So, my question is, what is currently considered the best practice (or at least, a good practice) way to structure and build a client/server application of this type? An ideal answer to this question would include both folder structure and enough of the major configuration files to help me figure out how to write mine. A reference to an up-to-date and reliable source of information on this topic would satisfy me nicely.

I suspect that the right answer includes merging everything back into a single project and doing something clever with the webpack config files and maybe project.json... but what exactly that clever thing might be has so far eluded me.

Thanks!

解决方案

In my opinion, you're right to use separate folders for your node.js(server)/vue.js(client app) as they're effectively 2 separate projects.

Apart from sharing some configs, utilities and validation, the app and server typically have little overlap: they're typically doing 2 very different things, require different build tools, different runtime environments, have different security concerns, and if you consider the future possibility of leveraging your client codebase to create a native IOS/android... app the difference between the 2 codebases will only increase.

For my current project, I have a folder structure whereby my server resides in the project root and my client is in a subfolder /app. Here's an simplified outline of how I've structured my node.js/vue.js project:

constants
  config.js (server environment, database connection, api keys etc)
  settings.js (business logic)
  pricing.js
drivers
  auth.js
  db-connect.js
  email.js
  sms.js
  socket-io-server.js
models (mongoose database models)
node_modules
routes (express routes)
  api.js
  auth.js
schema (json schema for automated validation)
  login-validation.js
  register-validation.js
services
  billing.js
  validation.js
app (this is my client sub-project sharing some server modules)
  public (the output of the webpack client bundle including index.html)
  src (ES6 source code, images, SASS/Stylus, fonts etc)
    css
    html (handlebars templates)
      index.hbs
      home.hbs
      account.hbs
      pricing.hbs
    img
    js
      api
      client-services
        socket-io-client.js
        store.js
        router.js
        vuex-utils.js
        dom-utils.js
      components  (Vue components)
        Profile.vue
        Payment.vue
      index.js  (root and entry point for webpack)
  webpack.config.js
.env.development.js
.env.production.js
package.json
server.js  (node.js server root entry point)

This is by no means prescriptive. Notice, that I've organized the project files largely by function. Here's a link to an article proposing structuring around features.

A shared (client/server) module folder has pros and cons. The main downside I can see is that module sharing changes during development. For that reason my server codebase and modules reside in the project root folder - and some are also imported by the client app. The project root folder then naturally hosts a shared package.json and node_modules folder.

As your app develops, and you gain insight, it's fine to re-structure as the need arises (some IDEs make refactoring easier than others). If the Visual Studio Code IDE or webpack are not working well with your folder structure, it may be a configuration issue or the problem may stem from incorrect require/import paths. IDE inspections may help you find those errors or your IDE may struggle to be useful because of those errors.

My IDE (webstorm) and webpack v4 have no problems with the above folder structure or the location of modules in general (I have re-structured my app in many different ways) and got more adept at optimally configuring my IDE and webpack.

Webpack is very specific about the location of it's configuration file, input/output paths, whether it is executed from the project root or /app folder and it can take a lot of time to get it working properly. Nevertheless, it will locate modules referenced by the correct require/import paths. Here's the part of my webpack.config.js that sets up file entry/output.

const sourcePath = './src';   
     
module.exports = {
  entry: [
    sourcePath + '/js/index.js'
  ],
  output: {
    path: __dirname + '/public',     //location of webpack output files
    publicPath: '/',      //address that browser will request the webpack files
    filename: 'js/index.[contenthash].js',        //output filename
    chunkFilename: 'js/chunk.[contenthash].js'      //chunk filename
  },
  ...

I've located my webpack.config.js and execute webpack inside the /app subfolder. My package.json scripts section to start the node.js server and have webpack build & watch my app files is:

 "scripts": {
    "start": "if [$NODE_ENV == 'production']; then node server.js; else nodemon server.js; fi",
    "build": "cd ./app; webpack;"
  },

Which allows me to start the node server with:

> npm start 

and have webpack watch/re-build my bundle with:

> npm run build

Visual Studio Code has a rich IntelliSense experience and a feature called Automatic Type Acquisition which should allow it to support modules you import regardless of their location. This article provides more information on configuring VS Code for node.js.

这篇关于如何使用服务器，客户端和共享代码来组织Node.js/webpack项目?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！