PHP から Node.js に切り替えるときにやるべきこと-PHPチュートリアル-php.cn

開発チームが PHP を使用していて、Node.js への移行を検討している場合は、この記事が役立ちます。この記事では、PHP から Node.js への移植の詳細や、Node.js の基本知識については説明しません。代わりに、意思決定、どこから始めるべきかの説明、Node.js サーバーを作成するための詳細な考慮事項、およびデプロイメント戦略について説明します。

なぜ移行するのですか?

1stdibs は次の 5 つの理由から Apache/PHP から Node.js+Express への移行を決定しました:

コードが少ない
フルスタック JS
より幸せな開発者
ROI
将来の最適化

少ないコード

1stdibs はサービス指向アーキテクチャ (SAO) に基づいており、フロントエンドはバックグラウンド JAVA サービスを呼び出します。これは、フロントエンドモデルだけでなく、サーバー側の PHP テンプレートとクライアント側の JS テンプレートの両方を維持することを意味します。想像してみてください。PHP を廃止できれば、フロントエンドディスプレイとバックエンドモデルを 1 つの言語である JavaScript に統合できます (同時にいくつかのテンプレートをマージできます)。メンテナンスの観点から見ると、これによりコードがより簡潔になり、ロジックが重複しなくなります。

同型 JavaScript 万歳!

フルスタック JS (およびその利点)

開発スタック全体で 1 つの言語を使用するのは簡単です。開発者にとって、コンテキストの切り替えが減れば、幸せになり、生産性も高まります。さらに、ツールの使用が簡単になるという利点もあります。 Composer と npm という 2 つのパッケージマネージャーを使用するのに比べ、必要なのは 1 つだけです。 Composer は優れていますが、nbp はツールとクライアント管理を担当するため、nbp は常に必要になります。すべての PHP コードが削除されると、nbp が唯一のパッケージマネージャーになります。

開発者は満足しています

開発者のスキルセットが拡大され、キャリアが成長し続けることを保証することが重要です。 JavaScript エンジニアにとって、Node.js は非常に魅力的です。クライアントと同じツール、スタイル、パターンをサーバーでも使用できることは、非常に便利で効率的です。さらに、Node.js は非常に人気があり、エンタープライズレベルの開発でも大きな進歩を遂げています。 Node.js は JavaScript エンジニアにとって必須のスキルです。

投資収益率

当社は優秀な JS エンジニアの採用と若手 JS エンジニアの育成に多額の資金を費やしています。クライアントスタックは複雑であるため、上級 JavaScript エンジニアが必要です。当社では PHP エンジニアを採用せず、JavaScript エンジニアのみを採用しています。私たちの見解は、サーバー側で彼らのスキルを開発してはいかがでしょうか?というものです。

将来の最適化

長期的には、2 つの巨大なアプリケーションを、独立してデプロイされた一連の小さなアプリケーションに分割する予定です。これは、Node.js、Express、nbp を使用すると簡単に実現できます。理論的には、PHP (たとえば、Slim を使用) でも同じことができます。しかし、上記の利点が得られないだけでなく、Apache/PHP での操作がより複雑になり、インフラストラクチャが少し奇妙になるなど、混乱も生じます。

フレームワークの選択

最終的に Node.js に置き換えた PHP アプリケーションには主に次の役割があります:

ログインと承認
ルーティングおよびサーバー側テンプレートエンジン (HTML を提供)
ブートストラップフロントエンドアプリケーション
プロキシサービス (CORS を回避するため)
静的リソース (js、css、画像) を提供

これらは、置き換える必要がある基本的な関数です。

私たちはかなりの数のフレームワークを試してきましたが、Express は素晴らしいものでした (私たちがレビューしたスプレッドシートを試してください)。 Express に基づいていないフレームワークは信頼性に欠けるように見えます。 Express は理解しやすく、優れたドキュメントが用意されています。さらに、Express の正式なトレーニングを受けた人材を採用することもできます。

いくつかの kraken コアモジュールを追加しました (express-enrouten がルーティングに使用され、lusca がセキュリティを担当します)。さらに、i18n-node は国際化サポートを提供し、テンプレートエンジンは Swig を使用します (後に Swig を放棄しました。あはは、オープンソースソフトウェアには依然としてリスクがあります)。

私たちは完全に kraken を使用することを検討しましたが、オリジナルのサーバーサイド PHP テンプレートエンジンである Twig から Swig への切り替えは簡単かつ迅速でした。さらに、クラーケンの塵や i18n は目に不快なものです。

サーバーの作成

フレームワークを選択したら、次のステップはサーバーを作成することです。

Apache+PHP を使用する場合、別のサーバーを作成する必要はありません。 Apache自体がサーバーであり、PHPがアプリケーションです。 Node.js を使用する場合、サーバーとアプリケーションは同一です。 Apache/PHP から PHP に移行する場合、以前は自然に使用していたいくつかの機能に取り組む必要があることが重要です。 Apache を使用すると、ユーザー (またはシステム管理者) がサーバーを構成するため、PHP アプリケーションで Apache が何を処理するかを心配する必要がなくなります。 Node.js は別の方法で動作します。

静的ファイルサービスの提供

静的ファイルサービスの提供が Apache の中核機能であることは疑いの余地がありません。 Node.js は、アプリケーション内で静的ファイルの提供を構成するという点でこれとは異なります。幸いなことに、これはシンプルで、十分に文書化されており、Express で実装されています。

ログ

多くの基本的な Apache 設定では、アクセスログとエラーログが提供されます。 Node.js を使用する場合、アプリケーション内でも Node.js を構成する必要があると思われるかもしれません。幸いなことに、これを簡単に行える優れたオープンソースソフトウェアパッケージが数多くあります。 Morgan は、構成が簡単で、出力ストリーム (標準出力デバイスまたはファイル) にログを書き込むことができる基本的なリクエストロガーです。ログをデータベースに書き込む必要がある場合、または他の (より高度な) ログ要件がある場合は、Winston を試してみてください。

プロキシ

基本的な要件があります。それは、クライアントの Ajax リクエストをプロキシしてバックグラウンドサービスに送信できることです。 CORS ヘッダーを処理するよりも、同じドメインからのすべてのリクエストをプロキシする方がはるかに簡単です。ただし、(私たちが行っているように) プロキシ経由で webpack-dev-server を使用したい場合は、これを Node.js アプリケーションで処理する必要があります。 http-proxy はシンプルで信頼性の高いソリューションです。

残りの作業

上記に加えて、完了する必要のある一連のタスクがあります。 MVC アプリケーションから始めましょう。これは CodeIgniter (CI) フレームワークに基づいており、一連のシングルページアプリケーションにサービスを提供します。作業のほとんどは移植です:

CI コントローラーを Express ルートセレクターとミドルウェア (ログインと認証を含む) に移植
Twig テンプレートエンジンを Swig に移植 (このステップは簡単です)
サービス層データアクセス (クライアントのシングルページアプリケーションを通常どおり起動するため)

CodeIgniter モデルのこの重要なコンポーネントは上にリストされていません。実際、PHP モデルを書き直す必要はまったくありません。 本当にすごいですね！ 私たちのクライアントアプリケーションはバックボーンモデルを使用します。もちろん、サーバーとクライアントでグローバルに動作するように、Backbone.Model.sync を拡張する必要があります。

展開

アプリが大規模な場合は、一度にすべてを起動しないでください。プログレッシブ展開を通じて段階的に開始できます。数週間かかりました。

プログレッシブデプロイメントの利点:

バグの範囲を最小限に抑える
ルートや機能の一部がリリースされるたびに、他のエンジニアが正常に開発できる
進行中の機能開発と改善への影響は最小限 — 新しい機能は引き続きリリースされます (作業の重複が生じる可能性があります)
正しく実行されれば、以前のサービスにすぐにロールバックできます

NGINX は非常に優れています

徐々にオンラインにするにはどうすればよいですか?数あるサーバーの中からNginxを選択しました。

             +----------+ http        |          |---> Apache/PHP request---->|  Nginx   |             |          |---> Node.js             +----------+

ログイン後にコピー

Nginx では、一度に 1 つのルートを「オン」にすることができます (何度も遭遇したように、何かがうまくいっていないことに気付いた場合はオフにします) , これにより、柔軟性に優れた自由度が得られます。コードをデプロイせずにルーティングを有効にすることも役立つことがわかりました。これにより、毎週のリリーススケジュールに多少の余裕が生まれます。

ただし、欠点があります。クライアントコードが古い Apache/PHP サーバーと新しい Node.js サーバーの両方によって提供されるサービスを確実に受け入れる必要があります。それほどひどいことではありませんが、最適化されていない機能を古いサーバーから新しいサーバーに移植する必要があります。息を止めて実行してください（そして、技術的負債を一掃するために付箋に書くことを忘れないでください）。

概要

移植作業全体には、最初から最後まで約 1 年かかりました。少しばかげているように聞こえるかもしれませんが、このスケジュールには、意思決定プロセス (比較的急ぎます)、ニーズを満たす Express ベースのコアフレームワークの作成、すべての機能の移植、および段階的なオンラインローンチが含まれています。また、私たちのために働いている開発者は常に 1 人か 2 人だけであり、パートタイムで働いていることにも留意してください。

試してみたい方は、よくご検討ください。あなたのチームにメリットはありますか?組織全体にメリットがもたらされるでしょうか?ビジネス組織に所属している場合は、ビジネスを継続する必要があることを忘れないでください。ビジネス目標とエンジニアリング目標の間で適切なバランスを見つける必要があります。

試してみて本当によかったです。