Warning: file_get_contents(/data/phpspider/zhask/data//catemap/3/reactjs/23.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Express 在开发中使用WebpackDevServer作为后端有哪些缺点?_Express_Reactjs_Webpack_Webpack Dev Server - Fatal编程技术网

Express 在开发中使用WebpackDevServer作为后端有哪些缺点?

Express 在开发中使用WebpackDevServer作为后端有哪些缺点?,express,reactjs,webpack,webpack-dev-server,Express,Reactjs,Webpack,Webpack Dev Server,报告说: webpack dev服务器是一个小型node.js Express服务器,它使用webpack dev中间件为webpack包提供服务 我可以毫无困难地使用这个已经创建的服务器来为开发中的API后端服务,事实上一些样板文件使用这种方法 但随后,报告说: 您可能希望在开发中运行后端服务器或对其进行模拟。您不应将webpack dev服务器用作后端。它的唯一用途是为静态(网页包)资产服务 为什么会这样? 为什么我不能在开发中仅将webpack dev server用作后端 有什么特别的原

报告说:

webpack dev服务器是一个小型node.js Express服务器,它使用webpack dev中间件为webpack包提供服务


我可以毫无困难地使用这个已经创建的服务器来为开发中的API后端服务,事实上一些样板文件使用这种方法

但随后,报告说:

您可能希望在开发中运行后端服务器或对其进行模拟。您不应将webpack dev服务器用作后端。它的唯一用途是为静态(网页包)资产服务

为什么会这样?
为什么我不能在开发中仅将webpack dev server用作后端 有什么特别的原因吗

在上下文中,我使用API的Express后端进行React开发。

在本文中,“后端”指的是API端点和动态处理之类的东西。正如你自己提到的:

它的唯一用途是为静态(网页包)资产服务

这意味着它不能做诸如与数据存储或其他动态处理之类的事情,而这正是你的应用程序可能需要的。如果您所做的只是开发不需要与API对话的前端组件(即“后端”),那么
webpack dev server
就足够了

请注意,还有其他解决方案,例如使用
webpack dev server
为静态html/css/js文件提供服务,以及在另一个端口上运行单独的后端。这是非常有效的,但许多人发现必须指定绝对URL很不方便,因为您必须在每个API调用之前加上
localhost:[port]/endpoint
,而不仅仅是
/endpoint

*编辑*

没有技术上的理由你不能这么做。对于你实际提出的“缺点是什么”的问题,我能给出的唯一答案是:它不是预期用途,如果以另一种方式使用,作者很可能不会支持或提供帮助

归根结底,这都是JS,你几乎可以随心所欲。

在这里,“后端”指的是API端点和动态处理之类的东西。正如你自己提到的:

它的唯一用途是为静态(网页包)资产服务

这意味着它不能做诸如与数据存储或其他动态处理之类的事情,而这正是你的应用程序可能需要的。如果您所做的只是开发不需要与API对话的前端组件(即“后端”),那么
webpack dev server
就足够了

请注意,还有其他解决方案,例如使用
webpack dev server
为静态html/css/js文件提供服务,以及在另一个端口上运行单独的后端。这是非常有效的,但许多人发现必须指定绝对URL很不方便,因为您必须在每个API调用之前加上
localhost:[port]/endpoint
,而不仅仅是
/endpoint

*编辑*

没有技术上的理由你不能这么做。对于你实际提出的“缺点是什么”的问题,我能给出的唯一答案是:它不是预期用途,如果以另一种方式使用,作者很可能不会支持或提供帮助


最终,这一切都是JS,你几乎可以随心所欲。

“我可以毫无困难地使用这个已经创建的服务器来服务我的API后端”。“它不能做诸如与数据存储或其他动态处理的事情”——它只是一个express服务器,您当然可以为您的api添加更多的处理程序。@rossipedia查看样板文件。在开发模式下,他创建了一个
网页包开发服务器
来与后端API进行对话(参见路由器,在那里你可以进行动态处理)好的,也许“不能”应该替换为“不应该”。在JS中,你几乎可以做任何你想做的事情,但我的观点是,
webpack dev server
的预期用途是专门为webpack生成的文件提供服务,而不是作为后端的基础,虽然我个人会将
webpack开发中间件
webpack热中间件
集成。但这是我个人的偏好。“好吧,也许“不能”应该换成“不应该”。——这就是问题的关键所在。问题是:避免这种情况的技术原因是什么。我们都可能喜欢某些东西,也可能不喜欢其他东西,但作为工程师,我们必须受到理性原因的驱使。你的回答没有透露任何这些,“我可以毫无困难地使用这个已经创建的服务器来服务我的API后端”。“它不能做诸如与数据存储或其他动态处理的事情”——它只是一个express服务器,您当然可以为您的api添加更多的处理程序。@rossipedia查看样板文件。在开发模式下,他创建了一个
网页包开发服务器
来与后端API进行对话(参见路由器,在那里你可以进行动态处理)好的,也许“不能”应该替换为“不应该”。在JS中,你几乎可以做任何你想做的事情,但我的观点是,
webpack dev server
的预期用途是专门为webpack生成的文件提供服务,而不是作为后端的基础,虽然我个人会将
webpack开发中间件
webpack热中间件
集成。但这是我个人的偏好。“好吧,也许“不能”应该换成“不应该”。——这就是问题的关键所在。问题是:避免这种情况的技术原因是什么。我们都可能喜欢某些东西,也可能不喜欢其他东西,但作为工程师,我们必须受到理性原因的驱使。你的回答没有透露任何这些。