Как да получите предимства от странично рендериране от сървъра (разбъркване, индексиране, възможност за търсене) без изграждане на SSR логика

Няма да чуете много по темата за визуализацията от страна на сървъра (SSR) от много стартирания на blockchain. Ако не става дума за нов механизъм за мащабиране, токен икономическа структура или някаква друга революционна идея, можете да настроите или продължите да превъртате. Въпреки това, има много неща, за които да говорим като стартиране на blockchain, които не са свързани с протоколния слой или други изследвания на ръба на кървенето. Все още се сблъскваме със същите проблеми, които редовните стартъпи имат - с малко допълнителна магия. В нашия случай ние изграждахме бързо и искахме да се откажем от тежестта на внедряването на решение на сървър за визуализация (SSR) в нашия код. Открихме, че можем да извлечем всички предимства на SSR решение, без да се налага да прилагаме SSR в нашия код.

Решихме следните задачи:
1. Предаване от страна на сървъра за нашето приложение React / Redux - но само за ботове :)
2. Разглобяване на връзката (визуализация на изображения и допълнителни данни при публикуване в Twitter, слаби, facebook)
3. Индексиране, генериране на Sitemap и други

Сървърно рендериране

Ние сме клиентско приложение React / Redux, използващо redux-saga. Когато за първи път създадохме приложението, се преместихме бързо и се съсредоточихме върху #SHIPLING. Не приложихме SSR. Бързо открихме, че се обвързваме в рамка като Next или други, които ще ограничат нашия код и ще ни направят твърде разчитащи на външна битова библиотека. Ние също решихме да не изграждаме собствена логика за изобразяване от страна на сървъра от нулата. Това щеше да добави прекалено много случаи, сложност към нашия код, отделна логика за сървъра срещу фронтенда и като цяло тежки архитектурни последици. Избягвахме това на всяка цена и тези решения ни дадоха гъвкавост и гъвкавост да се движим бързо и да пропуснем прилагането на тежка логика на сървъра, като все пак имаме всички предимства на SSR решение.

КАКВО РАЗБИРАМЕ

Приложихме го само за ботове. Приложението ни се зарежда бързо и е оптимизирано за по-бавни интернет връзки. Не е необходимо да предоставяме на потребителите на сървъра визуализация. Всъщност това би изисквало прогресивно зареждане на определени компоненти при автентификация и извличане. Много сравнителни и изследователски проучвания се възползват от предимствата на сървърното рендериране (SSR) и просто не са много. Това ускорява приложението леко - но времето до първото взаимодействие не се променя драстично. Освен това трябва да съставите солидна инфраструктура за мащаб и активен стартиран процес срещу съхранение на вашия пакет в CDN. Като цяло SSR изглеждаше като по-големи проблеми, отколкото би струвало.

И така, ние работихме усилено, за да зарадваме нашите приятели на бота - Slack, Twitter, Google, DuckDuckGo, Bing и други. :). И нека ви уверя, че всички са доста доволни от нашето решение.

КАК ДА СЕ ИЗПЪЛНИХ

1. Използвахме ламбда функция с нашия CloudFront CDN за пренасочване на ботове към кеш услуга (повече за това по-долу), наречена prerender.io
2. Програмно обновяваме кеша всеки път, когато се случи събитие, което актуализира съдържанието на страницата (използвайки техните api)
3. Планирахме добра добра, стратегическа итерация - в крайна сметка просто ще стартираме собствения си кеш (не е толкова трудно) и ще се откажем от използването на Prerender

РЕЗУЛТАТИТЕ

Ботовете получават напълно рендирана страница за по-малко от секунда. Мета таговете, връзките и всичко останало са индексируеми и сега могат да бъдат открити от Google. Разплитането се случва красиво - просто вижте това в Twitter:

По-долу ще говоря повече. :)

Функциите на ламбда (или бот пренасочване):

Добавяне на заглавки за пренасочване Lambda функция:

Инициирайте функция за пренасочване на ламбда:

Първият фрагмент добавя съответните заглавки при поискване от зрителя. Вторият фрагмент задейства поведението на маршрутизиране / прокси при заявка за начало. И двете са чисти ламбда функции, базирани на кода, намерен в това репо за Github. В CloudFront допълненията трябва да изглеждат по следния начин:

За да работи това, вие също трябва да включите персонализирани заглавки за искане на бот, който винаги да препраща:

Предварително изобразяване:

Планираме скоро да изградим собствена услуга. Междувременно Prerender се справи добре за нас. Prerender отива на страницата ви, изчаква, докато всичко се рендерира, записва представения html и го кешира. Когато изпращате трафик на бот към него, той обслужва страницата веднага от кеша. Изпращаме заявка за API за предварително представяне, когато нашият сайт генерира нова страница или актуализира съществуваща. Тази заявка загрява кеша на тази страница. Тъй като клиентското приложение използва React Helmet, всички мета тагове се изобразяват и за сървъра.

Unfurling:

Когато споделяте един от нашите щедрости в Twitter, изглежда така:

На Slack изглежда така:

Във Facebook изглежда така:

За да постигнем това разгръщане, трябваше да направим 3 неща:
1. Уверете се, че нашите мета тагове са представени правилно на ботове (Вече е обхванато по-горе) - @mathowie описва в тази статия какво трябва да поставите във вашите мета тагове
2. Създайте услуга, която прави екранна снимка всеки път, когато се създаде или актуализира нова награда
3. Включете мета маркер с изображението на екрана / предварителен преглед от стъпка 2

Ние наричаме функция без сървър, за да направим екранна снимка всеки път, когато наградата се обновява или променя. В фрагмента на кода по-долу използваме кукловод, за да направим екранна снимка и да я качим директно в S3. Това дава възможност на CloudFront да обслужва изображението чрез своя CDN. Пълното репо за Github за функцията на екрана и операциите без сървър можете да намерите тук. Имайте предвид, че функцията може да се използва в леко променен формат, за да замени Prerender.

В приложението React използваме React Helmet и обслужваме съответните маркери за изображения. Имайте предвид, че ако вашето изображение е хоствано в крайна точка на https, трябва да използвате URL адреса на защитен образ за мета маркерите на Open Graph (OG) на Facebook. Slack и много други доставчици по подразбиране ще прочетат или маркери на Twitter или OG маркери. Нашият код, който настройва тези мета тагове, може да бъде намерен тук и в фрагмента по-долу:

Индексиране и сайтове за търсачки:

За да определите дали търсачките могат правилно да преглеждат и четат вашата страница:

1. Използвайте Fetch as Google, за да изобразите вашата страница и се уверете, че техният браузър без глава може да чете правилно страниците ви
2. Уверете се, че няма останки от ES6 код (може да се изненадате)
3. Поддържайте правилно оптимизираните си Sitemaps до данни и вашите страници

Извличане като Google:

Този е прост. Ако страницата се показва за вас, вие сте на ясно. Ако не, тогава имате проблем, който трябва да проучите. В нашия случай Google не успя да изобрази страниците ни, в резултат на което просто видяхме празна страница. Проблемът ни беше бездомният ES6 код, който лежи наоколо. Една от библиотеките, които използвахме, носеше отговорност и нарушаваше Google, добива!

Няма остатъци от ES6:

Google работи с версия 41 на Chrome за преглед на вашата страница. Това означава, че не е съвместим с много съвременни ES6. За да сте сигурни, че нямате остатъци от ES6, трябва да изпълните следната команда на пакета си с JavaScript: es-check es5 [js-filename] .js - verbose. Ако бъдат намерени останки на ES6, ще бъде изхвърлена грешка и ще трябва да проучите допълнително. В нашия случай IPFS-API прекъсваше нашия пакет за Google и други ботове в мрежата, тъй като IPFS-API и неговите зависимости не се прехвърлят в ES5. Ако стартирате стартиране на blockchain и включите тази библиотека в пакета си, определено трябва да проучите дали приложението ви среща същите проблеми.

Малък курс за обхождането и индексатора на Google:

Ако решите да не се справяте със сървърното визуализиране (или решение за Prerender), ще забавите скоростта, с която вашите страници ще бъдат посещавани от търсачките. Например, роботът на Google следва връзки в мрежата. Ако роботът кацне на вашия сайт и осъзнае, че HTML съдържанието не се зарежда веднага, той ще добави вашия сайт към неговата опашка за индексиране. Това означава, че индексаторът на Google ще посети сайта ви по-късно, за да оцени вашата единствена страница, предоставена от страна на клиента приложение за връзки за индексиране спрямо запис на връзките ви веднага. Това забавя драстично откриването на нови страници. Само Baidu и Google могат да индексират нашия сайт преди настоящото ни SSR решение. Други търсачки дори не спазват клиентски приложения (Bing, DuckDuckGo и др.). Ако погледнем как сайтът ни е индексиран в мрежата, преди да имаме настоящото си SSR решение, само Baidu и Google могат да индексират правилно. @wiekatz има страхотна статия по тази тема тук.

Актуализиране на вашата Sitemap:

Всеки път, когато се случи събитие, се публикува актуална награда или се публикува нещо ново, ние генерираме нова карта на сайта и пингваме Google, за да ги уведомим, че сме я актуализирали. Програмно генерираме Sitemap в движение, използвайки нашия API и приставката на Django за карта. След като се генерира тази карта на сайта, ние я качваме в s3, за да бъде обслужен от CDN за уебсайта. Нашата без сървър функция, която управлява това поведение, можете да намерите тук. Кодът на API за Django около създаването на карта на сайта може да бъде намерен тук.

Ето!

Това беше много в една публикация, но се надявам, че това ви дава насоки в решението ви дали трябва да изградите заявление от страна на сървъра или не. Избрахме да го избегнем за решение за предварително представяне и сме щастливи, че го направихме. Надяваме се, че тази статия ще ви помогне да ви информираме, докато решавате собствения си подход за изобразяване от страна на сървъра, и ще ви предостави убедителен аргумент срещу обвързването на вашия React код към определена рамка, докато все още получавате търсенето, развъртането и бота предимствата на първокласен сървър - решение за рендериране отвън ще осигури.

Обичате ли да се справяте с нови и вълнуващи предизвикателства? Bounties Network изгражда екип от елитни, отдалечени първи инженери. Пуснете ни линия, ако мислите, че ще бъдете добре.

Вижте нашия нов изследовател на адрес: https://explorer.bounties.network
Любимата ми награда: https://explorer.bounties.network/bounty/1265

Присъединете се към нашата общност на Bounties Slack и ни следвайте в Twitter, за да видите какво правим!

Също така, следвайте ме в Twitter :)