はじめに： 問題点に触れる簡潔でワンストップのフロントエンドエージェントソリューションは、それに値します。
著者：コールド斜め
フロントエンドエージェントと言えば、フロントエンドとバックエンドの共同デバッグを行ったすべての学生がそれに遭遇したと思います。フロントエンドとバックエンドのエンジニアリングプロジェクトの現在の開発では、主流モデルはフロントエンドとバックエンドの分離でなければなりません。これにより、フロントエンドとバックエンドの役割がより明確になり、プロジェクトのR＆D品質の保証が向上します。しかし、それはまたデバッグに多くの不便をもたらします。
ここでは例としてWeb開発を取り上げます。フロントエンドプロジェクトとバックエンドプロジェクトが分離され、それぞれのサービスが有効になっています。フロントエンドサービスは主に、フロントエンド開発を容易にして、記述されたコードのレンダリング結果をリアルタイムで観察できるようにします。ここでは、より現実的なエンジニアリング効果を確保するために、優先順位を付けたいと考えています実際のバックエンドインターフェイスを使用してデータを取得しますが、ブラウザー自体のクロスドメイン制限のため、フロントエンドはブラウザーから開始されたリクエストがバックエンドサーバーに直接到達することを許可できません。
現時点では、クロスドメイン問題の解決に役立つプロキシ機能のレイヤーを追加する必要があります。
ソリューションは非常にシンプルです。Webpackでプロキシアドレスを構成して、フロントエンドとバックエンドのジョイントデバッグを開始します。しかし...ほとんどの場合、共同試運転の状況は、単にバックエンドでIPアドレスを提供するよりも複雑なことがよくあります。
あなたはそのような状況に直面する必要があるかもしれません
シナリオ1
通常、バックエンドプロジェクトでは、インターフェイスにいくつかの制限を追加する必要があります。たとえば、ほとんどの場合、ログイン認証は必須です。この時点で、プロキシのサービスアドレスを直接構成し、リクエストを開始します。
シナリオ2
1多くの非常に現実的な例に。プロジェクトチームの現在のR＆D比は、通常、1つのフロントエンドから複数のバックエンドであり、バックエンドの学生は同時に開発します。フロントエンドと調整すると、並列になります。サービスが別のサービスにデプロイされたのは、全員がコードをマージして、サービスアドレスがフロントエンドのデバッグを許可するステージに配置するのがまだ終わらないためです。現時点では、フロントエンドはエージェントのみを切り替えることができます。
シナリオ3
ログイン検証の状況に加えて、バックエンドサービスが要塞マシンの背後に隠されているという特別なことがあります。セキュリティ検証のレベルに相当します。お客様の独自のクラウド環境のような別のレベルです。現時点では、ホストの使用を含む一般的なプロキシ設定は解決できません。
あなたの可能な解決策
シナリオ1のソリューション
ログイン権限をバイパスする方法は、通常の方法で単純にログを記録し、インターフェイスからCookie情報を取得し、いくつかのメソッドを使用してローカルリクエストでこのCookieを取得し、サーバーがそれを認識できるようにします。このとき、テストサーバーがドメイン名の形式でサービスを提供している場合は、ihostsなどのホスト管理ツールを導入し、ローカルIPとテストサービスドメイン名の間のマッピングを構成してアクティブ化できます。これは、同じドメイン名と異なるポートがCookieを共有できるためです。スムーズにアクセスできます。ただし、テストサービスがIPアクセスのみを提供し、ログイン検証が設定されている場合、現時点では、ホストをバインドしてCookieを送信することはできません。webpackについて考えますが、webpackのcookie設定はより複雑です多くの場合、検索と学習を通じてこれを行うには長い時間がかかり、成功するためには、最終的には間違いを犯し続ける必要がある場合があります。明らかに、このコストは、小さなデバッグ要件に対してはまだ少し高いです。
シナリオ2のソリューション
複数のプロキシ構成を設定し、異なる開発環境に対応するときに切り替えますが、プロジェクトを再起動する必要があります。特定の環境の違いを判断するための独自のロジックを記述する必要があります。
シナリオ3ソリューション
Charles、PostManなどの既存のプロキシツールを使用します。ChromeプラグインSwitchyOmegaなど、PostMan、SwitchyOmegaは、独自のインターフェースをテストするリクエストを開始するバックエンドシミュレーションに適しています。Charlesはより包括的で、パケットのキャプチャに使用でき、プロキシデバッグにも使用できますが、構成は比較的複雑です。または、nginxに精通している学生はnginxをプロキシ実装として使用できますが、初心者にとって、これらの方法で調整可能なプロキシを実装するコストは依然として高すぎます。
フロントエンドとバックエンドの共同デバッグの問題を5分で解決するにはどうすればよいですか？
簡潔で問題点に触れる、より優れたワンストップソリューションはありますか？答えは、存在する必要があるということですここでは、引き出しツール-Alibaba CloudTookit vscodeプラグインバージョンをお勧めし ます。プラグインのインストールは、vscodeを開き、プラグインパネルを選択し、「Alibaba Cloud Tookit」を検索して選択し、インストールするのに非常に便利です。
次に、CloudTookitの「治療効果」を示す実際的な例を見てみましょう。
実際の展開環境のフロントセクションでの共同デバッグ
多くの場合、フロントエンドのR＆Dは、実際の環境により近い環境で共同デバッグを行うことを望んでいます。問題が発生した場合、事前送信と同様の環境でローカル共同デバッグテストを実行する必要があります。現時点では、厳しい認証問題が発生します。たとえば、クラウド製品の事前発行環境を共同で調整し、sec_tokenを取得し、検証に合格するためにログイン検証Cookieを取得する必要がありますが、従来のWebpackプロキシが認証を設定し、直接友好的ではありません。
次に、認証との共同デバッグ効果を示し、環境ホストxx.xxx.xxx.xx mse.console.aliyun.comを事前送信し、コンソールにログインします。
プロキシを設定する前に、ローカル起動の効果を見てみましょう：
データが利用できないことがわかります。次に、Cloud Tookitを直接使用してすばやく立ち上がる：
クリックしてビデオを表示
要約すると、プロキシ認証のデバッグは、次の3つのステップに分割するだけで済みます。
1.ログインしてcookieを取得し、sec_token（認証データのセキュリティを保護するために注意してください）
2. vscodeを開き、cloud Takeitプロキシを選択し、プロキシ構成を作成してCookieを貼り付け、プロキシを保存してアクティブ化します
3.プロキシホストをコピーし、webpackプロキシ構成を置き換えます。プロジェクトを開始するだけです。
マルチ環境ドッキングと共同デバッグ
アリPTS新旧の反復的な開発ニーズの2つのバージョンがあり、製品のクラウドパフォーマンステストを曇らせるように設計され、各事前オンライン環境と環境の別のバージョンがある、独自のプロキシとフロントエンド開発コードの結合、管理、切り替えは不便です。
古いバージョン：pre-pts.aliyun.com、pts.aliyun.com
新しいバージョン：pts.console.aliyun.com異なるホストを介して送信前とオンラインを切り替えます
いくつかの特別な関数がpre-s.pts.aliyun.comの新しいドメインを追加するため、つまり、同じフロントエンドエンジニアリングコードのセットを少なくとも5つの共同デバッグ環境に接続する必要があり、実際には開発が非常に困難になります。 、しかし、Cloud Tookitプラグインを使用すると、まったく異なるエクスペリエンスが得られます。
対応するドメイン名に応じて、CloutTookitプラグインを開いてセットアップします。効果を区別するために、さまざまなアカウントからCookieを取得します
proxy1は完全なPTSアカウントCookieを
取得します1 proxy2-は不完全に認証されたアカウントCookieを取得します2
まず、proxy 1を使用してpre-pts.aliyun.comを指定します。現時点では、proxy 1が使用するcookieアカウントがメインアカウントであり、データは比較的完全です。プロジェクトにプロキシを構成し、プロジェクトを開始して効果を確認します。
ビデオをクリックして効果を確認してください
次に、プロジェクトを再起動せずに、2番目のpre-s.pts.aliyun.comのセットに切り替えます。このアカウントには十分な権限がなく、データも多くありません。proxy2を開き、ブラウザーで直接更新して結果を確認します：
共同デバッグ環境の切り替えは非常に完璧であり、途中でプロジェクトを再起動する必要がないことがわかります。
独自のクラウド環境の共同デバッグ
ローカル環境の制限により、特定のプロジェクト機能は実際の環境でのみ検証できます。実際の環境には比較的高いセキュリティ要件があり、要塞マシンは内部サービスの転送によく使用されます。現時点では、通常のプロキシ方式は失敗し、ローカルとオンラインの間の共同デバッグは不可能になります。プロジェクトのプロモーション効率は大幅に低下します。
注：要塞マシン自体へのアクセスはより面倒です。最初にブラウザプロキシソフトウェアを使用して設定する必要があります。
次に、ブラウザーを介してaa.bb.ccなどの特定のサービスのドメイン名にアクセスします（前にログインリンクもあります）。次に、ブラウザーは最初に指定された要塞マシンエージェントにリクエストを送信し、要塞マシンは内部に分散され、特定のサービスに通信されます。ローカルで共同デバッグを希望しても、応答の検証をバイパスすることはできません。ログイン後、検証Cookieを取得し、次のステップはCloudTookitでその能力を継続します。
最初にシステムにログインします。
公式ページにアクセスしてCookieを取得します。
プラグインを開いて、サービスアドレスと要塞マシンアドレスを設定します。
次に、プロキシを保存してアクティブ化し、ローカルプロキシサービスアドレスをプロジェクトのプロキシアドレスに置き換えます。
プロジェクトを開始し、驚きを目撃してください：
使用感
流行の最中に、私たちは専用のクラウドプロジェクトを作成しました（パブリックネットワークに直接接続されていません）要塞マシンなどの複雑なシナリオに遭遇し、最初はそれを助けることができませんでした。スタンダード環境にログインした後、ページをクリックして問題の原因を特定します。SoureMapは問題の迅速な特定にのみ役立ち、変更後の確認はできません。オンラインでのみ問題を確認してから、コードを変更してパッケージ化し、再デプロイのためにバックエンドのクラスメートに投げます。通常、往復に3時間以上かかります。これがどれほど非効率的か想像できます。ビジネスは私たちに代理店の能力に関するそのような研究を強いる。後で、独自のクラウド環境、ローカルコードのデバッグ、問題が発生したときの数秒の検証に直接接続でき、効率が大幅に向上し、プロジェクトの通常の配信が完全に保証されます。
クラスメートの1人から、共同デバッグ環境が再び変更されたと言われたら、どうすればよいですか？私はCTを数分間彼に直接投げて、彼を終わらせました。
最後
CloudtTookitは常に、開発者に高効率の開発サービスを提供することを約束しており、自社製品の機能は開発者の真のニーズに基づいています。CloudTookitをこの小さなプラグインとして収集することを強くお勧めします。一般的なプロジェクトの共同デバッグを行っている場合でも、他の共同デバッグのニーズがある場合でも、問題を完全に解決するのに役立ちます。良い提案やアイデアがあれば、私たちに教えてください。良い提案を真剣に検討します。以前は開発者コミュニティのサービスを楽しんできましたが、今は開発者コミュニティに還元したいと思っています。開発者エコシステム全体のインフラストラクチャを充実させ、改善するために一緒に。
