Firebase-tools: استخدم الاستضافة مع prerender.io

مرحبا،

في الوقت الحالي ، لا يتم تفصيل قواعد إعادة الكتابة / إعادة التوجيه الخاصة بـ Firebase Hosting بما يكفي لتقديم خدمات العرض المسبق ، ولكن نجح بعض عملائنا في بناء خطوة ما قبل العرض في عملية الإنشاء الخاصة بهم للمواقع الثابتة إلى حد ما باستخدام html5 pushState. إنهم يعرضون كل صفحة مسبقًا بناءً على تطبيق الصفحة الواحدة بحيث يتم تقديم المحتوى الصحيح إلى الزاحف ، ثم إذا انتقل المستخدم إلى صفحة أخرى ، يتولى تطبيق الويب المسؤولية ويعيد العرض بدون تحديث الصفحة

من الواضح أن هذا معقد جدًا ومن الواضح أنه ليس مثاليًا ، لكننا نعمل على جعل هذا الأمر أقل صعوبة

امل ان يساعد

كريس

أدرك أنه قد مضى شهرين فقط ، ولكن هل هناك تحديث لهذا؟ نظرًا لأنك مملوكة لشركة Google الآن ، أفترض أنهم يريدون أن تتم فهرسة المواقع المستضافة باستخدام Firebase بواسطة خدمة البحث الخاصة بهم.

ليس لدينا تحديث محدد حول هذا الأمر في الوقت الحالي ، فقط أن مُحسّنات محرّكات البحث مهمة بشكل واضح بالنسبة لنا وتبقي استضافة Firebase ذات صلة بالمطورين. آمل أن أحصل على تحديث لك قريبًا

اهلا ياجماعة! أردت فقط أن أعرف ما هي حالة هذا التحديث؟ هل سيأتي في أي وقت قريب؟ أنا أستخدم استضافة Firebase ، ومن الرائع أن الشيء الوحيد الذي أشعر بالقلق هو تحسين محركات البحث ، ولا يظهر موقعي في أي مكان في google ، كما أنني بحثت عن تكاملات تحسين محركات البحث مع Firebase ولم أجد أي حل. أحب حقًا الاحتفاظ بكل شيء في مكان واحد ، لذلك سيكون من العار التغيير إلى خدمة مختلفة يمكنها خدمة صفحاتي في محرك الزاحف من Google. سيكون هذا تحسنًا كبيرًا لأنني أعرف أن Firebase مملوكة لشركة Google الآن. شكرا لك!

لا يزال مهتمًا بهذه الخدمة أيضًا. شكر!

إضافة صوتي إلى الموضوع - سيكون من الرائع الحصول على هذه الميزة!

+1

أنا أنتظر هذا أيضًا.

كبديل ، أبحث في استخدام https://divshot.com + firebase.

+1

بسبب الإعلان الأخير عن دمج DIvshot و Firebase ، تنشأ هذه المشكلة مرة أخرى. لقد انتقلت بالفعل إلى Divshot للاستفادة من المجال المخصص المجاني وإمكانيات prerender.io. كيف ستتعامل fireabse مع هذه القضايا؟ هل ستضيف مجالات مخصصة إلى المستوى المجاني؟ ماذا عن prerender.io؟

نحن نبحث في الطرق التي قد نتمكن من خلالها من تقديم عرض JS المسبق إلى Firebase Hosting ، ولكن ليس لدينا أي خطط ثابتة لمشاركتها في الوقت الحالي. (ملاحظة شخصية: أريد حقًا أن أرى ذلك يحدث).

نظرًا لأن Firebase يرى أن جميع المواقع يجب أن تكون HTTPS فقط ، فإننا ندير توفير شهادة SSL نيابة عن مستخدمينا. التكلفة التي ينطوي عليها القيام بذلك تمنعنا من أن نكون قادرين على تقديم استضافة مجال مخصصة مجانية.

شكرًا على الإجابة السريعة (يقصد التورية).

هناك حاجة إلى نوع من إمكانات تحسين محركات البحث (SEO) لمنصات استضافة تطبيقات الويب الثابتة ، لذلك آمل فقط يا رفاق أن تتمكنوا من الحصول على هذا العمل حتى منتصف ديسمبر ، وإلا فإن الكثير من المطورين سيحتاجون إلى التبديل إلى موفري استضافة المدارس القديمة (للأسف من بينهم أنا ).

الإجابة الثانية منطقية تمامًا وأنا أعتبر مجرد القفز على المستوى المدفوع ، فمن العار أنها لا توفر نفس القياس الإضافي لك.

100٪ من مواقع استضافة Firebase تعمل على شبكة توصيل المحتوى (CDN) السريعة للغاية من Fastly. يمكنك الحصول على جميع امتيازات خطة Divshot عالية الأداء حتى في الخطة المجانية (فقط ليس في مجال مخصص). بالنسبة لعرض النطاق الترددي ، ينتهي الأمر بـ 10 جيجا بايت لتكون _lot_ من النطاق لموقع ويب ثابت.

أحتاج أن أعترف أنني لم أفكر في امتيازات Divshot عالية الأداء. على أي حال ، من العار أن أحتاج إلى ترحيل تطبيقي وإعداد خلفية (وتأخير ميزات جديدة!) ، بينما تأكل درجة CS كل وقتي تقريبًا. على الرغم من أن مشروعي لا يعني أن الآخرين قد يعانون من تأخيرات هائلة ، لذا آمل حقًا أن يساعدنا Firebase في أن نصبح صديقين لكبار المسئولين الاقتصاديين أو ربما يؤخر Divshot إغلاقه. أتفهم أن هذا ربما ليس خيارًا ، ولكن إذا هاجر البعض منا فقد لا يعودون أبدًا

مبروك mbleigh على الاستحواذ!

DamodarSojka ، أتفق معك تمامًا. أنا مستخدم مدفوع حاليًا لبرنامج Divshot. يعد العرض المسبق أمرًا ضروريًا لتسويق / مشاركة موقع الويب الخاص بي على Facebook. إذا لم يقدم Firebase هذه الإمكانية قريبًا ، فسوف يتعين علي الانتقال إلى خدمات استضافة الويب الأخرى.

+1 لقدرة تحسين محركات البحث

نحن ندفع أيضًا لعملاء Divshot والدعم المسبق ضروري بالنسبة لنا. دعم العرض المسبق على Divshot ليس مثاليًا (بسبب عنوان URL للإنتاج.blabla.divshot.io بعد المشاركة) ولكن إذا لم يكن هناك دعم مسبق على Firebase ، فلا يمكننا استخدامه على الإطلاق. شكر.

وبالمثل ، فإن تحسين محركات البحث له أهمية قصوى ، سواء كنت تستخدم prerender.io أو أي حل مشابه آخر. يجب معالجة هذا الأمر في Firebase قبل إيقاف تشغيل divshot.

نعم ، ما زلت أواجه مشكلة في تحسين محركات البحث

+1 - عميل Divshot المدفوع ، سيتطلب دعمًا مسبقًا للترحيل إلى Firebase.

توافق كومبليتلي. لا يعد Firebase بديلاً لـ Divshot إذا لم يكن لديه إمكانيات العرض المسبق. أنا مستخدم مدفوع لبرنامج Divshot. مع إشعار شهرين بإغلاق Divshot. هل يجب أن أعمل على الانتقال إلى خدمة أخرى؟ هل يجب علي قضاء وقتي في تكوين الخادم؟ أو استمر في التركيز على ما كنت أفعله؟ أليست هذه فكرة الخدمة؟ لا تحتاج للتعامل مع مشاكل الخادم؟ يُرجى توضيح ما إذا كان Firebase سيكون خيارًا ليوم 14 كانون الأول (ديسمبر) أم ينبغي أن أقضي وقتي في تكوين الخادم.

لقد ذكر مايك ، أيها السادة بالفعل ، في مجملها ، حالة هذه الميزة: نحن نبحث في الطرق التي قد نتمكن من خلالها من تقديم عرض JS المسبق إلى Firebase Hosting ، ولكن ليس لدينا أي خطط مؤكدة لمشاركتها في الوقت الحالي. (ملاحظة شخصية: أريد حقًا أن أرى ذلك يحدث).

لا يوجد جدول زمني. نريدها بقدر ما تريد.

سيكون عليك أن تقرر بنفسك ما يجب عليك فعله. ليس لدينا خريطة طريق عامة. لا يمكننا تقديم أي ضمانات على أي جدول زمني ، بغض النظر عن عدد الطلبات أو الاستفسارات. معذرةً ، ليست الإجابات الزغبية السعيدة سعيدة ، ولكن نأمل أن تكون الإجابات الواقعية أكثر فائدة في تخطيطك.

☼ كاتو

من الجميل أن ترى أنك تهتم به حقًا :) شكرًا يا رفاق!

mbleigh / katowulf سؤال واحد حول هذه الخطة لتقديم عرض JS المسبق إلى Firebase: كيف سيكون العرض المسبق لـ JS أفضل من دعم تحسين محركات البحث الحالي الذي يقدمه Firebase ؟

بناءً على إجابة SO هذه ، يوفر Firebase بالفعل تحسين محركات البحث (SEO) خارج الصندوق منذ ng-conf 2015.

لذلك لا أحصل على مزايا استمرار محاولة استخدام Prerender.io على Firebase.

douglascorrea لـ Google SEO ، ستكون التحسينات هامشية ، لكن (كما اتضح) Google ليست الزاحف الوحيد هناك: ابتسم:

أكبر مكسب لذلك هو المواقع التي تريد تقديم دعم أفضل لعلامات Facebook OpenGraph ، وبطاقات Twitter ، ومحركات البحث غير التابعة لـ Google.

شكرًا لك mbleigh ، إنه يوضح الأشياء ويجعلني أعتقد أننا نريد حقًا هذا الدعم ، أو نوعًا من البديل مثل drtriumph قال في تعليقه.

كنت أبحث عن حل ، ووجدت التفاصيل التالية قد تكون مفيدة للقراء الآخرين:

• في أكتوبر 2015 ، ألغت Google التوصية باستخدام _escaped_fragment_ و hashbang (! #). لذلك ، بالنسبة إلى Google ، يجب على كل SPA استخدام html5 pushstate (html5mode على angularjs). لكنهم سيستمرون في دعم hashbang (! #) وترجمته إلى جزء هارب لبعض الوقت.
• لا يزال موقع Facebook وربما برامج الزحف الأخرى بحاجة إلى الجزء المُفلت ، وهو عبارة عن ترجمة آلية للفيسبوك من hashbang إلى تدوين _escaped_fragment. وربما تفعل برامج الزحف الأخرى نفس الشيء لأنها كانت التوصية السابقة من Google.
• نظرًا لأن Firebase لا يدعم عمليات إعادة التوجيه بناءً على User-Agent حتى الآن ، فلا يزال أملنا على برامج الزحف التي تترجم hasbangs (! #) إلى escape_fragament مثل هذا:
  إذا كانت عناوين URL الخاصة بك تبدو هكذا:
  http://www.example.com/#!/user/1
  ثم قم بالوصول إلى عناوين URL الخاصة بك مثل هذا:
  http://www.example.com/?_escaped_fragment_=/user/1

لذلك ، لفترة من الوقت ، قد تكون إحدى الأفكار لمعرفة ذلك هي:

• لا تستخدم html5 pushstate (وضع html5 في Angular) واستخدم hashbang بدلاً من ذلك (! #)
• استخدم prerender.io لإنشاء نسخة ثابتة / مخبأة من كل صفحة تريدها في تطبيقك (مثل عملية العرض المسبق العادية).
• قم بتطوير مكون إضافي يخزن هذا الإصدار المخبأ في هيكل مجلد يبدأ بالمجلد ?_escaped_fragment_= وأنشئ مجلدات مثل:
  إذا كانت عناوين URL الخاصة بك تبدو هكذا:
  http://www.example.com/#!/user/1
  سيكون المجلد الذي تم إنشاؤه
  ?_escaped_fragment_= +- /user +- /1

حيث سيكون الملف الأول هو ملف html الفعلي.

• انشر هذا المجلد في مجلد Firebase الجذر باستخدام أدوات firebase (يمكن أتمتة هذه العملية في وظيفة cron أو شيء من هذا القبيل).

كيف أعتقد أنه سيعمل:

• عندما يرى الزاحف عنوان url الخاص بك ، سيحاول الوصول إلى عنوان URL ?_escaped_fragment_= . نظرًا لأن لدينا ملفات HTML فعلية في هذه المجلدات ، فإن Firebase سيعمل حينئذٍ ولن يعيد التوجيه إلى index.html ، وبالتالي فإن HTML الذي يقرأه الزاحف سيكون هو النسخة المخبأة وليس AngularJS.

لتحقيق ذلك ، نحتاج إلى إنشاء وظيفة مجدولة تقوم بتشغيل العرض المسبق لكل صفحة ، وحفظ هذا المجلد وتنفيذ نشر Firebase.

نظرًا لأن نشر Firebase لا يدعم النشر الجزئي (المزامنة أو التزايدية) ، يجب علينا الاحتفاظ بنسخة محدثة من نشرنا على الخادم الذي سيكون مسؤولاً عن هذه العملية.

سأحاول إعداد ذلك وسأخبرك إذا كان يعمل.

هل يمكنك السماح لنا بتعيين "X-Prerender-Token" مثلما يمكننا استخدام مفاتيح الرأس الأخرى ؟؟؟
https://www.firebase.com/docs/hosting/guide/full-config.html
https://prerender.io/install-token

+1

@ srk9 يرجى إرسال مشكلة منفصلة بدلاً من إعادة تخصيص موضوع هذا الموضوع.

لماذا تم إغلاق هذه القضية؟ لا أرى حلًا منشورًا.

douglascorrea ، ماذا حدث بفكرتك؟

شكر،
-- د

مرحبًا bethuneco ، آسف لعدم نشر النتيجة هنا.

في الواقع كنت على وشك كتابة مقال ، لكنني أدركت بعد ذلك أن هذا الحل سيتألف من الكثير من "الآلات" لجعلها تعمل في الإنتاج ، ولم أشعر بالراحة في "التوصية" بها لأنني لا أعرف كيف سوف تتصرف على نطاق واسع.

ولكن بشكل أساسي ، كما وصفت سابقًا ، أحتاج إلى خادم "نشر / عرض مسبق" والذي ، لكل عملية نشر ، يقوم بعرض / إلغاء جميع الصفحات وتخزين HTML الناتج في المجلدات الموضحة أعلاه (/؟ _ escaped_framuation_ / xxxx) ستكون HTMLs "الحقيقية / المادية" هي صفحاتنا "المعروضة مسبقًا".

لذلك في كل مرة ينتقل فيها متتبع ارتباطات google / facebook / twitter إلى صفحتنا ويطلب البادئة "escaped_fragment" عبر "؟ _escaped_fragment" ، فإنه يشير في الواقع إلى مجلد حقيقي به HTMLs حقيقية ، ثم سيتم فهرسة HTML.
عندما ينتقل مستخدم حقيقي إلى التطبيق ، فلن يستخدم؟ _escaped_fragment ، لذلك سيتلقى الصفحة الديناميكية.

تكمن المشكلة في هذا "الحل" في أننا بحاجة إلى الاستمرار في إنشاء ملفات HTML لكل صفحة أو صفحة إضافية. على سبيل المثال ، إذا كان تطبيقك عبارة عن نظام إدارة محتوى بسيط ، فستحتاج إلى تشغيل العملية لإنشاء صفحة HTML جديدة لكل منشور / مقالة / صفحة جديدة. لكن المشكلة ستزداد حجمًا عندما نتحدث عن شبكة اجتماعية ديناميكية على سبيل المثال ، حيث يمكن لكل مستخدم إنشاء مئات الصفحات "القابلة للعرض مسبقًا" ، ثم يجب أن يعمل برنامج العرض المسبق / الزاحف الداخلي طوال الوقت. وهذا ، في العالم الحقيقي يمكن أن يكون سدادة.

هذا حل "خادع" للغاية يمكن أن يعمل مع التطبيقات الصغيرة ، ولكن ليس مع التطبيقات الكبيرة الحقيقية ، لأننا في الواقع ننشئ HTMLs لتكون موجودة عندما تنتقل برامج الزحف ولا نعيد توجيه برامج الزحف تلقائيًا إلى خدمة العرض المسبق لدينا التي ستعرضها مسبقًا عبر الإنترنت (مثل عملية العرض المسبق العادية).

لذلك ، في الوقت الحالي ، يجب أن نستخدم خادم Nginx كخادم ثابت حتى نتمكن من العرض المسبق ، أو استخدام منافس Divshot مثل https://www.netlify.com/ الذي يوفر Prerender خارج الصندوق لتطبيقات الصفحة الواحدة .

douglascorrea ،

شكرا لك على هذا الشرح الموسع. أنت أول شخص يذكر Netlify ، لذا سأبحث في ذلك.

أنت محق في أن العرض المسبق لكل شيء مناسب فقط للمواقع الصغيرة. لحسن الحظ ، فإن تطبيقي صغير إلى حد ما (بحد أقصى 1200 صفحة) ، لذلك يمكن أن يعمل.

أبسط حل (وهو الحل الذي تتجنبه Google) هو عرض جافا سكريبت مسبقًا وتقديم HTML عند اكتشاف وكلاء مستخدم الروبوت. لقد أثبتت Google بالفعل العرض خارج المتصفح ، لذا فإن هذا ليس صعبًا من الناحية الفنية. إنه يمثل تحديًا استراتيجيًا بالنسبة لهم لأنه يبدو أنه يساعد أحد المنافسين في مجال الإعلانات.

إذا حصلت على شيء يعمل ، فسأنشر تحديثًا هنا.

اسمحوا لي أن أقدم بعض الوضوح هنا لأي شخص قد يكون مرتبكًا:

هل تدعم استضافة Firebase العرض المسبق لـ JS على الخادم؟ لا ، لا. العرض المسبق من جانب الخادم هو شيء نرغب في دعمه وهو موجود في خريطة الطريق طويلة المدى الخاصة بنا ، لكن ليس لدينا تواريخ أو جداول زمنية محددة للإعلان عنها في هذا الوقت. نحن نعلم أن هذه نقطة ألم ، خاصة بالنسبة لأولئك الذين يستخدمون بطاقات المشاركة على Facebook أو Twitter ، ونأمل أن نتمكن من مشاركة المزيد حول هذا في المستقبل.

ألا يمكنك دعم مثل X-Prerender-Token ؟ كلا ، هذا لن ينجح. يجب أن يعرض العرض المسبق المحتوى _ الفعلي المعروض مسبقًا_ على عنوان URL ?_escaped_fragment_= ، مما يعني أنه ليس العنوان فقط ولكن المحتوى يجب أن يكون الخادم على علم به ويتعامل معه بشكل صحيح. لا يوجد حل نصف قياس بقدر ما نتمنى أن يكون هناك.

ما هو نوع العرض المسبق الممكن؟ النوع الوحيد من "العرض المسبق" الحقيقي الذي يمكنك القيام به في الوقت الحالي هو تجميع الموقع الثابت. عادةً ما يتم ذلك باستخدام شيء مثل Jekyll ، ولكن من الممكن بالتأكيد استخدام متصفح بدون رأس محليًا "لعرض مسبق" لموقع أكثر ديناميكية. يجب عليك عرض كل عنوان URL بشكل شامل ثم نشره ، لذا فهذه ليست حالة استخدام رائعة في الوقت الحالي. لاحظ أيضًا أن إنشاء أسماء ملفات تحتوي على ?_escaped_fragment_ بداخلها غير ممكن ، لأن CDN يزيل معلمات الاستعلام وهذه ليست حالة استخدام مدعومة بشكل عام.

هل هذا نوع من الأشياء الإستراتيجية لـ Google لإبقاء برامج الزحف الأخرى معطلة؟ لا على الاطلاق. نرغب بشدة في دعم المزايا التي يوفرها العرض المسبق لاستضافة Firebase. الأمر كله مجرد مسألة وقت وموارد.

اضطررت إلى التبديل من استضافة Firebase بسبب علامات الوسائط الاجتماعية / مشكلة تحسين محركات البحث البديلة. إنه أمر يكسر الصفقات عندما يلاحظ الأشخاص غير التقنيين أنه ليس لدينا صور جميلة على روابطنا مثل أي شخص آخر على الإنترنت.

يمكنك عرض مسبق باستخدام phantomjs والبرمجيات الوسيطة السابقة. إنه مفتوح المصدر ويعمل بشكل جيد ، لكنني ذهبت مع prerender.io لتجنب عمل العمليات. إنها بطيئة بعض الشيء عند الطلب الأول ، ولكن يمكنك تخزين الصفحات مؤقتًا عن طريق طلب كل صفحة بشكل استباقي.

من الجيد أن تطلب جميع الصفحات أيضًا ، لأنه يمكنك بعد ذلك إجراء بعض الاختبارات عليها ، وتحليل html للتأكد من تقديم العلامات والمحتوى بشكل صحيح.

هناك تحذير ضخم ثو. لا يعمل Prerender مع بيانات Firebase الحية. كيف يمكن ذلك؟ بيانات Firebase في الوقت الفعلي ، والاتصال مستمر. العرض المسبق لمرة واحدة ، الاتصال مغلق. لا توجد طريقة لمعرفة وقت انتهاء عرض الصفحة ، لأنه لا يمكنك حساب الطلبات.

كان لدي بعض الأفكار لإصلاح هذا:

1. قدم طلب GET مع كل اشتراك في Firebase .on("value") . تخطي الاشتراك عندما يكون طلبًا مسبقًا. تخطي طلب GET عندما يكون مستخدمًا عاديًا. لن يعمل هذا مع أحداث .on("child_*") .
2. قم بتعيين علامة العرض المسبق العام على false أعلى ملف الإدخال الرئيسي ، ثم قم بتعيين العلامة لكل مكون من مكونات الصفحة على true بمجرد تحميل البيانات. مع التصميم المناسب ، عادة ما يكون هناك _حالة تحميل_ و _حالة خطأ_ و _حالة نجاح_ لذلك في طريقة مساعد حالة الخطأ / النجاح ، قم بتعيين العلم على true .

إنه أمر مؤلم ، لكن فقط بضع صفحات ديناميكية لا يتم عرضها بشكل صحيح وتحتاج إلى معالجة خاصة. ما زلت أعتقد أن الفوائد الثابتة تفوق التكاليف.

mbleigh نتطلع إلى ما

آمل حقًا في بعض الحلول. السبب الوحيد الذي أحتاجه للخلفية هو أيضًا بطاقات Twitter و opengraphs. توفر الواجهة الخلفية المؤكدة بعض المزايا الأخرى لتطبيقات الصفحة الواحدة مثل العرض المتماثل ، ولكن من الجيد الحصول عليها. تعد علامات Twitter و OG مهمة لأي تطبيق يحتاج إلى المشاركة.

هل يمكن أن يكون هناك نوع من قاعدة شبيهة بإعادة الكتابة من شأنها أن تأمر Firebase backend لخدمة هذا الكائن / html أو ذاك من قاعدة البيانات؟

يمكن إعداد هذا الكائن مسبقًا حيث تبدأ كل مشاركة من زيارة عنوان url أو تمرير زر المشاركة أولاً.

bump .. لقد اندهشت من Firebase ثم أدركت أنه لا يمكنني استخدامه ، وقراءة هذه التعليقات ..
كما أحتاج أيضًا إلى خدمة Prerender على حد سواء للعمل. إذن ما الجديد في التطور في هذا ؟؟

احصل عليه معًا Google! أنت محرك بحث مجاني !! : يضحك:

على محمل الجد. هذا مهم جدا قد يكون هذا هو الشيء الأكثر أهمية على الإطلاق.

أعلم أنها كانت مزحة ، ولكن للتوضيح ، هل كانت هذه الملاحظة موجهة إلى بحث Google أو Google Firebase؟ واحد فقط من هؤلاء هو محرك بحث وواحد فقط من هؤلاء يوفر Firebase Hosting (وصفحات الويب المجمعة مسبقًا ليست من اختصاص أي منهما ، على الرغم من القيمة المضافة الواضحة للاستضافة للعمل بشكل أفضل مع الأدوات التي توفر ذلك).

في ملاحظة التدبير المنزلي ذات الصلة ، لا يتعلق الأمر أيضًا بأدوات Firebase (أي أداة تعقب مشكلات OSS). سأحرص على التأكد من إضافة تصويتك إلى مناقشة الأولويات ؛ ربما تكون القائمة البريدية هي أفضل مكان للتواصل مع طلبات الميزات الأساسية في المستقبل.

الأهم من ذلك ، أننا لم ننس هذا. لا يزال مهمًا جدًا بالنسبة لنا. أقل أهمية من الدمج مع Google Cloud Functions وتقديم رؤى متينة عبر Analytics و Crash Reporting و Test Labs ، لكنها لا تزال مهمة.

سأطرح هذا الأمر مرة أخرى عندما نناقش الأولويات بعد ذلك. نحن نقدر حقًا إضافة صوتك إلى التعليقات. ☼☼☼

شكرا لجهودك على
هذا هو الشيء الوحيد الذي يمنعني من استخدام Firebase كـ "مضيف" لتطبيقاتي ng1.

أنت لست وحدك هنا. واجه آخرون نفس القيد. لاحظ أنه نظرًا لأن Google يمكنها الآن فهرسة المحتوى الذي تم إنشاؤه باستخدام JavaScript ، وهناك بعض الأحكام الخاصة لفهرسة محتوى Firebase ، فمن المفترض أن تتم فهرسة بيانات Firebase غير المصادق عليها والمحملة في صفحاتك. لكن الدعم الكامل للمترجم المسبق موجود على الرادار.

katowulf تمامًا مثل headup (إذا لم تكن تعرفه بالفعل أو شاهدته) ، لكن المشكلة الرئيسية ليست زاحف google. أعتقد أن الناس يعرفون بالفعل أنهم إذا استخدموا شيئًا مثل Prerender. إن برامج الزحف الأخرى مثل LinkedIn و Facebook و Twitter وغيرها غير راضية. يريدون محتوى ثابت

samvloeberghs أعتقد ، مع ذلك ، أن الآثار المترتبة على تقديم Google لهذا الدعم هي أنه من المحتمل أن يحذو الآخرون حذوها. لذلك قصدت أن أشير إلى أنها خطوة في الاتجاه الصحيح لنشر هذا على نطاق واسع (وأنه على الأقل يعمل مع Google اليوم).

من غير المحتمل أن يتبع FB / LinkedIn / Twitter قدرة Google على المضي قدمًا بسرعة كما نريدها. سيكون هناك دائمًا لاعب رئيسي في الخلف ، ولا يمكننا ببساطة تجاهل ذلك. من ناحية أخرى ، تعمل Google على حل المشكلة من خلال العمل على NG2 ، والتي ستحتوي على تجميع من جانب الخادم باستخدام Angular Universal :) 👍

الزاوي للإنقاذ! انتظر ، هل تقول أن التعلم الآلي لن يحل كل هذا؟

لتقديم 2 سنتي ، أجد أنه يبدو أن العملاء يقدّرون بطاقات الوسائط الاجتماعية على الأقل بقدر ما يقدّرون تحسين محركات البحث. بالحديث عن المشاريع الأخيرة ، فإن Twitter / Facebook كانا الوسيلة الأساسية للعلامات التجارية للترويج لأنفسهم من خلال مشاركة الروابط إلى موقع الويب الخاص بهم.

من الواضح أن مُحسّنات محرّكات البحث لا يزال أمرًا بالغ الأهمية ، لكن هل سيكون مهاجمة بطاقات الوسائط الاجتماعية حلاً أبسط / قصير المدى؟ نظرًا لأن بطاقات الويب هي مجرد علامات وصفية ، فهل يمكنك تحديد البنية في firebase.json (على غرار قواعد الأمان)؟ يمكن لـ Firebase بعد ذلك حقن العلامات الوصفية المناسبة لبرامج زحف twitter / facebook ، على الرغم من أنني متأكد من أنها ليست بهذه البساطة 😄.

بغض النظر ، شكرًا جزيلاً على العمل الرائع ودعم المجتمع. نتطلع إلى بعض ميزات Firebase الأكثر إثارة (وظائف السحابة 👍!).

@ katowulf ، كان تعليقي "عثرة" قوية أكثر من أي شيء ... أنتم يا رفاق تقومون ببعض الأعمال الرائعة! إنني أوجه دعاباتي أكثر نحو Google ككل. ومع ذلك ، أعتقد أن Firebase هو قسم Google الجديد * الذي يجب أن يمتلك مشكلة عرض صفحة "SPA / PWA - SEO" بالكامل.

أفكاري في هذا ...

مهما كانت المنتجات التي تطرحها Google في العالم ، يجب أن تعمل بشكل لا تشوبه شائبة مع جميع الأنظمة الأساسية التي نستخدمها اليوم ، وأن تكون أمثلة مشرقة تعمل وتعكس منتجها الأصلي ، بحث Google.

لقد كانت SPA موجودة منذ فترة قصيرة الآن .. تمتلك Google اثنين منهم [Angular] و [Polymer]. يعد تطبيق SEO فيها (Meta Tags / OpenGraph / Schema) بمثابة Blackbox رئيسي (ما لم تكن نينجا خلفي). كان خبرًا رائعًا أن بدأ بحث Google في معالجة JS ، لكن هذا بالتأكيد نصف المعركة فقط (ربما أقل).

يبدو Firebase ، كونه واجهة خلفية كخدمة (BaaS) ، وكأنه مجموعة Google الجديدة المثالية لتسهيل عرض صفحة SPA بالكامل. أعلم أنكم سوف تتعاملون مع الأمر ، لكنني أشعر بشدة أن هذا يجب أن ينتمي إلى ميزة حرجة / ذات أولوية قصوى.

تخيل قراءة هذا العنوان ...

تقديم القاعدة النارية ...
مُحسنات محركات البحث الجديدة والمحسّنة لجميع تطبيقات الصفحة الواحدة (SPA) وتطبيقات الويب التقدمية (PWA's) خارج الصندوق!

سوف يتدفق المطورون: +1:

أردت فقط أن تتناغم بسرعة لأن لدينا هذا بالتأكيد على رادارنا. إنه مهم ، لكن هناك الكثير من الأشياء الأخرى (كما ذكر كاتو). لدينا بعض الأفكار حول بعض الطرق الرائعة لمعالجة هذه المشكلة ، لكن لديهم بعض التبعيات التي يتعين علينا التخلص منها أولاً. حاول التحلي بالصبر واعلم أن هذا بالتأكيد في أذهاننا!

حسنا هذا مخيب للآمال. أجد نفسي الآن أبحث عن بدائل Firebase ...

لقد مر ما يقرب من 3 سنوات ...

أي تحديث على هذا.. ؟

ألا يجب أن يعمل هذا الآن لأن Firebase تمتلك divshot؟ تحديث PLZ!

نحن ندرك جيدًا الرغبة في هذا النوع من الوظائف ، ومن أولوياتنا تقديم بعض الحلول الأفضل هنا. ما زلت ليس لدي أي نوع من الجدول الزمني للإعلان ، لكننا لم ننسكم يا رفاق.

+1

:( :(

توصلنا إلى نتيجة مماثلة. ماذا رأيت أيضا؟ ؛)

أنا فقط أستخدم وظائف Firebase كنقطة نهاية لرابط المشاركة ثم أعيد توجيه رابط باستخدام JavaScript.

ربما تكون قد شاهدت هذا أو لم تره ، ولكن وظائف السحابة مدمجة الآن مع Firebase Hosting !!!

يمكن اعتبار هذا الحل الأساسي الخاص بنا للعرض من جانب الخادم باستخدام Firebase Hosting. استمتع!

mbleigh حسنًا ، لذا إذا كان لدي ملف رأس عام به بيانات وصفية مثل ما يلي ، في الوقت الحالي لا يتم نسخ هذا في الواجهة الأمامية. إذا قمت بتثبيت وظائف السحابة ، فهل يجب أن يكون هذا هو كل ما أحتاجه لتشغيل هذه الميزة.

<meta name="description" content="{{ pageDescription }}">

رائع ، شكرا على التحديث.

في 17 مايو 2017 5:39 مساءً ، كتب "Michael Bleigh" [email protected] :

ربما تكون قد شاهدت هذا أو لم تره ، ولكن وظائف السحابة مدمجة الآن
مع Firebase Hosting https://firebase.google.com/docs/hosting/functions
!!!

يمكن اعتبار هذا الحل الأساسي الخاص بنا للعرض من جانب الخادم
مع استضافة Firebase. استمتع!

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-302268864 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbtWCdygdw4ozixK5_XcL2Dlznp4Jks5r65M-gaJpZM4CtPYG
.

أدرك أن هذا قد لا يكون أفضل مشكلة بالنسبة لهذه التعليقات ، لكن البحث في Google عن مشاكلي قادني إليه ويبدو أن هناك بعض المناقشات النشطة ، لذا أرجوك سامحني!

ما أود رؤيته لحل مشكلة عرض قوالب الرسم البياني المفتوحة للمواقع الاجتماعية في SPAs المستضافة على Firebase - هو القدرة على تحميل الرصيد عبر وكيل المستخدم.

أود أن أكون قادرًا على استخدام وظائف السحابة لانتزاع بعض بيانات القوالب من memcache / cloudql وتقديم علامات القالب إلى النظام الأساسي الاجتماعي المطلوب ، ولكن ارجع إلى الاستضافة الثابتة لجميع العملاء الآخرين. ثم لن نحتاج إلى عرض كامل من جانب الخادم لجميع الطلبات.

cdharris Totally ، ATM ، إعادة كتابة كل الطلبات إلى وظيفة حاولت استخدام window.location لإجراء إعادة توجيه إضافية (للعميل / الزائر) إلى الاستضافة الثابتة ، ولأغراض تحسين محركات البحث الخاصة بي لم تنجح ، ربما للأغراض الاجتماعية.

mbleigh هل هناك أي خيار لإعادة كتابة طلب من برامج الزحف / مواقع التواصل الاجتماعي

يمكن أن ينجح اتخاذ قرار ما يجب إرجاعه في وظيفة Firebase. يمكننا أن نقول: هل الطلب يأتي من Facebot؟ ثم أعد علامات الرسم البياني المفتوحة هذه. إذا لم يكن كذلك ، فقم بإرجاع index.html. ولكن كيف يمكنني إرجاع index.html الرتق من وظيفة Firebase؟

fs.readFileSync ('./ index.htm')

في 13 سبتمبر 2017 ، الساعة 4:34 صباحًا ، كتب "Birowsky" [email protected] :

يمكن أن ينجح اتخاذ قرار بشأن المحتوى في وظيفة Firebase. يمكننا أن نقول:
هل الطلب قادم من Facebot؟ ثم أعد علامات الرسم البياني المفتوحة هذه. ان لم،
إرجاع index.html. ولكن كيف يمكنني إرجاع ملف index.html الرتق من ملف
وظيفة Firebase؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329140134 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbrXQNbVMhRmeZQTbx3Z3vi0c1HXTks5sh728gaJpZM4CtPYG
.

megamindbrian هل يعني ضمنيًا أن الوظائف لها حق الوصول إلى الملفات المستضافة؟ هل هو موثق في أي مكان؟ شكرا على أي حال!

نعم. هذه هي الطريقة التي أتذكر استخدامها ، سؤال جيد أحاول العثور على مستندات.

في 13 سبتمبر 2017 ، الساعة 7:09 صباحًا ، كتب "Birowsky" [email protected] :

megamindbrian https://github.com/megamindbrian هل يعني ضمناً أن ملف
وظائف الوصول إلى الملفات المستضافة؟ هل هو موثق في أي مكان؟
ثانكس ، على أي حال!

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

هنا واحد
https://stackoverflow.com/questions/42960506/how-can-i-read-and-write-to-firebase-storage-from-within-cloud-functions-for-fir

في 13 سبتمبر 2017 ، الساعة 7:09 صباحًا ، كتب "Birowsky" [email protected] :

megamindbrian https://github.com/megamindbrian هل يعني ضمناً أن ملف
وظائف الوصول إلى الملفات المستضافة؟ هل هو موثق في أي مكان؟
ثانكس ، على أي حال!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

يستخدم هذا الدليل دليلًا مؤقتًا ولكني أعتقد أنه يعمل أيضًا مع الملفات
قمت بتحميله بجانب مشروعك. قد يكون غير قابل للتغيير وهذا هو السبب
المثال هو إلغاء تحميل الملف لحفظه في مكان آخر
https://firebase.google.com/docs/storage/extend-with-functions

في 13 سبتمبر 2017 ، الساعة 7:12 صباحًا ، كتب [email protected] "Brian Cullinan":

هنا واحد https://stackoverflow.com/questions/42960506/how-can-i-
القراءة والكتابة إلى Firebase التخزين من داخل وظائف السحابة مقابل التنوب

في 13 سبتمبر 2017 ، الساعة 7:09 صباحًا ، كتب "Birowsky" [email protected] :

megamindbrian https://github.com/megamindbrian هل يعني ضمناً أن ملف
وظائف الوصول إلى الملفات المستضافة؟ هل هو موثق في أي مكان؟
ثانكس ، على أي حال!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

عذرًا ، ما زلت لا أرى مقدمة مناسبة لكيفية ارتباط الوظائف من الناحية المفاهيمية بالملفات المستضافة. إذا كنت مهتمًا بالشرح ، فقد حصلت على بعض النقاط لك: https://stackoverflow.com/q/46192570/592641

كان بإمكاني أن أرى نفسي أجيب على ذلك بأمثلة رمزية ، لكن ذلك لم يكن واضحًا
أنه من داخل وظيفتك يمكنك الرد بمحتوى من ملف بتنسيق
مشروعك؟ إنها ليست إعادة توجيه.
سأبحث عن المزيد من التعليمات البرمجية.

في 13 سبتمبر 2017 ، الساعة 7:18 صباحًا ، كتب "Birowsky" [email protected] :

عذرًا ، ما زلت لا أرى مقدمة مناسبة لكيفية عمل الوظائف
من الناحية المفاهيمية المرتبطة بالملفات المستضافة. إذا كنت مهتمًا بالشرح ، فقد حصلت
بعض النقاط لك: https://stackoverflow.com/q/46192570/592641

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329182385 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbnCSoaKUuVKUnfha5A-4K-p76kZ3ks5sh-QygaJpZM4CtPYG
.

megamindbrian لقد حاولت للتو fs.readFileSync('./index.html') لكن لسوء الحظ ، الملف غير موجود. كنت آمل أيضًا في العثور على الملفات المستضافة في دلو تخزين تم إنشاؤه ضمنيًا ، ولم يحالفني الحظ. كيف ستمضي قدما؟

إذا قمت بتداخل دليل الاستضافة public داخل دليل functions ، فسيكون متاحًا هناك.

Birowsky نعم ، إليك كيفية قراءة ملف من وظيفة سحابية ، مثل index.js:

const page = fs.readFileSync(__dirname + '/facebook-meta.html').toString();

ولكن إذا كان تخطيط مشروعك هو:

project/
project/src (<- actual source of app)
project/functions ( <- firebase functions)
project/dist (<- build output)

ستحتاج إلى نسخ الملفات ذات الصلة من / dist in to / function

هذا العدد له ألموس 3 سنوات (حتى الآن) ومازال لم يحالفه الحظ في هذه المرحلة ؟؟؟؟

ربما يعني ذلك أن Google ستتخلى عن Firebase في منتصف دعم الجميع
تطبيقاتنا.

الحل الرسمي لهذه الفئة من المشاكل هو استخدام وظائف السحابة
لإجراء عرض من جانب الخادم للمحتوى الذي يجب أن يكون مرئيًا للثابت
الزواحف:

https://firebase.google.com/docs/hosting/functions

هذا هو حل أكثر قوة وعمومية يسمح لجميع أنواع
أشياء رائعة!

إذا كنت تشعر بقوة أنه لا يزال هناك شيء مفقود ، يرجى إعطائنا
حالة استخدام مفصلة حتى نتمكن من التفكير في كيفية معالجتها! :)

في الخميس ، 14 سبتمبر 2017 ، الساعة 3:57 مساءً Brian Cullinan [email protected]
كتب:

ربما يعني Google مع التخلي عن Firebase في منتصف دعم الكل
تطبيقاتنا.

يوم الخميس 14 سبتمبر 2017 الساعة 3:52 مساءً ، tofanelli [email protected]
كتب:

هذا العدد له ألموس 3 سنوات (حتى الآن) ومازال لم يحالفه الحظ في هذه المرحلة ؟؟؟؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
<
https://github.com/firebase/firebase-tools/issues/33#issuecomment -329630338
،
أو كتم الخيط
<
https://github.com/notifications/unsubscribe-auth/AX5XbhBSDSl6TStSv7M02Dx0brb9MOPbks5sia44gaJpZM4CtPYG

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329631266 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAD_iI6L-yu3RTECI88a2y_ZOzIxdDQks5sia9rgaJpZM4CtPYG
.

mbleigh هل يمكنك استخدام وظائف السحابة على جذر مجال Firebase ، حتى الآن؟

نعم ، إذا كنت أفهمك بشكل صحيح. هل واجهت مشكلة من قبل؟

في الخميس ، 14 سبتمبر 2017 ، 6:38 مساءً Brian Cullinan [email protected]
كتب:

mbleigh https://github.com/mbleigh هل يمكنك استخدام وظائف السحابة على ملف
الدليل الجذر firebase حتى الآن؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329653711 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAD_g7BV3TMM_5nVX92_-3ai_mZHfHBks5sidUvgaJpZM4CtPYG
.

تضمين التغريدة

هذا حل أكثر قوة وعمومية يسمح لجميع أنواع الأشياء الرائعة!

يجعل SSR نظامنا أكثر تعقيدًا 😢
أعتقد أن العرض المسبق أكثر برودة ليس دائمًا ولكن كثيرًا 💡
مثل Facebook OGP و Twitter Cards و SEO لغير Google

mbleighmegamindbrian شكرا لرسائلك. لقد قدمت استضافتي لتوجيه كل الطلبات إلى وظيفتي والاستجابة index.html التي يتم استضافتها في functions/build/index.html للعملاء. لكني لا أعرف كيف أؤكد أن الطلب قادم من FaceBot؟ لقد حاولت استخدام أدوات تصحيح أخطاء facebook للوصول إلى عنوان url لموقع الويب الخاص بي ، وافترضت أنه سيتم تشغيل وظيفة السحابة ، لكنها لم تكن كذلك. لست على دراية بالتطوير الخلفي ، هل يمكنك أن تعطيني بعض التلميح؟ شكر.

عند استخدام أداة Facebook ، تأكد من استخدام الزر الذي يقرأ شيئًا ما
مثل "جلب نسخة حديثة" بالقرب من المعاينة.

في الثلاثاء ، 17 أكتوبر ، 2017 الساعة 8:29 صباحًا ، كتب Jude [email protected] :

mbleigh https://github.com/mbleighmegamindbrian
https://github.com/megamindbrian شكرا على رسائلك. عندي
جعلت استضافتي توجه كل طلبات وظيفتي واستجابتي
index.html الذي يتم استضافته في الوظائف / build / index.html للعملاء. لكن
لا أعرف كيف أؤكد أن الطلب قادم من FaceBot؟ لقد حاولت
باستخدام أدوات تصحيح أخطاء facebook للوصول إلى عنوان url لموقع الويب الخاص بي ، افترضت أن
سيتم تشغيل وظيفة السحابة ، لكنها لم تكن كذلك. لست على دراية
تطوير الخلفية ، هل يمكن أن تعطيني بعض التلميح؟ شكر.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-337266581 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbrCQ3mowcUnJjWYWsaiScoN1y4l0ks5stMfcgaJpZM4CtPYG
.

-
إشعار السرية: محتويات رسالة البريد الإلكتروني هذه وأي محتوى
المرفقات مخصصة فقط للمرسل إليه (المرسلون) وقد تحتوي على
معلومات سرية و / أو مميزة وقد تكون محمية قانونًا
من الإفشاء. ثم يتم مشاركتها مع شركات التكنولوجيا والروبوتات والمتسللين
الوكالات الحكومية والمسوقين. أمان هذه الرسالة لا يوجد ،
ويمكن مشاركته على Instagram في أي وقت. إذا كنت موافقًا على هذا ،
يرجى الرد. لا يوجد حقًا أي أمان أو خصوصية في أي مكان. إذا
أنت لا توافق على أنك قد ترغب في الذهاب للتخييم والتحدث مع الناس وجهًا لوجه
كما في العصور القديمة.

هل هناك أي شيء في سجلات Firebase مثل "بدأ تنفيذ الوظيفة"؟

يوم الثلاثاء 17 أكتوبر 2017 الساعة 8:37 صباحًا ، بريان كولينان [email protected]
كتب:

عند استخدام أداة Facebook ، تأكد من استخدام الزر الذي يقرأ
شيء مثل "جلب نسخة حديثة" بالقرب من المعاينة.

في الثلاثاء ، 17 أكتوبر ، 2017 الساعة 8:29 صباحًا ، كتب Jude [email protected] :

mbleigh https://github.com/mbleighmegamindbrian
https://github.com/megamindbrian شكرا على رسائلك. عندي
جعلت استضافتي توجه كل طلبات وظيفتي واستجابتي
index.html الذي يتم استضافته في الوظائف / build / index.html للعملاء. لكن
لا أعرف كيف أؤكد أن الطلب قادم من FaceBot؟ لقد حاولت
باستخدام أدوات تصحيح أخطاء facebook للوصول إلى عنوان url لموقع الويب الخاص بي ، افترضت أن
سيتم تشغيل وظيفة السحابة ، لكنها لم تكن كذلك. لست على دراية
تطوير الخلفية ، هل يمكن أن تعطيني بعض التلميح؟ شكر.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-337266581 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbrCQ3mowcUnJjWYWsaiScoN1y4l0ks5stMfcgaJpZM4CtPYG
.

-
إشعار السرية: محتويات رسالة البريد الإلكتروني هذه وأي محتوى
المرفقات مخصصة فقط للمرسل إليه (المرسلون) وقد تحتوي على
معلومات سرية و / أو مميزة وقد تكون محمية قانونًا
من الإفشاء. ثم يتم مشاركتها مع شركات التكنولوجيا والروبوتات والمتسللين
الوكالات الحكومية والمسوقين. أمان هذه الرسالة لا يوجد ،
ويمكن مشاركته على Instagram في أي وقت. إذا كنت موافقًا على هذا ،
يرجى الرد. لا يوجد حقًا أي أمان أو خصوصية في أي مكان. إذا
أنت لا توافق على أنك قد ترغب في الذهاب للتخييم والتحدث مع الناس وجهًا لوجه
كما في العصور القديمة.

-
إشعار السرية: محتويات رسالة البريد الإلكتروني هذه وأي محتوى
المرفقات مخصصة فقط للمرسل إليه (المرسلون) وقد تحتوي على
معلومات سرية و / أو مميزة وقد تكون محمية قانونًا
من الإفشاء. ثم يتم مشاركتها مع شركات التكنولوجيا والروبوتات والمتسللين
الوكالات الحكومية والمسوقين. أمان هذه الرسالة لا يوجد ،
ويمكن مشاركته على Instagram في أي وقت. إذا كنت موافقًا على هذا ،
يرجى الرد. لا يوجد حقًا أي أمان أو خصوصية في أي مكان. إذا
أنت لا توافق على أنك قد ترغب في الذهاب للتخييم والتحدث مع الناس وجهًا لوجه
كما في العصور القديمة.

megamindbrian تم تشغيل وظيفة إذا قمت بالوصول إلى موقع الويب الخاص بي باستخدام المتصفح. لكن لم يتم تشغيله بعد استخدام أداة facebook لجلب بيانات الصفحة.

judewang ألق نظرة على https://firebase.google.com/docs/hosting/functions#when_is_cached_content_served

لإجراء اختبار سريع وقذر ، يمكنك محاولة إضافة بعض معاملات الاستعلام العشوائية إلى عنوان URL الذي تم اختباره.

لذا كان السؤال الأولي هو كيفية استخدام العرض المسبق. لا يحل هذا الحل مشكلة تكامل العرض المسبق ، ولكنه يحل الرسم البياني المفتوح لتطبيق صفحة واحدة.

1. في نصي البرمجي ، أنسخ public/index.html إلى functions/hosting/index.html
2. في firebase.json أضفت قاعدة إعادة الكتابة للإشارة إلى وظيفة سحابية تسمى "المضيف"

"hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "**",
        "function": "host"
      }
    ]
  }

1. أحدد وظيفة سحابية تسمى host . في معظم الحالات ، يُرجع هذا الملف index.html الذي نسخته إلى functions/hosting/index.html ، ولكن إذا كان الوكيل أحد موزعي الرسم البياني المفتوح المعروفين ، فأنا أعيد بيانات قاعدة البيانات بتنسيق الرسم البياني المفتوح بناءً على طريق.

exports.host = functions.https.onRequest((req, res) => {
  var userAgent = req.headers['user-agent'];
  if (userAgent.startsWith('facebookexternalhit/1.1') ||
    userAgent === 'Facebot' ||
    userAgent.startsWith('Twitterbot')){

    //getOpenGraph() parses the path, and gets some data from the firebase database to construct open graph data.
    // eg: <meta property="og:description" content="My super cool webpage." /> <meta property="og:title"...

    res.status(200).send(getOpenGraph(req.path));
  }
  else{
    //optional - turn on caching: res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
    res.status(200).send(fs.readFileSync('./hosting/index.html').toString());
  }
});

وأعتقد أن كل شيء. أتمنى أن يساعد هذا بعض الناس!

يجب أن أقول أن هذا أمر مخيب للآمال ، فالمنافسون الجدد يعانون من ذلك ، مثل https://www.netlify.com/features/ ، مما يجعله بالتأكيد أكثر جاذبية لتطبيقات الويب التي تحتاج إلى التكامل الاجتماعي / تحسين محركات البحث

Firebase يقتلها للجوّال / يتفاعل مع المحتوى الأصلي ، وأنا أستمتع به حقًا كمنصة عامة ، لكن هذا عيب كبير جدًا لتطبيقات الويب IMO.

بشكل عام ، وجدنا أن المحتوى الذي يحتاج إلى العرض المسبق هو أيضًا المحتوى الذي يتم تقديمه بشكل أفضل من خلال العرض من جانب الخادم (لأسباب تتعلق بالأداء والتحميل الأول). العرض العام غير موجود في خارطة الطريق الفورية لدينا لهذا السبب.

ومع ذلك ، فإننا نستمع إلى التعليقات حول الرغبة في أن يكون تكامل الوظائف أكثر مرونة للسماح بتنفيذ الوظيفة "أحيانًا". نظرًا لأن Firebase Hosting يعتمد بشكل كبير على تخزين CDN المؤقت ، يصعب تحقيق هذا النوع من المرونة تقنيًا بالنسبة لنا. سنواصل الاستماع إلى التعليقات ونحاول إيجاد طرق لجعل النظام الأساسي أفضل لحالة الاستخدام الخاصة بك. :ابتسامة:

واجهة مستخدم في Firebase لتوصيل الوظائف مباشرة بمقدمة المجال
سيصلح الاسم حالة الاستخدام الخاصة بي.

https: //us-central1-...dsaflk؛ sdafkljsdafkl؛ jsdf؛
lkjsadfkljasdfkljsdaflk.cloudfunctions.net

يوم الجمعة ، 5 يناير 2018 الساعة 3:33 مساءً ، مايكل بليغ إخطارات @github.com
كتب:

بشكل عام وجدنا أن المحتوى الذي يحتاج إلى عرض مسبق هو أيضًا
يتم تقديم المحتوى بشكل أفضل من خلال العرض من جانب الخادم (للأداء و
أسباب الحمل الأول). العرض العام غير موجود في خريطة الطريق الفورية الخاصة بنا
لهذا السبب.

ومع ذلك ، فإننا نستمع إلى التعليقات حول الرغبة في
تكامل الوظائف ليكون أكثر مرونة للسماح بوظيفة "في بعض الأحيان"
تنفيذ. نظرًا لأن استضافة Firebase تعتمد بشكل كبير على تخزين CDN لهذا النوع
من الصعب تحقيق المرونة من الناحية الفنية بالنسبة لنا. سنكمل
للاستماع إلى التعليقات ومحاولة إيجاد طرق لتحسين النظام الأساسي
حالة الاستخدام الخاصة بك. 😄

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-355683821 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX5XbtVDQSPOIAZFyozujQQUektf2WM1ks5tHqM8gaJpZM4CtPYG
.

-
درست الهندسة

إشعار السرية: محتويات رسالة البريد الإلكتروني هذه وأي محتوى
المرفقات مخصصة فقط للمرسل إليه (المرسلون) وقد تحتوي على
معلومات سرية و / أو مميزة وقد تكون محمية قانونًا
من الإفشاء. ثم يتم مشاركتها مع شركات التكنولوجيا والروبوتات والمتسللين
الوكالات الحكومية والمسوقين. أمان هذه الرسالة لا يوجد ،
ويمكن مشاركته على Instagram في أي وقت. إذا كنت موافقًا على هذا ،
يرجى الرد. لا يوجد حقًا أي أمان أو خصوصية في أي مكان. إذا
أنت لا توافق على أنك قد ترغب في الذهاب للتخييم والتحدث مع الناس وجهًا لوجه
كما في العصور القديمة.

mbleigh ألا تتعارض وجهة النظر هذه إلى حد ما مع روح عدم وجود خادم ، واستخدام مزود BaaS / FaaS مثل Firebase؟ مع الاتجاه نحو SPA على مدار السنوات القليلة الماضية ، تعد هذه حالة استخدام شائعة إلى حد ما ، لدرجة أنه تم التعامل معها من قبل المنافسين مثل netlify و roast على سبيل المثال. على الرغم من أنها أصغر حجمًا ، إلا أن الاستضافة تبدو منطقية ، وتوفر أوقات تحميل أسرع ، بالإضافة إلى قابلية الاكتشاف وإمكانية المشاركة المهمة

بدلاً من إضافة تكاليف إضافية للتطوير والصيانة للعملاء ، أو خدمة عرض مسبق اختيارية أو على الأقل ، فإن القدرة على التكامل مع خدمة جهة خارجية مثل prerender.io ستكون بمثابة تحسن كبير.

يعد Firebase حقًا نظامًا أساسيًا رائعًا ولكنه يبدو أكثر توجهاً نحو الجوّال ، مع كون الاستضافة هي الجزء الباهت الوحيد بالنسبة لي.

شكرا للاستجابة السريعة.

تضمين التغريدة

بشكل عام ، وجدنا أن المحتوى الذي يحتاج إلى العرض المسبق هو أيضًا المحتوى الذي يتم تقديمه بشكل أفضل من خلال العرض من جانب الخادم (لأسباب تتعلق بالأداء والتحميل الأول).

بصرف النظر عن حجةPushplaybang الفورية ، يجب أن أختلف مع حجتك. لسبب واحد ، الأمر متروك لمطور التطبيق (أي ليس لكم يا رفاق) لاتخاذ قرارات في هذا المجال. يجب موازنة اعتبارات أداء الصفحة فقط مع القرارات المعمارية الأخرى التي لا تقل أهمية.

يجب أن تلجأ التطبيقات ذات الصفحة الواحدة أو أقسام التطبيقات إلى درجة معينة من العرض من جانب العميل ، وللأسف ، فإن برامج الزحف ، بما في ذلك برامج Google ، ليست جيدة جدًا حتى الآن في فهرسة هذه الصفحات. اضطررت إلى اللجوء إلى PrerenderIO بعد شهور من المحاولات الفاشلة للسماح لـ Google بفهرسة مواقع الويب الخاصة بي بشكل صحيح ، وهو الأمر الذي أجبرني على الاحتفاظ بنهج يعتمد على خادم express.js ، __للمشكلة فقط في الفهرسة__.

فكر في موقع ويب يحتوي على صفحة /product/**.html تعرض أي منتج بناءً على جانب العميل الذي اكتشف عنوان url عميقًا. الأساس المنطقي وراء هذا التصميم هو أن تحميل صفحة منفصلة فعلية لمنتج ، حتى مع مراعاة المستعرض والتخزين المؤقت cdn ، ليس سلسًا من منظور UX مثل تحميل بيانات منتج آخر وعرضها أثناء تغيير عنوان url. يقضي العملاء معظم وقتهم على صفحات المنتجات عند التصفح للشراء أثناء تصفحهم لموقع التجارة الإلكترونية وغالبًا ما ينتقلون إلى منتجات أخرى عبر روابط "المنتجات ذات الصلة" أو روابط بحث ajax في الصفحة.

نحن عالقون مع آلية _escaped_fragment_ السخيفة (IMHO) خشية أن نعاقب على إخفاء الهوية ... هل تجد Google صعوبة في توظيف مهندسين مع حلول أنيقة لهذه المشكلة في كل مكان ؟؟

أجد حتى الغياب التام لقسم فهرسة موقع الويب / تطبيق الويب في الوثائق __غير مبرر__.
قد تهيمن تطبيقات الأجهزة المحمولة على السوق الاستهلاكية ولكن ماذا عن B2B؟ تعمل معظم أقسام المكاتب على أجهزة كمبيوتر سطح المكتب. إن فهرسة مواقع سطح المكتب للوصول إلى أقسام البحث والتطوير أو الشراء ليس "أمرًا ممتعًا" ، بل إنه أمر بالغ الأهمية لشركات موردي B2B.

إذا لم يكن Firebase / Google مهتمين بهذا لأن التطبيقات البراقة التي تعمل على أدوات لامعة تحقق المزيد من الأرباح ، فسيكون من الجيد معرفة ذلك ؛ 4 سنوات من إعطاء إجابات مراوغة لمتبني التكنولوجيا المخلصين هي إهانة لذكاء أي شخص.

صراخ؟ نعم ، ولكن أنا الشخص الذي يتعين علي تبرير تكاليف البنية التحتية الإضافية لأوقات تطوير إضافية وسلوكيات غير متوقعة من برامج الزحف لعملائي.

أربع سنوات من فتح هذه القضية تبدو سخيفة بعض الشيء. cleverplatypus - لا يمكن أن أتفق أكثر مع

منطقة المشكلة هذه بشكل عام ليست شيئًا توقفنا عن التفكير فيه ، ولكن ما زلنا لا نملك أي خطط فورية للعرض المسبق للجزء الهارب.

أدرك أنه توجد بالتأكيد أوقات يمكن أن يستفيد فيها تطبيق الصفحة الواحدة الثابت من العرض المسبق ؛ ومع ذلك ، ما زلت أعتقد أنه في غالبية (وليس كل) حالات هذه الأنواع من المواقع يتم تقديمها بشكل أفضل من خلال العرض من جانب الخادم الذي يمكنه تمهيد SPA من أي عنوان URL.

هدفنا هو جعل Firebase Hosting منصة رائعة لتقديم جميع أنواع تجارب الويب. بينما أقدر التعليقات الصريحة والعاطفية المقدمة في هذا الموضوع ، لدينا موارد محدودة وعلينا تحديد أولويات العمل الذي نعتقد أنه سيكون له أكبر تأثير على قاعدة عملائنا بشكل عام. إذا كنت ترغب في المساعدة في تغيير رأينا بشأن تحديد أولويات الميزة التي تشعر بشدة حيالها ، فإن أفضل طريقة هي تقديم طلب ميزة - يتم تسجيلها وتساعد في توجيهنا نحو العمل الذي يطلبه مجتمع المطورين لدينا.

سأغلق هذا الموضوع لأنني لا أعتقد أنه يوجد حقًا أي مكان متبقي للمحادثة ، لكنني أشجع أي شخص لا يتم تقديمه جيدًا من خلال تكامل وظائف السحابة لدينا لتقديم طلب ميزة للعرض المسبق بحيث يمكننا أن نرى بشكل مباشر حجم الطلب!

شكرًا لاستخدامك استضافة Firebase ، الكل 😸