Merge pull request #174 from YukiOta/5-11-japanese-trans

translate 5-11 to japanese
This commit is contained in:
Yuta Azumi
2020-11-28 19:11:57 +09:00
committed by GitHub
2 changed files with 17 additions and 17 deletions

View File

@ -655,13 +655,13 @@ null == undefined; // true
<br/><br/>
## ![✔] 5.11. Get your frontend assets out of Node
## ![✔] 5.11. フロントエンドの資産を Node から取り出す
**TL;DR:** Serve frontend content using dedicated middleware (nginx, S3, CDN) because Node performance really gets hurt when dealing with many static files due to its single-threaded model
**TL;DR:** 専用のミドルウェア (nginx, S3, CDN) を使用してフロントエンドのコンテンツを提供します。なぜなら、シングルスレッドモデルのため、多くの静的ファイルを扱う場合、Node のパフォーマンスは非常に痛手を受けるからです。
**Otherwise:** Your single Node thread will be busy streaming hundreds of html/images/angular/react files instead of allocating all its resources for the task it was born for serving dynamic content
**さもないと:** あなたの Node のシングルスレッドは、何百もの html/images/angular/react ファイルのストリーミングに忙殺され、本来の目的のために生まれたタスクにすべてのリソースを確保することができません。– 動的コンテンツの提供
🔗 [**Read More: Get your frontend assets out of Node**](/sections/production/frontendout.md)
🔗 [**さらに読む: フロントエンドの資産を Node から取り出す**](/sections/production/frontendout.japanese.md)
<br/><br/>

View File

@ -1,32 +1,32 @@
# Get your frontend assets out of Node
# フロントエンドの資産を Node から取り出す
<br/><br/>
### One Paragraph Explainer
### 一段落説明
In a classic web app the backend serves the frontend/graphics to the browser, a very common approach in the Nodes world is to use Express static middleware for streamlining static files to the client. BUT Node is not a typical webapp as it utilizes a single thread that is not optimized to serve many files at once. Instead, consider using a reverse proxy (e.g. nginx, HAProxy), cloud storage or CDN (e.g. AWS S3, Azure Blob Storage, etc) that utilizes many optimizations for this task and gain much better throughput. For example, specialized middleware like nginx embodies direct hooks between the file system and the network card and uses a multi-threaded approach to minimize intervention among multiple requests.
古典的なウェブアプリケーションでは、バックエンドはフロントエンドやグラフィックをブラウザに提供します。Node の世界で非常に一般的なアプローチは、クライアントへの静的ファイルのストリーム化のために Express の静的ミドルウェアを使用することです。しかし Node は、一度に多くのファイルを提供するために最適化されていないシングルスレッドを利用しているため、典型的なウェブアプリではありません。代わりに、リバースプロキシnginx、HAProxyなど、クラウドストレージや CDNAWS S3Azure Blob Storage などを使用して、このタスクのために多くの最適化を利用し、はるかに優れたスループットを得ることを検討してください。例えば、nginx のような特殊なミドルウェアは、ファイルシステムとネットワークカード間のダイレクトフックを具現化し、複数のリクエスト間の介入を最小限に抑えるためにマルチスレッドアプローチを使用しています。
Your optimal solution might wear one of the following forms:
最適なソリューションは、以下のフォームのいずれかに従っている可能性があります:
1. Using a reverse proxy your static files will be located right next to your Node application, only requests to the static files folder will be served by a proxy that sits in front of your Node app such as nginx. Using this approach, your Node app is responsible deploying the static files but not to serve them. Your frontends colleague will love this approach as it prevents cross-origin-requests from the frontend.
1. リバースプロキシの使用 静的ファイルは Node アプリケーションのすぐ隣に配置され、静的ファイルフォルダへのリクエストだけが nginx のような Node アプリケーションの前にあるプロキシによって提供されます。このアプローチを使用すると、Node アプリは静的ファイルをデプロイする責任がありますが、それらを提供する責任はありません。フロントエンドからのクロスオリジンリクエストを防ぐことができるので、フロントエンドの同僚はこのアプローチを気に入るでしょう。
2. Cloud storage your static files will NOT be part of your Node app content, they will be uploaded to services like AWS S3, Azure BlobStorage, or other similar services that were born for this mission. Using this approach, your Node app is not responsible deploying the static files neither to serve them, hence a complete decoupling is drawn between Node and the Frontend which is anyway handled by different teams.
2. クラウドストレージ 静的ファイルは Node アプリのコンテンツの一部ではなく、AWS S3Azure BlobStorage、またはこのミッションのために生まれた他の類似のサービスにアップロードされます。このアプローチを使用すると、Node アプリは静的ファイルをデプロイする責任がなく、静的ファイルを提供する責任もありません。そのため、Node とフロントエンドの間は完全に分離され、異なるチームによって処理されます。
<br/><br/>
### Configuration example: typical nginx configuration for serving static files
### 設定例: 静的ファイルを提供するための典型的な nginx の設定
```nginx
# configure gzip compression
# gzip 圧縮を設定する
gzip on;
keepalive 64;
# defining web server
# ウェブサーバを定義する
server {
listen 80;
listen 443 ssl;
# handle static content
# 静的コンテンツを扱う
location ~ ^/(images/|img/|javascript/|js/|css/|stylesheets/|flash/|media/|static/|robots.txt|humans.txt|favicon.ico) {
root /usr/local/silly_face_society/node/public;
access_log off;
@ -36,10 +36,10 @@ expires max;
<br/><br/>
### What Other Bloggers Say
### 他のブロガーが言っていること
From the blog [StrongLoop](https://strongloop.com/strongblog/best-practices-for-express-in-production-part-two-performance-and-reliability/):
ブログ [StrongLoop](https://strongloop.com/strongblog/best-practices-for-express-in-production-part-two-performance-and-reliability/) より:
>…In development, you can use [res.sendFile()](http://expressjs.com/4x/api.html#res.sendFile) to serve static files. But dont do this in production, because this function has to read from the file system for every file request, so it will encounter significant latency and affect the overall performance of the app. Note that res.sendFile() is not implemented with the sendfile system call, which would make it far more efficient. Instead, use serve-static middleware (or something equivalent), that is optimized for serving files for Express apps. An even better option is to use a reverse proxy to serve static files; see Use a reverse proxy for more information
>…開発では、[res.sendFile()](http://expressjs.com/4x/api.html#res.sendFile) を使用して静的ファイルを提供することができます。この関数はファイル要求ごとにファイルシステムから読み込まなければならず、大幅な待ち時間が発生し、アプリの全体的なパフォーマンスに影響を与えることになるため、本番環境では行わないでください。res.sendFile() は、より効率的になる sendfile システムコールでは実装されていないことに注意してください。代わりに、Express アプリ用にファイルを提供するために最適化された serve-static ミドルウェア (または同等のもの) を使用してください。さらに良い方法は、静的ファイルを提供するリバースプロキシを使うことです。; 詳細については、リバースプロキシの使用を参照してください。
<br/><br/>