Comments 10
Большинство почт было на tut.by мертвый. Я был очень удивлен узнать, но оказывается хоть в рб и прикрыли этот домен но mx запись жива, и почта на эти адреса всё ещё доходит редиректя на яндекс. Я делал небольшие группы рассылок, конечно те кто в 2010 юзали gmail восстанавливали пароль чаще. Но тем не менее были и такие. Моя самая большая ошибка как раз в другом, до 2010 кажется учитывая что сеть была локальная на форуме не было верификации почты, и в итоге помимо устаревшей почты есть очень много нереальных адресов.
Еще есть очень интересный пост, интересно было узнать как поменялась жизнь людей за эти 10 лет. https://talkvio.com/threads/24680-chto-sluchilos-s-vami-za-poslednie-10-let можете ознакомиться ).
Для этих целей можно использовать и Next.js являющийся по сути отдельным фреймворком для схожих целей, но одновременно налагающий определенные ограничения на принцип формирования страниц и структуры проекта.
Не лишним будет сказать, что Next.js накладывает такие ограничения, потому что он именно что фреймворк. ReactJS с первых версий вполне самостоятельно умеет рендерится на NodeJS в строку.
У меня на одном из проектов Vue и для решения проблемы с рендерингом для всяких честных краулеров (гугл, яндекс, фб, линкедин и т. д.) используется похожее решение, только мы опирались на prerender и работает наше решение на aws lambda@edge + для некоторых случаев на nginx. И хочу сказать, что это еще одна головная боль, конечно. Нужно держать руку на пульсе и обновлять список хороших/плохих краулеров, для кого нужно рендерить, для кого не нужно. А самый новый хром для лямбд - 96 версия или около того (3-4 года ей уже). Короче, пришли к выводу, что проще переходить на server rendering, чем пилить костыли для того чтобы всё работало как должно
Спасибо, интересно было узнать что там прям так грустно по версиям. Ну конечно не phantomjs который там на каких-то 40-60 версиях основан, но все равно выглядит странно, учитывая что у нас на работе на android железе заставили пересобирать chromium с 116 на 118 версию тупо из-за уязвимости в декодере недавней).
У меня у друга проект тесно повязан на лямбды, у него там какая-то другая головная боль - их цикл жизни и перезапуск который по итогу его мучает и он с ним сражается.
В качестве баловства - забавно, конечно, но египетские боги - в какой же бред превратился современный фронтенд. Как можно читать эту статью не хватаясь за голову (не пытаюсь обидеть автора)?
И как на SEO повлияет то, что бот будет получать сплошные ошибки при превышении определённой нагрузки, думаю тоже очевидно.
Ну статус ошибки 503 закономерен и вполне хорошо распознается поисковиками. Такой статус может быть и на обычном любом другом сайте при чрезмерной нагрузке от одного источника. Ну и не стоит забывать что индексирующая система монолитна и отвязана от выдачи контента обычному клиенту и может быть размещена отдельна с необходимым масштабированием, если уже нужно не пропускать запросы и уделить этому максимум внимания, исключив условия лимитирования. Ну и конечно мы тут говорим о случаях довольно высокой нагрузки, рендеринг браузером это не самая страшная вещь, она хотя бы довольно точная и соответствует тому что видит клиент на другом устройстве выполняя ваш чуда-юда js код.
Тут все зависит от цели. Если бы приоритет был в сторону SEO и поиск и все выстраивается от него, я бы рекомендовал смотреть в сторону Next.js, или даже в сторону серверного рендеринга вплоть до связки с PHP или статических сайтов - там не ошибешься. Данное же решение хорошо когда индексация опциональна и она просто должна быть, и вам не хочется выстраивать проект исключительно под нее. В моем случае там около 400 000 страниц, мне просто выгодно чтобы они индексировать постепенно и точно никак не влияя на сам проект и его технологии.
А насчет современного фронтенда я согласен
сайты сейчас больше походят на монолитные приложения, особенно с появлением сервис-воркеров и webrtc. Концепция серверной выдачи такое ощущение что уже тоже уходит на задний план вынуждая прибегать к каким-то отдельным решениям наподобие этого или другим.
Согласен со всем, что вы написали, чисто технически.
Меня больше ужасает, какие костыли приходится теперь городить, чтобы обеспечить такую базовую (и чрезвычайно важную для бизнеса) вещь, как индексация поисковиками.
То что Next решает этот вопрос - это, конечно, хорошо, но если проект изначально был написан на чём-то другом, то помимо фронта получается нужно переписывать ещё и весь бэк.
Делали JS-фреймворки для улучшения "дев-экспириенса", а в результате скатились в кромешный ад.
Talkvio — не капибара и не старый пикабу. Модуль серверной индексации для поисковиков для Nginx. Альтернатива Next.js