系统在此应用程序堆栈溢出_部署第一个完整堆栈应用程序之前需要考虑的三件事...

系统在此应用程序堆栈溢出

Building a full stack app is no small endeavor, and deploying it comes with its own host of things to consider.

构建一个全栈应用程序并不是一件容易的事，而部署它本身也要考虑很多事情。

I'm a tabletop game developer, and recently deployed a simple roleplaying game tracker that uses the M-E-V-N stack (you can follow my tutorial to create your own app here).  

我是一名桌面游戏开发人员，最近部署了一个使用M - E - V - N堆栈的简单角色扮演游戏跟踪器 (您可以按照我的教程在此处创建自己的应用程序)。

In deploying the app, I came across three key takeaways that may be useful as you begin considering the best way to bring your projects from development to production.

在部署该应用程序时，我遇到了三个关键问题，在您开始考虑将项目从开发到生产的最佳方法时，这可能会很有用。

You can check out the code to my app on GitHub, and I should mention that it includes Chad Carteret's very cool CSS statblock in prettifying what's otherwise very basic HTML.

您可以在GitHub上查看我的应用程序中的代码，并且我应该提到，它在美化其他非常基本HTML时包括了Chad Carteret的非常酷CSS statblock 。

If you're thinking of following the same path to deployment as I have here, be sure to check out the official documentation on Heroku, the Vue CLI, and this tutorial by Nick Manning.

如果您想按照与我此处相同的方式进行部署，请确保查看有关Heroku ， Vue CLI和Nick Manning撰写的本教程的官方文档。

You'll also want to take a look at Will Abramson's article on a similar topic.

您还将想看看Will Abramson 在类似主题上的文章 。

On to deployment!

即将部署！

您的前端和后端可以部署在一起，也可以分别部署，具体取决于应用程序的复杂性。 (Your front end and back end can be deployed together or separately, depending on your app's complexity.)

One snag that seems to appear immediately when considering production is the structural question of how to deploy the front and back ends of your app.

在考虑生产时，似乎会立即出现的一个障碍是如何部署应用程序的前端和后端的结构性问题。

Should the client (or static files) live in the same place as the server and database? Or should they be separate, with the front end making HTTP requests from elsewhere to the back end using CORS?

客户端(或静态文件)是否应该与服务器和数据库位于同一位置？ 还是应该将它们分开，前端使用CORS从其他地方向后端发出HTTP请求？

The answer is yes! Or no. Maybe??

答案是肯定的！ 或没有。 也许？？

For better or worse, there's no one-size-fits-all solution to this question, as it will likely depend on your app's architecture and complexity. In the roleplaying game tracker that I linked to above, I have the whole stack running on a single Heroku dyno, with the following folder structure:

不管是好是坏，这个问题没有一个万能的解决方案，因为这很可能取决于您应用程序的体系结构和复杂性。 在上面链接到的角色扮演游戏跟踪器中，我将整个堆栈运行在单个Heroku dyno上 ，具有以下文件夹结构：

All of the front and back end files live in the same place, with the Vue client built for production in a folder located at /client/dist.

所有前端文件和后端文件都位于同一位置，而Vue客户端是为生产而构建的，位于/ client / dist的文件夹中。

In server.js, along with a bunch of database and routing code, there's a little line that says:

在server.js中，以及一堆数据库和路由代码，其中有一小行表示：

server.use(serveStatic(__dirname + "/client/dist"));

In Express, this tells the app to serve my static client files from a particular folder, and enables me to run the front and back ends all within the same environment. If you're deploying a similarly simple app, this type of solution might work for you as well.  

在Express中，这告诉应用程序从特定文件夹提供我的静态客户端文件，并使我可以在同一环境中运行前端和后端。 如果您要部署类似的简单应用程序，则这种解决方案也可能适用。

Conversely, and depending on your project's complexity, you may have to separate the front and back ends and treat them as separate applications, which is no big deal. In the app above, my client is making calls to static API endpoints that are handled by the server, like this:

相反，根据项目的复杂性，您可能必须将前端和后端分开并将它们视为单独的应用程序，这没什么大不了的。 在上面的应用程序中，我的客户端正在调用由服务器处理的静态API端点，如下所示：

getQuests: function () {
    axios
        .get('https://mevn-rpg-app.herokuapp.com/quests')
        .then(response => (this.questData = response.data))                   
 }

Technically, my client could be making those requests from anywhere - even a static GitHub Pages site. This type of solution can help separate your app into two distinct entities to tackle, which is sometimes better than trying to cram the whole project into one location.

从技术上讲，我的客户可以从任何地方(甚至是静态GitHub Pages站点)发出这些请求。 这种类型的解决方案可以帮助将您的应用分为两个不同的实体来处理，这有时比将整个项目塞入一个位置要好。

One note: if you're going to be making cross-origin HTTP requests - that is, requests from a client that lives on a separate domain from the API or server - you'll need to become familiar with CORS.  You can read more about it in this article.  

一个注意事项：如果要进行跨域HTTP请求(即，来自与API或服务器位于不同域的客户端的请求)，则需要熟悉CORS 。 您可以在本文中阅读有关它的更多信息。

您的代码将需要更改以支持生产环境。 (Your code will need to change to support a production environment.)

When you're knee deep in the development process, it can be easy to lose track of how much of your code depends on local files or other data.

当您全神贯注于开发过程时，很容易忘记多少代码依赖于本地文件或其他数据。

Consider the following in a locally-running server.js:

在本地运行的server.js中考虑以下内容：

server.listen(3000, () => console.log("Server started!"));

On a local machine, the code just asks the server to listen on port 3000 and log to the console that we're ready for liftoff.

在本地计算机上，该代码仅要求服务器侦听端口3000并登录到我们已准备好提起的控制台。

In a production environment, the server has no concept of where the "localhost" should be, or to whose port 3000 it should be listening. With this example, you'd have to change your code to something like:

在生产环境中，服务器不知道“本地主机”应位于何处，或应侦听其端口3000。 在此示例中，您必须将代码更改为以下内容：

const port = process.env.PORT || 3000;

server.listen(port, () => console.log("Server started!"));

The above instructs the server to instead listen at port 3000 of the process that's currently running, wherever that might be (check out this article for further reading on this topic).

上面的内容指示服务器改为侦听当前正在运行的进程的端口3000，无论该端口位于何处(请查看本文以进一步了解此主题)。

Similarly, in my app, I have several modules that need to be imported by one another to function:

同样，在我的应用中，我有几个模块需要相互导入才能起作用：

In /routes/Quests.js, for example, I have a router that tells the server what to do when receiving API requests to interact with quest-related items in the database. The router needs to import a Mongoose schema from /models/quest.js to function properly. If the application were running locally, we could just say:

例如，在/routes/Quests.js中，我有一个路由器，它告诉服务器在接收API请求以与数据库中与任务相关的项目进行交互时该怎么做。 路由器需要从/models/quest.js导入Mongoose模式才能正常运行。 如果应用程序在本地运行，我们可以说：

const Quest = require('../models/quest');

Pretty simple! Yet, unfortunately, our server won't know where to find the root directory of our project once deployed. In Express, we'd change our code to something like:

很简单！ 但是，不幸的是，一旦部署，我们的服务器将不知道在哪里可以找到我们项目的根目录。 在Express中，我们将代码更改为：

const path = require('path');
const Quest = require(path.join(__dirname, '../models/quest'));

Your particular case might be different, depending on your language and framework(s), but you'll need to get specific about what your code looks like in a production environment rather than in your local development environment.

具体情况可能会有所不同，具体取决于您的语言和框架，但是您需要具体说明代码在生产环境中(而不是在本地开发环境中)的外观。

Additionally, you're probably already familiar with whatever bundler you're using for your front end (e.g., webpack), and will want to build your client for production to optimize it for deployment.

另外，您可能已经熟悉用于前端的任何捆绑程序(例如webpack )，并且将希望构建用于生产的客户端以对其进行优化以进行部署。

您可以从多种部署平台中进行选择。 (You have a multitude of deployment platforms from which to choose.)

If you've deployed a front end website or some other type of static app, you might be familiar with just pushing your files to some remote repository and calling it a day.

如果您已经部署了前端网站或某种其他类型的静态应用程序，则可能会熟悉将文件推送到某个远程存储库并每天调用它。

Deploying a full stack app (or even just a back end) is eminently more complex. You'll need a dedicated server, or something that emulates one, to respond to the HTTP requests that it will be receiving and work with an online database.

部署全栈应用程序(甚至只是后端)显然更加复杂。 您将需要一台专用服务器或类似的服务器，以响应将要接收并使用在线数据库的HTTP请求。

There are a number of services that will do this very thing for you, and the spectrum ranges based on price, scalability, complexity, and other factors.

有很多服务将为您完成此任务，频谱范围取决于价格，可伸缩性，复杂性和其他因素。

There's a bunch of articles out there that compare PaaS options for deployment, but here are some thoughts as you consider platforms for your first project:

有很多文章比较了PaaS部署选项，但是在考虑第一个项目的平台时，有一些想法：

• Heroku: If you have a small project like mine or just want to learn about deployment, a good first step could be Heroku.

  Heroku ：如果您有一个像我这样的小项目，或者只是想学习部署，那么最好的第一步就是Heroku 。

• AWS, Docker, and Kubernetes: If you're seeking a career in full stack web development or DevOps, now's a good time to familiarize yourself with Amazon Web Services and/or container platforms like Docker and Kubernetes.

  AWS，Docker和Kubernetes ：如果您正在寻找从事全栈Web开发或DevOps的职业，那么现在是您熟悉Amazon Web Services和/或Docker和Kubernetes等容器平台的好时机 。

• Azure: If you're a C# or .NET developer, Azure appears to be a seamless way to deploy your apps without having to leave the safety of the Microsoft ecosystem.

  Azure ：如果您是C＃或.NET开发人员，则Azure似乎是一种无缝部署应用程序的方式，而不必离开Microsoft生态系统的安全性。

There are, of course, several other options out there, and your particular use-case scenario might depend on pricing or the specific feature sets that are on offer.

当然，还有其他几种选择，您的特定用例场景可能取决于定价或所提供的特定功能集。

Additionally, you'll want to consider any addons that will be necessary to replicate your app's functionality in a production environment. My roleplaying game tracker, for example, uses MongoDB, but the production version certainly can't use the little database on my local machine! Instead, I've used the mLab Heroku addon to get the live site up and running with the same functionality as in my development environment.

此外，您将需要考虑在生产环境中复制应用程序功能所必需的任何附加组件。 例如，我的角色扮演游戏跟踪器使用MongoDB，但是正式版肯定不能使用本地计算机上的小数据库！ 取而代之的是，我使用mLab Heroku插件来启动实时站点并以与开发环境中相同的功能运行该站点。

Your app's success, as well as your own progress as a full stack web developer, depend on your ability to consider deployment options and create a successful pipeline for production. With a little research, I'm certain that you can find the best solution that fits all of your app's needs.

应用程序的成功以及您作为全栈Web开发人员的进步，取决于您考虑部署选项并创建成功的生产渠道的能力。 经过一点研究，我相信您可以找到满足您所有应用程序需求的最佳解决方案。

Happy coding!

祝您编码愉快！

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

如果您喜欢这篇文章，请考虑查看我的游戏和书籍 ， 订阅我的YouTube频道或加入Entromancy Discord 。

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.

法赞(MS Farzan)博士 曾为知名的视频游戏公司和编辑网站(例如，Electronic Arts，Perfect World Entertainment，Modus Games和MMORPG.com)撰写和工作，并曾担任《龙与地下城：龙骨无双》和《 质量效应：仙女座》等游戏的社区经理。 他是《 Entronancy：Cyber​​punk Fantasy RPG》的创意总监和首席游戏设计师，并且是《 The Nightpath Trilogy》的作者。 在Twitter @sominator上找到MS Farzan 。

翻译自: https://www.freecodecamp.org/news/3-things-to-consider-before-deploying-your-first-full-stack-app/

系统在此应用程序堆栈溢出