Мой вывод - если нужно гнаться за sео, то NextJS (React) не выбор
И вот почему я считаю что это не случайностью
То есть Вы по одному единственному параметру решили судить о применимости фреймворков в контексте оптимизации производительности для SEO? Какое-то более глубокое сравнение пытались делать? Например, искать корреляцию между количеством скриптов и DOM нод на страницах с использованием разных фреймворков?
В какой-то момент нужны будут .webp, поэтому, на момент написания статьи, обязательно использование next-images
Зачем? Достаточно перед загрузкой страницы проверить поддержку avif и webp в браузере через base64 fetch и передать расширение изображения в пропах. Это к Вашему высказыванию:
На этом моменте я совершенно запутался. Какое отношение это имеет к SEO и уж тем более какое отношение статья о NextJS имеет к NestJS? В ссылке на документацию к Nest которой вы поделились чёрным по белому написано:
For high-traffic websites in production, it is strongly recommended to offload compression from the application server - typically in a reverse proxy (e.g., Nginx)
С учётом того, что свой бэкенд с вероятностью 90% Вы будете хостить на PaaS, у которого есть свой собственный load balancer, он же reverse proxy, - то о сжатии будет беспокоиться именно он и в таком случае сжатие с однопоточного JavaScript движка лучше вообще снять, иначе можете сделать только хуже.
В конце-концов, готов оспорить самый главный тезис, озвученный Вами в этой статье. NextJS - это один из лучших, если не лучший инструмент для разработки UI с упором на оптимизацию. В подтверждение своих слов демонстрирую Вам скриншот аудита одного из наших NextJS проектов, где на мобильном устройстве оценка достигает 75-77/100 (https://imgur.com/a/20kkHTp), а на десктопе и вовсе 100/100 вышло (https://imgur.com/a/EN7TxOa). Аудит проводили на одной из самых "тяжёлых" страниц с множеством интерактивных компонентов, которая и близко не готова к продакшену - её только пару дней назад закончили "натягивать" с верстки на фреймворк, и ни о какой оптимизации тут и речи не идёт. Тем не менее. Также советую не тратить своё время на попытки добиться 90+ оценки для мобильных устройств, если Вы поставили себе цель гнаться за этим. В этом нет никакого смысла и добиться этого крайне трудно на сайте с интерактивными элементами. В какой-то момент Вы просто заметите, что тратите время на различные "хаки" и анти-паттерн приёмы, которые в дальнейшем будет тяжело поддерживать. Оно того не стоит.
В заключение предположу, что Вы просто недостаточно хорошо разобрались в теме оптимизации производительности в контексте SEO и решили, что фреймворк плохой и нежели тратить время на детальное изучение решили предложить не использовать его вообще.
Но закон (пользовательское соглашение в данном случае) не имеет обратной силы и это изменение никак не повлияет на текущего мошенника. Только предупредит последующие случаи.
Вчера получил зарплату и пытался купить 3060 Ti. Добавил в корзину, а меня на главную страницу перекинуло, корзина пустая. Захожу снова в каталог, а видеокарт уже нет. Как обычной Gigabyte Eagle, так и её OC версии (2 разных лота в магазине). Это, наверное, Хуанг свои же видеокарты скупает.
Администрирование кластера и поддержание его в рабочем состоянии ложится мёртвым грузом на разработчика. Лично для меня это уже пройденный этап - я пытался одновременно администрировать MySQL, Redis, Jenkins и сам хост. В какой-то момент осознал, что прокрастинирую даже запускать проект на локалке. Преимущество serverless заключается именно что в делегировании обязательств по администрированию поставщику, не дерущему с разработчика семь шкур.
Мне кажется, что мы перешли от обсуждения конкретной имплементации к обсуждению инфраструктурных вопросов и решению несуществующих проблем и мне бы не хотелось углубляться в это. В NextJS предусмотрен и задокументирован механизм создания API эндпоинтов. Использовать его или нет — персональный выбор каждого отдельно взятого инженера в сложившихся для него условиях. Я в свою очередь лишь продемонстрировал один из способов упрощения взаимодействия с программным интерфейсом фреймворка для создания API эндпоинтов в пределах NextJS. Относительно Вашего решения ни в коем случае не имею ничего против.
Во-первых, Вы добавляете лишнее звено в цепочку запросов и увеличиваете общее время получения ответа. Во-вторых, Ваш API на NestJS нужно куда-то деплоить, подключать к нему мониторинг и создавать отдельный репозиторий для shared типов для избежания дублирования кода, следить за версионированием, обновлять в нескольких репозиториях и тригерить редеплой коммитами в мастер. В целом, я поддерживаю идею использования наиболее подходящих инструментов для решения разных задач, но в то же время мне кажется, что NextJS создавался как monorepo фреймворк с целью упрощения процесса создания сайтов.
А ещё не очень понял как вы реализуете автокомплит через getInitialProps?
Наверное, я немного запутал Вас своим вступлением о разработке API на основном месте работы. NextJS не подходит для разработки API, но рано или поздно любому сайту понадобится пара-тройка эндпоинтов для интерактивных элементов, если это только не статичный лэндинг.
Я рассуждаю о том, что видел в использовании в рамках крупных проектов и о том, чем пользовался сам. Про MobX мне действительно мало известно, но радикализм в выборе технологий осуждаю.
В конечном итоге бизнес всё равно потратит больше на оплату времени разработчика, чем потеряет в продажах из-за более медленной загрузки страницы. А потом и вовсе может оказаться так, что скорость выпуска новых фич в приложении гораздо важнее, чем размер бандла.
В этих делах важно найти золотую середину и redux-toolkit в этом случае как раз помогает перейти от чего-то что "так себе" к чему-то что "норм" без значительных потерь.
Что, простите? Ещё полгода назад на одну позицию middle frontend engineer было несколько десятков человек. Джуны за место в компании были готовы драться, буквально.
почему IT-компании находятся в постоянном поиске
Потому что в США традиция такая — если компания «хайрит» новых сотрудников, значит она развивается. И вакансия у них будет висеть даже если разработчики им не нужны. А наши аутсорсеры учатся у них и делают так же.
Хоть и поиск достойного синьора — дело не пары недель.
В сторону облачных контор а-ля AWS не смотрели из-за ФЗ, или какая-то своя причина была?
Яндекс.Облако также не рассматривали из-за финансовой невыгодности? И, на самом деле, была бы интересна арифметика — "на колокейшене со своим железом тратим столько-то, в облаке бы тратили вот столько-то", например.
Ещё любопытно почему на одном кластере есть мастер, на другом слейв, а на третьем нету ничего, но на всех есть приложение. Групповая репликация с хранением копии под каждой репликой приложения также не могла быть применена по каким-то причинам?
Воспользуюсь случаем и прорекламирую свой проект по замене CloudFlare (или использовании защиты, подобной той что есть у CloudFlare на своей инфраструктуре): github.com/JamesJGoodwin/umbress
Если есть желающие, можем создать группу и сделать аналоги для Golang, PHP, Rust, etc.
nginx на одном ядре без особой настройки с включённым кэшированием способен обрабатывать 50.000+ запросов в секунду. В чём смысл городить огород на бэкенде?
Не забывайте, что в Воркер нужно передавать только сериализованные данные или строки. Запихнуть туда json-объект для обработки не выйдет, перед этим его нужно превратить в строку, а на другом конце распарсить, что уже будет в разы сложнее для браузера по сравнению с оригинальным алгоритмом.
По-видимому, человек хочет чтобы Facebook изобрели очередной Handlebars/Mustache.
То есть Вы по одному единственному параметру решили судить о применимости фреймворков в контексте оптимизации производительности для SEO? Какое-то более глубокое сравнение пытались делать? Например, искать корреляцию между количеством скриптов и DOM нод на страницах с использованием разных фреймворков?
Зачем? Достаточно перед загрузкой страницы проверить поддержку avif и webp в браузере через base64 fetch и передать расширение изображения в пропах. Это к Вашему высказыванию:
На этом моменте я совершенно запутался. Какое отношение это имеет к SEO и уж тем более какое отношение статья о NextJS имеет к NestJS? В ссылке на документацию к Nest которой вы поделились чёрным по белому написано:
С учётом того, что свой бэкенд с вероятностью 90% Вы будете хостить на PaaS, у которого есть свой собственный load balancer, он же reverse proxy, - то о сжатии будет беспокоиться именно он и в таком случае сжатие с однопоточного JavaScript движка лучше вообще снять, иначе можете сделать только хуже.
В конце-концов, готов оспорить самый главный тезис, озвученный Вами в этой статье. NextJS - это один из лучших, если не лучший инструмент для разработки UI с упором на оптимизацию. В подтверждение своих слов демонстрирую Вам скриншот аудита одного из наших NextJS проектов, где на мобильном устройстве оценка достигает 75-77/100 (https://imgur.com/a/20kkHTp), а на десктопе и вовсе 100/100 вышло (https://imgur.com/a/EN7TxOa). Аудит проводили на одной из самых "тяжёлых" страниц с множеством интерактивных компонентов, которая и близко не готова к продакшену - её только пару дней назад закончили "натягивать" с верстки на фреймворк, и ни о какой оптимизации тут и речи не идёт. Тем не менее. Также советую не тратить своё время на попытки добиться 90+ оценки для мобильных устройств, если Вы поставили себе цель гнаться за этим. В этом нет никакого смысла и добиться этого крайне трудно на сайте с интерактивными элементами. В какой-то момент Вы просто заметите, что тратите время на различные "хаки" и анти-паттерн приёмы, которые в дальнейшем будет тяжело поддерживать. Оно того не стоит.
В заключение предположу, что Вы просто недостаточно хорошо разобрались в теме оптимизации производительности в контексте SEO и решили, что фреймворк плохой и нежели тратить время на детальное изучение решили предложить не использовать его вообще.
Но закон (пользовательское соглашение в данном случае) не имеет обратной силы и это изменение никак не повлияет на текущего мошенника. Только предупредит последующие случаи.
Вчера получил зарплату и пытался купить 3060 Ti. Добавил в корзину, а меня на главную страницу перекинуло, корзина пустая. Захожу снова в каталог, а видеокарт уже нет. Как обычной Gigabyte Eagle, так и её OC версии (2 разных лота в магазине). Это, наверное, Хуанг свои же видеокарты скупает.
Смотрел На первый взгляд показалось, что довольно выгодно, но в AWS калькуляторе посчитал и получилось $115 за одну минимальную базу с бэкапами.
Администрирование кластера и поддержание его в рабочем состоянии ложится мёртвым грузом на разработчика. Лично для меня это уже пройденный этап - я пытался одновременно администрировать MySQL, Redis, Jenkins и сам хост. В какой-то момент осознал, что прокрастинирую даже запускать проект на локалке. Преимущество serverless заключается именно что в делегировании обязательств по администрированию поставщику, не дерущему с разработчика семь шкур.
Вы это определение нашли в каком-то учебнике по юриспруденции?
Во-первых, Вы добавляете лишнее звено в цепочку запросов и увеличиваете общее время получения ответа. Во-вторых, Ваш API на NestJS нужно куда-то деплоить, подключать к нему мониторинг и создавать отдельный репозиторий для shared типов для избежания дублирования кода, следить за версионированием, обновлять в нескольких репозиториях и тригерить редеплой коммитами в мастер. В целом, я поддерживаю идею использования наиболее подходящих инструментов для решения разных задач, но в то же время мне кажется, что NextJS создавался как monorepo фреймворк с целью упрощения процесса создания сайтов.
А ещё не очень понял как вы реализуете автокомплит через getInitialProps?
Наверное, я немного запутал Вас своим вступлением о разработке API на основном месте работы. NextJS не подходит для разработки API, но рано или поздно любому сайту понадобится пара-тройка эндпоинтов для интерактивных элементов, если это только не статичный лэндинг.
Я рассуждаю о том, что видел в использовании в рамках крупных проектов и о том, чем пользовался сам. Про MobX мне действительно мало известно, но радикализм в выборе технологий осуждаю.
В конечном итоге бизнес всё равно потратит больше на оплату времени разработчика, чем потеряет в продажах из-за более медленной загрузки страницы. А потом и вовсе может оказаться так, что скорость выпуска новых фич в приложении гораздо важнее, чем размер бандла.
В этих делах важно найти золотую середину и redux-toolkit в этом случае как раз помогает перейти от чего-то что "так себе" к чему-то что "норм" без значительных потерь.
Жаль, что про Redux-toolkit в основном либо не слышали, либо не пробовали. И ведь статей хватает что на Хабре, что на Медиуме.
Потому что в США традиция такая — если компания «хайрит» новых сотрудников, значит она развивается. И вакансия у них будет висеть даже если разработчики им не нужны. А наши аутсорсеры учатся у них и делают так же.
Хоть и поиск достойного синьора — дело не пары недель.
В сторону облачных контор а-ля AWS не смотрели из-за ФЗ, или какая-то своя причина была?
Яндекс.Облако также не рассматривали из-за финансовой невыгодности? И, на самом деле, была бы интересна арифметика — "на колокейшене со своим железом тратим столько-то, в облаке бы тратили вот столько-то", например.
Ещё любопытно почему на одном кластере есть мастер, на другом слейв, а на третьем нету ничего, но на всех есть приложение. Групповая репликация с хранением копии под каждой репликой приложения также не могла быть применена по каким-то причинам?
Если есть желающие, можем создать группу и сделать аналоги для Golang, PHP, Rust, etc.
nginx на одном ядре без особой настройки с включённым кэшированием способен обрабатывать 50.000+ запросов в секунду. В чём смысл городить огород на бэкенде?
OVH.com — скидки до 50% на выделенные сервера, VPS, домены и хостинг с 27 ноября по 3 декабря
Не забывайте, что в Воркер нужно передавать только сериализованные данные или строки. Запихнуть туда json-объект для обработки не выйдет, перед этим его нужно превратить в строку, а на другом конце распарсить, что уже будет в разы сложнее для браузера по сравнению с оригинальным алгоритмом.