19

私のgoogle-fuが失敗したか、これを行っている人がまだあまり多くありません。ご存知のように、Backbone.js にはアキレス腱があります。Googlebot などのページ クローラーは JavaScript を実行しないため、レンダリングする html を提供できません (ただし、Google のリソース、V8 エンジン、およびJavaScript アプリケーションは増加傾向にあります。私は、これがいつか実現することを期待しています)。Google がハッシュバングの回避策ポリシーを持っていることは承知していますが、それは単純に悪い考えです。さらに、PushState を使用しています。これは私にとって非常に重要な問題であり、他の人にとっても同様であることを期待しています. SEO は無視できないものであり、SEO を必要とする、または依存する多くのアプリケーションでは考慮することができません。

node.js を入力します。私はこの流行に乗り始めたばかりですが、クライアントに存在するのと同じ Backbone.js アプリを、node.js と手をつないでサーバーに置くことは可能のようです。node.js は、Backbone.js アプリからレンダリングされた html をページ クローラーに提供できるようになります。実現可能と思われますが、node.jsの経験が豊富な人、または実際にこれを行ったことがある人にアドバイスを求めています。

node.js を使用して Backbone.js アプリを Web クローラーに提供できるようにするには、どのような手順を実行する必要がありますか? また、私のバックボーン アプリは、Rails で記述された API を使用しているため、これで頭痛が軽減されると思います。

編集: Backbone.js で記述された実稼働アプリを既に持っていることは言及しませんでした。この手法をそのアプリに適用しようとしています。

4

6 に答える 6

1

まず、この node.js の使用は悪い考えだと思うという免責事項を追加させてください。2 番目の免責事項: 私は同様のハッキングを行ったことがありますが、自動テストの目的であり、クローラーではありません。

それはさておき、行きましょう。サーバーでクライアント側アプリを実行する場合は、サーバーでブラウザー環境を再作成する必要があります。

  1. 最も明白なのは、DOM (Document Object Model) が欠けていることです。基本的には、解析された HTML ドキュメントの上にある AST です。これに対する node.js ソリューションはjsdomです。

  2. しかし、それだけでは十分ではありません。お使いのブラウザは、BOM (Browser Object Model) も公開しています。たとえば、history.pushState. ここがややこしいところです。2 つのオプションがあります。phantomjs または casperjs を曲げてアプリを実行し、HTML をスクレイピングすることができます。UI パーツが切り取られた巨大なフル WebKit ブラウザーを実行しているため、脆弱です。

  3. もう 1 つのオプションはZombieです。これは、Javascript でブラウザー機能を軽量に再実装したものです。ページによると、それは pushState をサポートしていますが、私の経験では、ブラウザーのエミュレーションは完全にはほど遠いものです。

于 2012-10-11T08:32:27.753 に答える
0
于 2012-10-09T11:27:42.130 に答える
0

フォールバック戦略タイプのアプローチを取ることができると思います。JavaScript をオフにして、リンクをクリックした場合と js をオンにした場合に何が起こるかを考えてみてください。クロール可能なページで行うことはすべて、javascript がオフになっている場合に適切なフォールバック手順を用意する必要があります。リンクには常にサーバーへのリンクが href として含まれている必要があり、発生するデフォルトのアクションは JavaScript で防止する必要があります。

これは必ずしもバックボーンの責任であるとは言えません。ここでバックボーンが役立つ唯一のことは、ページが変更されたときに URL を変更し、モデル/コレクションがクライアント側とサーバー側の両方になるようにすることです。私が信じているビューとルーターは、厳密にはクライアント側です。

ただし、コンテンツが挿入されているかどうかに関係なく、クライアント側またはサーバー側から jade ページと部分的にレンダリング可能にすることができます。このようにして、同じページをどちらの方法でもレンダリングできます。つまり、ページの大部分を置き換えて URL を変更した場合、取得している html は、誰かがそのページに直接アクセスしたかのように、同じテンプレートからのものになる可能性があります。

サーバーがリクエストを受信すると、メイン エントリ ポイントとロード バックボーンを経由してページを操作し、ユーザーが URL を使用して意図するように設定するのではなく、直接そのページに移動する必要があります。

アプリ内のものを少し再配置するだけで、これを達成できるはずだと思います。かなりの量の物を動かすだけで、実際の書き直しはありません。注入されたコンテンツまたは注入されていないコンテンツを含む html ファイルを提供するコントローラーを作成する必要がある場合があります。これは、モデルからのデータと結合するために必要な html をバックボーン アプリに提供するのに役立ちます。先ほど言ったように、express/node.js で定義されたルーターを介してこれらのリンクに直接アクセスすると、同じテンプレートを使用できます。

于 2012-10-09T22:39:47.887 に答える
0

実用的な解決策は、 https://github.com/Morriz/backbone-everywhereのどこでも Backbone を使用する ことですが、バックエンドとして Node を使用する必要があります。

もう 1 つの方法は、サーバーとフロントエンドで同じテンプレートを使用することです。フロントエンドは、require.js テキスト プラグインを使用して Mustache テンプレートを読み込み、サーバーも同じ Mustache テンプレートを使用してページをレンダリングします。

もう 1 つの追加機能は、javascript タグでブートストラップされたモジュール データを JSON データとしてレンダリングし、バックボーンがモデルとコレクションを設定するためにすぐに使用できるようにすることです。

于 2012-10-13T13:34:02.723 に答える
0

これは、私たちのアプリでやるべきことの私の todo リストです: Node.js にバックボーン ルート (アプリの起動時にメモリに保存されます) を解析させ、少なくともメイン ページ テンプレートを直接 HTML で提供します。何千ものユーザーがサイトにアクセスすることを考慮すると、BE のオーバーヘッド/処理が多すぎます。

AirBnB のようなバックボーン アプリもこの方法で行うと思いますが、Google クローラーのようなロボットに対してのみです。また、Facebook がクローラーを送信して og:tags を読み取るため、Facebook のいいねなどにもこの状況が必要です。

于 2012-10-09T22:49:13.207 に答える
-1

基本的には、何を提供しているのかを判断する必要があります。それは真のアプリ (つまり、専用のデスクトップ アプリケーションの代わりになるもの) なのか、それともコンテンツのプレゼンテーション (つまり、従来の「Web ページ」) なのかを判断する必要があります。 )? SEO が気になる場合は、実際には後者 (「コンテンツ サイト」) である可能性が高く、その場合、「シングル ページ アプリ」モデルは適切ではありません。代わりに「プログレッシブ エンハンスド ウェブサイト」モデルが本当に必要です (「目立たない JavaScript」、「プログレッシブ エンハンスメント」、「アダプティブ Web デザイン」などのフレーズを調べてください)。

少し増幅すると、「サーバーはシリアル化されたデータのみを送信し、クライアントはすべてのレンダリングを行います」は、「真のアプリ」シナリオでのみ適切です。「コンテンツ サイト」のシナリオの場合、適切なモデルは「サーバーがメインのレンダリングを行い、クライアントが見栄えを良くし、可能な場合は混乱を招くページ遷移を避けるために小規模なレンダリングを行う」です。

ところで、プログレッシブ エンハンスメントが「テキスト読み上げを使用する目の不自由なユーザーに勝るものはない」ということを意味するという反論は、現実ではなく政治的な反感の表れです。プログレッシブ エンハンスド サイトは、ハイエンド レンダリング システムを使用するユーザーの観点から、好きなだけファンシーにすることができます。

于 2012-09-16T10:43:34.503 に答える