Node.jsのは、ジャバスクリプト言語を使用して書かれたサーバアプリケーションですノンブロッキング、高いI / Oの利点があります。私は、フロントエンドの開発プロジェクトの多くは、この説明は熱心に表示されます信じています。最後に、私は、世界と戦う舞台裏を開発するプログラマはちょうどコーナーああ（C> C ++>のJava / .NET>フロントエンド）の周りにチェーン理論を軽蔑打倒する機会がありました。
しかし、実際には、Node.jsのは、10年を経ている、というように、サーバアプリケーションの波の多くをオフに設定するのではなく、アプリケーションのより広い態様のパッケージ管理ツールでは、そのようなNPMの倉庫として、WebPACKのとしませんでした。だからあなたのチームは、バックエンド・テクノロジー・スタックを持っていない限り、Node.jsのであるか、あるいはまだでいくつかの努力を要するNode.jsのサーバーを使用するように企業を説得するために。
私は、同社がすでにいくつかの経験を蓄積しNode.jsの革新的なプロジェクトを使用して、会社の一部を想定し、分離の終了前後に行うために、代替JSPの使用のNode.jsで始まる、二年以上持っているのNode.jsを使用しています。次に、この記事では、使用Node.jsの記述が直面している課題を納得させるのだろうか？指導者はNode.jsのを受け入れるように識別して足場にする方法？任意のコメントを歓迎コメントやアイデアを議論してきました。
この記事は19/06/14で書かれていました。たぶん将来的にはNode.jsのない困難なものを使用して説得し、適用されない、本明細書には説明します。
なぜあなたはとても難しいのNode.jsでサービスをしたいです
ほとんどの企業では、バックグラウンドサービスは基本的にJava（登録商標）、C ++や他の言語によって支配されています。だから、主として次のように、困難に直面しているNode.jsのサービスを使用したいです。
1.成熟したバックグラウンドシステム
Javaへ、例えば、開発およびオンライン検証、かなり完璧な生態のjavaの長い期間の後。使用例に人気のマイクロサービスシステムの現在のコンテキストでは、Javaなどのマイクロサービスのさまざまなソリューションが生まれている、のようなSpring Cloudシステムには、ソリューションのセットを構築することができます。そして、この中ではまだ初期段階にNode.jsの。幸いなことに、そのような解決策は、アクセスソリューションの基本的な標準を提供し、Node.jsのおよびその他の非Java言語のシステムがアクセスすることができます。しかし、このようなアクセスjavaは、関連するSDKを提供し、より高いアクセスの障壁は、唯一の関連の設定ファイルを記述する必要が、Node.jsのは、コードの実装を記述する必要があります。
また、運転コストとメンテナンスコストを削減するために中小企業は、一般的にだけで解決するのシニアエンジニアを見つけることが容易に問題のトラブルシューティングおよび解決するため、Javaシステムの下で、1つの言語の背景を受けます。
フロントエンド技術リテラシー担当者の2不足
背景の開発は高いアルゴリズムの能力、データ・インタフェース、デザインパターン、ロジック解析、およびより厳しいが必要です。伝統的な意味でのフロントエンドの開発は、ユーザーだけがそれを担当して、私たちは聞いたことがあると信じてDon't let me thinkこの文を。フロントエンドユーザエクスペリエンスのための責任、感情的になる傾向があります。これを行うには、あなたはまた、良好なフロントエンドの開発エンジニアになることができます。あなたは何かがサーバ側でアプリケーションをNode.jsのしたい場合でも、関連する技術的能力が記入されるが、幸いあなたは周りの多くのショッピングを学び、技術フォーラムダニエルにこれを補償することができます。
次の3環境のためのステレオタイプとJavaScriptフロントエンド
学生の前面がすべて聞いたことがあるはずですとしてそれを信じている「結局、前のエントリのしきい値は、比較的低いです」。そしてJavaScript後端に緩い使用弱く型付けされた言語であり、（活字体を用いてもよいです）。ステレオタイプを変更する長いプロセスです。また、国内メーカー、大規模な使用Node.jsのためのオンライン環境に感謝してありますが、それは過去の人々の印象を変えています。
4. Node.jsの生態系の不確実性。
これは主に2つの理由は次のとおりです。
- Node.jsの作者は、新たな破った
deno、みんなのNode.jsを使用しての信頼を損なわ。 - NPMパッケージには、膨大な数が、しかし、セキュリティが保証されていません。
要するに、Node.jsのサーバー側の開発言語を使用して行う、それは強い決意が必要です。しかし、決意は、我々はあなたが足場を特定する必要があり、新しい技術を使用し、十分ではありません。
足場 - なぜ私はNode.jsのを使うのですか
我々は最終的にはアムウェイリーダーシップのNode.jsに勇気を見つけたとき、我々はそれを「特定の植物にも使用し、あなたが見る」、と言うことはできません。あらかじめご了承の無駄を予断することなく、forearmedされます。指導者たちは、これが唯一の私の同僚の先端であることを理解して、あるいはもっとうまくなるように我々は、出発点を特定する必要があります。私たちは、次の側面から議論することができると思います。
すべてのユーザーに1 - ユーザーエクスペリエンスを向上
フロントエンドの開発は、ユーザーエクスペリエンスのために責任を負わなければなりません。
むかしむかし、前と開発の境界の終了後にはそれほど明白ではありません、フロントページと実行するバックオフィスのスタッフのほとんどは、jQueryの+ブートストラップが、そのようなので、上のJ2EE、PHP、ASP.NETやなど何でも、することができます。しかし、フロントフレームの出現で（角度、Vueの反応し）、その複雑さと背景は、箱から出していない始めるのは難しいことができます。ゆっくりと、今のバックオフィスのスタッフは、フロントエンドの「知らない」、フロントエンドは、より多くの経験について言います。
同時に、複雑なフロントエンドのフレームワークだけでなく、より多くの時間を倍にするには、黒と白のは、顧客の損失につながる、我々は、最適化を行うためのような一般的な手段を必要としSSR、PWA。あなたはNode.jsのでこれらの機能を助けていない場合や、それを達成することは困難です。
2.明確な権限 - 開発チームの生産性を向上させるために
サーバインターフェイスが安定する傾向がある、一般的なサービスのために設計されなければならない、バックエンドのチームがUIにサービス自体、およびなどほとんど注目に焦点を当てるべきです。インターフェイスのセットは、適用マルチポート。
インターフェース志向するUI BFFデータ集約、クリッピングおよび書式を達成するために、（フロントエンドのためにバックエンド）。保持しているサービスの自律 1人のチームリーダーの前端部に引き渡されるべき原則を、（開発して使用し、責任者です、）。
3.通電チームは - チームの想像力と成長の余地のフロントエンドを改善するために、
フロントは、以下のような継続的な学習と充電エリアの必要性、新技術の様々な出現と主流になるし続ける、でPWA、GraphQL、SSRというように、私たちがしようとする必要があります。Node.jsのは、これらの技術は、チームダイナミックで技術レベルを向上させるために作るために秋にチームを作るために使用されます。チームの想像力は、作成することができるのと同じものではありません。
指導者たちは、ライブのNode.jsをホールドするようにどのように信頼することができます
1.プロフェッショナルなイメージを確立
指導者たちは、あなたが信頼の人の指導者の最初の人またはチームように一つのことを行うことができるであることを知っているように、メインのビルドにリーダーシップとの信頼感を実現するために、プロフェッショナルなイメージを確立します。これは個人的な資質を示し、平時におけるリーダーシップを持つより多くの交流を必要とします。私は2つの領域に分割されていると思います：
- 強い責任感は、強力な問題解決能力は、勉強することができるように失敗しました。以前にプレイしている場合は厳しい戦いは非常に良い証拠材料になります。
- 卓越した技術力。自体は通常は良い仕事をする作業に加えて、バックエンドネットワーク、セキュリティ、コード、アーキテクチャなど、通常より多くのショッピングフォーラム、友人の内部/円共有するという点でパフォーマンスにそこに関連する必要があり、技術的な記事を書く良い証拠でしょう。
2.石の丘、学ぶことができます
技術へのオープンかつ包括的な態度。大きな牛の背景の前では、Node.jsのは、コンテンツまたはマイナーを行うことができますが、彼らはすべての面で成熟したプログラムを持っています。たとえば、全体の監視システム・パフォーマンス・メトリック、アルゴリズム、データベースなどで、リンク、およびので、バックオフィスのスタッフとより多くの助言で、他の人に耳を傾けます。
3.データ、文書に話します
どのようにNode.jsのパフォーマンス、いくつかの単語を明確に記述することができない私達によって、既存の圧力に耐えることができ、レポートを測定する圧力は最高の証拠です。既存のシステムの変換は、比較的直感的なデータは良くなるがある場合は、データが+の10倍の性能により増加したうちの圧力試験でページをレンダリングするとき、私たちは、Node.jsの変換JSPサイトを使用しています。
優れた技術設計文書は、あなたのアーキテクチャを理解し、それに続く拡張を作るために、誰もが容易になります。したがって、文書の長期維持も重要です。良いドキュメントを書くためにどのように、我々は記事を参照して、ここでお勧めのドキュメントについて説明しますどのような誰もが
他の
以下は参照用のみ、Node.jsの将来の発展に私の意見の一部を以下に示します。
service mesh大規模な使用後は、任意の言語でのマイクロサービスシステム自体を構築する方法について心配する必要がなく、ミクロなサービスを開発することができます。良いNode.jsのための;- 既存システムの運用・保守をして、すでにかなり成熟している
k8s+Prometheusオンラインモニタリングがシンプルになり、あなたはNode.jsの実行時監視を行うことができます。 - 「長い分間一緒に世界の動向」、事務所のNode.js後、サービス側に焦点を当て、独立した仕事になるはずです。
いくつかの有用な情報
ます。https：//juejin.im/post/5d033550f265da1b9253d6e3で再現