Вспомнилось, как-то много лет назад, когда я был молодой и зеленый, был у меня суровый, подвыгоревший тимлид-руководитель. Стоит он у окна и смотрит, как рабочие асфальт укладывают. Глаза стали такими грустными.. И он говорит, что вот же есть же нормальная работа! На свежем воздухе, физическая, всё понятно, никаких проблем и тяжелых митингов! Не то что это гребаное АйТи! И уволился. Уж не знаю куда он пошёл работать.
Я считаю, что не каждый может вынести эту ношу обязанностей и ответственности, которые возлагаются на тимлида. Потому что это сложно и нервно.
Но если уж кто-то решился быть ТЛ, то давайте поможем ему с этим! А поскольку работа больше менеджерская и процессная, то без азов таймменеджмента, планирования, процессов разработки - ничего не получится, будет снова выгоревший ТЛ, который уйдет из профессии. А хороших ТЛ итак мало :(
А вы уверены, что Symfony является тем самым единственным фреймворком, на котором стоит всё разрабатывать? Я вот не уверен. При всём моём уважении к Symfony, на котором я разрабатывал несколько лет, пока не ушёл в управление.
Я никогда сам не был разработчиком на Laravel, но текущуя коньюктура рынка, в частности заказной разработки, это миграция массового сегмента с Битрикса на Laravel. Потому что быстро, даёт хороший буст и нет проблемы со специалистами.
Это также сказываестя на количестве специалистов, срез по habr карьере https://career.habr.com/ :
При всей правильности подходов в Symfony, это не быстрая рабочая лошадка для запуска проектов. У нас есть проекты на симфони, но это крупный ecom рапиленный на SOA.
Да и тут, если честно, уже вырисовывается крепкий конкурент на ларе: https://ensi.tech/
Хорошо. Вам нужно разработать контентный сайт, основной стек Laravel. Контента много, куча свойств разных типов, тегов и всё это необходимо редактировать быстро и удобно. Предложите адекватный административный интерфейс. При этом сроки/бюджеты не позволяют разрабатывать админку с 0, в том числе и её дизайн/маркап.
Мы его попробовали, т.к. гибкость и скорость настройки интерфейса идеально подходила под ТЗ. Успешно реализовали проект и поделились своим мнением с сообществом. Честно пишем про плюсы и минусы данного решения. В том числе про требовательность к ресурсам. Мы же не агитируем на него всем переходить!
Filament это административный интерфейс на Laravel с набором гуев и понятной структурой. Он нужен исключительно для того, чтобы самому не собирать админку для сайта с 0. Это не CMS типа Битрикса.
А дальше, пользовательский фронт и бек - это разные репы и контейнеры, которые разрабатываются разными командами и взаимодействуют по API, всё по канонам :)
Рассказываешь про опыт на Битрикс - отвечают, что хорошие решения только на Laravel
Рассказываешь про новую админку на Laravel - отвечают, что хорошие решения только на Symfony
Была статья про проект на Symfony - ответили, что нужен Python
В статье про монолит на Python - комменты, что почему не микросервисы?
А в статье про решение на микросервисах - угадайте... комментируют, что надо наворачивать ecom на Битрикс, потому что там многое уже есть из коробки!
Круг замкнулся!
А дело в том, что решения можно делать, на чём угодно, хоть на паскале. Всё зависит от кривизны рук конечного исполнителя.
Спор Битрикс/Laravel/Symfony/Yii априори бессмысленный. У каждого фреймворка свой круг задач.
ИМХО Laravel с не сложным порогом входа и лёгок в эксплуатации. А на Symfony делать контентные сайты - как из пушки по воробьям. В статье как раз разбирается Laravel админка для быстрых решений.
Вообще, исторически, мы использовали Laravel только для создания BFF либо мидлваров. Основную разработку на PHP ведём на Symfony и Битриксе. Карьерный сайт, это должно быть лёгкое решение, которое не должно тащить за собой ограничений по лицензии, кучу пакетов и порог входа для доработки. Поэтому мы выбрали более лёгкий Laravel. Тут можно разводить холивар про Symfony и Laravel... мы больше отталкивались от того, что сферическому PHP разработчику в вакууме в разы проще освоить и разобраться в ларе, чем в симфони. А коробка должна быть доступна для доработки каждому, в этом и смысл гибкости.
Сравнивали несколько админок с точки зрения, где проще дорабатывать и адаптировать под клиента, а главное с наличием визивиг редактора. Сначала выбрали Twill, именно больше из-за редактора, на котором быстро реализовали конструктор лендингов.
Затем познакомились со сравнительно новым решением FilamentPHP, которое даёт ещё больше возможностей удобно кастомить интерфейс админки. Пример:
Конечно. Например, имеет смысл горизонтального масштабирования консумеров, читающих партиции из одного топика, когда порядок считывания сообщений не важен.
Если это какие-то статистические данные, которые можно считать из N партиций в N потоков и всё смешать в системе потребителя. Считывать заказы из нескольких партиций, уже не вариант, иначе может нарушиться хронология статусов.
Разрабатываемое и поддерживаемое нами web-приложение является небольшим звеном большой IT инфраструктуры заказчика, в которую входят другие приложения, физические магазины, склады и тд. Поддержкой и развитием Apache Kafka в данном случае мы не занимались, поэтому я не могу сообщить объём данных, проходящий через брокера.
Я понимаю Ваш вопрос, насколько сильно нужно «разогнаться», чтобы не хватило кролика. Когда начинаются высоконагруженные BigData системы и сотни тысяч сообщений в секунду и горизонтально масштабировать RabbitMQ становится уже затратно. Думаю, что роль Kafka также будет правильно рассматривать, как часть ESB, когда Kafka дополняет её своими плюшками и отказоустойчивостью.
Видел материал, как искусственно сравнивали скорость работы на больших данных кафки и кролика:
Я ответил в комментарии ниже за что и когда выдаются баны. Мы не вводим пользователя в заблуждение и не отдаём разный контент меняющий смысл страницы. Контент и внешний вид страницы для поисковика и контент страницы для неавторизованного пользователя отличается только наличием тегов <script>.
Неавторизованный пользователь видит страницу с контентом. Для него отдаётся такая же отренедеренная версия, что и для поисковика, но со всем JS. И запускается механизм регидратации, чтобы актуализировать DOM, события и тд.
Первая проблема: после отдачи уже отрендеренной страницы пользователю, отрабатывают события загрузки страницы и JS начинает заново пересоздавать блоки, начинается мигание, происходит двойная загрузка страницы...
Здесь нужно научит клиентский код понимать, что текущая страница уже готова, на ней уже есть необходимые DOM объекты и загружать ничего не нужно.
Вторая проблема это актуализация страницы. Контент-менеджер обновил описание элемента в админке. Кеш в битриксе сбросится автоматически, а вот отрендеренная страница об этом ничего не знает и поисковик/неавторизованный пользователь видит старый контент, а авторизованный пользователь новый.
И тут нужно подписываться на обновления кеша либо апдейты контентных таблиц и прокидывать из битры триггер на перегенерацию страницы.
Только авторизованный пользователь - видит скелет. И это сознательное допущение, чтобы не перерисовывать на лету контент, который видоизменяется для авторизованного. Не могу сказать, как это реализуется при использовании других технологий пререндеринга, возможно имеются какие-то изящные решения для авторизованных.
Боты поисковых систем видят только облегченный вариант (с высокой скоростью загрузки)?
Да, при прямом заходе бота (с заголовками, UA бота), PageSpeed Insights выдаёт 90+. И вы правы, когда гугл "притворяется" пользователем, то он увидит уже отрендеренную версию страницы, но уже плюс JS, аналитика и тд. и оценка будет 80+.
А на закрытые для определённых групп пользователей страницы, страницы в авторизованном режиме, в общем на не отрендеренные страницы - гугл уже не попадёт.
И как тут не будет бана за подмену страниц?
Да, у нас тоже были переживания по этому поводу. Помимо описанного вами случая, поисковики ещё собирают информацию из реального сеанса пользователя, в том числе когда он авторизован.
Консультировались по поводу случаев когда происходит бан страниц. Поисковые системы, когда обнаруживают существенные разницы в страницах, помечают их как подозрительные и отдают на верификацию человеку. Производится сверка страницы и бан выдаётся "если подменённый контент вводит пользователя в заблуждение".
Т.е. если для гугла сайт отдаёт страницу с ромашками и в поисковом индексе ромашки. Пользователь переходя из поисковой выдачи думает, что попадает на сайт про ромашки, а в реальности подменяется контент и пользователю отдаётся страница с покупкой Чебурашек - будет бан. Такой разницы у нас конечно нет.
Также добавлю, что проект категории "не для всех". При заходе на сайт пользователь попадает на страницу верификации. Это отдельная страница выдающаяся по любому адресу сайта. Т.е. в исходном состоянии поисковая система видит только страницу верификации и не индексирует контент.
У нас уже несколько лет, ещё до внедрения Vue.js, используется механизм определения поискового бота, я немного рассказал про него в статье. Когда на сайт заходит поисковик, то он не уходит на страницу верификации, а сразу видит весь контент и может его индексировать. И даже при таком условии у нас не возникало проблем с индексацией и банами.
Скажу честно, внушает доверие, что Puppeteer предлагают сами разработчики Lighthouse, как решение для веб-приложений, архитектура которых не предусматривает заложенный изначально SSR.
Есть риск, что гугл в будущем изменит свою политику? Только одному гуглу известно :) Риски есть всегда. Мы сделали пробу пера с реактивным фреймворком, почти не изменяя текущий код бекенда, результат нас устроил. А дальше уже будет по классике: Bitrix + GraphQL + Nuxt.js ))
Вспомнилось, как-то много лет назад, когда я был молодой и зеленый, был у меня суровый, подвыгоревший тимлид-руководитель. Стоит он у окна и смотрит, как рабочие асфальт укладывают. Глаза стали такими грустными.. И он говорит, что вот же есть же нормальная работа! На свежем воздухе, физическая, всё понятно, никаких проблем и тяжелых митингов! Не то что это гребаное АйТи! И уволился. Уж не знаю куда он пошёл работать.
Я считаю, что не каждый может вынести эту ношу обязанностей и ответственности, которые возлагаются на тимлида. Потому что это сложно и нервно.
Но если уж кто-то решился быть ТЛ, то давайте поможем ему с этим! А поскольку работа больше менеджерская и процессная, то без азов таймменеджмента, планирования, процессов разработки - ничего не получится, будет снова выгоревший ТЛ, который уйдет из профессии. А хороших ТЛ итак мало :(
Еее, давай!
А вы уверены, что Symfony является тем самым единственным фреймворком, на котором стоит всё разрабатывать? Я вот не уверен. При всём моём уважении к Symfony, на котором я разрабатывал несколько лет, пока не ушёл в управление.
Я никогда сам не был разработчиком на Laravel, но текущуя коньюктура рынка, в частности заказной разработки, это миграция массового сегмента с Битрикса на Laravel. Потому что быстро, даёт хороший буст и нет проблемы со специалистами.
Это также сказываестя на количестве специалистов, срез по habr карьере https://career.habr.com/ :
По запросу Laravel Найдено 55 вакансий, Symfony Найдено 39 вакансий, Bitrix Найдено 38 вакансий, Yii Найдено 17 вакансий.
При всей правильности подходов в Symfony, это не быстрая рабочая лошадка для запуска проектов. У нас есть проекты на симфони, но это крупный ecom рапиленный на SOA.
Да и тут, если честно, уже вырисовывается крепкий конкурент на ларе: https://ensi.tech/
Хорошо. Вам нужно разработать контентный сайт, основной стек Laravel. Контента много, куча свойств разных типов, тегов и всё это необходимо редактировать быстро и удобно. Предложите адекватный административный интерфейс. При этом сроки/бюджеты не позволяют разрабатывать админку с 0, в том числе и её дизайн/маркап.
У нас есть опыт разработки проектов на готовых админках для Laravel: https://twillcms.com/ https://orchid.software/ru/ https://delphinpro.gitbook.io/voyager-ru и https://octobercms.com/
Нельзя сказать, что какое-то решение идеальное и отвечает всем запросам.
В сообществе Laravel зарелизили новое решение https://filamentphp.com/ Между прочим 14к звёзд https://github.com/filamentphp/filament Не сказать, что какой-то ноунейм.
Мы его попробовали, т.к. гибкость и скорость настройки интерфейса идеально подходила под ТЗ. Успешно реализовали проект и поделились своим мнением с сообществом. Честно пишем про плюсы и минусы данного решения. В том числе про требовательность к ресурсам. Мы же не агитируем на него всем переходить!
Не понимаю критики, честно.
Laravel не популярный стек?)
Filament это административный интерфейс на Laravel с набором гуев и понятной структурой. Он нужен исключительно для того, чтобы самому не собирать админку для сайта с 0. Это не CMS типа Битрикса.
А дальше, пользовательский фронт и бек - это разные репы и контейнеры, которые разрабатываются разными командами и взаимодействуют по API, всё по канонам :)
Рассказываешь про опыт на Битрикс - отвечают, что хорошие решения только на Laravel
Рассказываешь про новую админку на Laravel - отвечают, что хорошие решения только на Symfony
Была статья про проект на Symfony - ответили, что нужен Python
В статье про монолит на Python - комменты, что почему не микросервисы?
А в статье про решение на микросервисах - угадайте... комментируют, что надо наворачивать ecom на Битрикс, потому что там многое уже есть из коробки!
Круг замкнулся!
А дело в том, что решения можно делать, на чём угодно, хоть на паскале. Всё зависит от кривизны рук конечного исполнителя.
Спор Битрикс/Laravel/Symfony/Yii априори бессмысленный. У каждого фреймворка свой круг задач.
ИМХО Laravel с не сложным порогом входа и лёгок в эксплуатации. А на Symfony делать контентные сайты - как из пушки по воробьям. В статье как раз разбирается Laravel админка для быстрых решений.
Вообще, исторически, мы использовали Laravel только для создания BFF либо мидлваров. Основную разработку на PHP ведём на Symfony и Битриксе. Карьерный сайт, это должно быть лёгкое решение, которое не должно тащить за собой ограничений по лицензии, кучу пакетов и порог входа для доработки. Поэтому мы выбрали более лёгкий Laravel. Тут можно разводить холивар про Symfony и Laravel... мы больше отталкивались от того, что сферическому PHP разработчику в вакууме в разы проще освоить и разобраться в ларе, чем в симфони. А коробка должна быть доступна для доработки каждому, в этом и смысл гибкости.
Сравнивали несколько админок с точки зрения, где проще дорабатывать и адаптировать под клиента, а главное с наличием визивиг редактора. Сначала выбрали Twill, именно больше из-за редактора, на котором быстро реализовали конструктор лендингов.
Затем познакомились со сравнительно новым решением FilamentPHP, которое даёт ещё больше возможностей удобно кастомить интерфейс админки.
Пример:
Получается так:
Красота же!
У нас PHP отдел один из самых больших по количеству сотрудников, видимо, хорошо работаем с их мотивацией :)
Конечно. Например, имеет смысл горизонтального масштабирования консумеров, читающих партиции из одного топика, когда порядок считывания сообщений не важен.
Если это какие-то статистические данные, которые можно считать из N партиций в N потоков и всё смешать в системе потребителя. Считывать заказы из нескольких партиций, уже не вариант, иначе может нарушиться хронология статусов.
Разрабатываемое и поддерживаемое нами web-приложение является небольшим звеном большой IT инфраструктуры заказчика, в которую входят другие приложения, физические магазины, склады и тд. Поддержкой и развитием Apache Kafka в данном случае мы не занимались, поэтому я не могу сообщить объём данных, проходящий через брокера.
Я понимаю Ваш вопрос, насколько сильно нужно «разогнаться», чтобы не хватило кролика. Когда начинаются высоконагруженные BigData системы и сотни тысяч сообщений в секунду и горизонтально масштабировать RabbitMQ становится уже затратно. Думаю, что роль Kafka также будет правильно рассматривать, как часть ESB, когда Kafka дополняет её своими плюшками и отказоустойчивостью.
Видел материал, как искусственно сравнивали скорость работы на больших данных кафки и кролика:
https://medium.com/@vozerov/kafka-vs-rabbitmq-38e221cf511b
Я ответил в комментарии ниже за что и когда выдаются баны. Мы не вводим пользователя в заблуждение и не отдаём разный контент меняющий смысл страницы. Контент и внешний вид страницы для поисковика и контент страницы для неавторизованного пользователя отличается только наличием тегов <script>.
Неавторизованный пользователь видит страницу с контентом. Для него отдаётся такая же отренедеренная версия, что и для поисковика, но со всем JS. И запускается механизм регидратации, чтобы актуализировать DOM, события и тд.
Первая проблема: после отдачи уже отрендеренной страницы пользователю, отрабатывают события загрузки страницы и JS начинает заново пересоздавать блоки, начинается мигание, происходит двойная загрузка страницы...
Здесь нужно научит клиентский код понимать, что текущая страница уже готова, на ней уже есть необходимые DOM объекты и загружать ничего не нужно.
Вторая проблема это актуализация страницы. Контент-менеджер обновил описание элемента в админке. Кеш в битриксе сбросится автоматически, а вот отрендеренная страница об этом ничего не знает и поисковик/неавторизованный пользователь видит старый контент, а авторизованный пользователь новый.
И тут нужно подписываться на обновления кеша либо апдейты контентных таблиц и прокидывать из битры триггер на перегенерацию страницы.
Только авторизованный пользователь - видит скелет. И это сознательное допущение, чтобы не перерисовывать на лету контент, который видоизменяется для авторизованного. Не могу сказать, как это реализуется при использовании других технологий пререндеринга, возможно имеются какие-то изящные решения для авторизованных.
Да, при прямом заходе бота (с заголовками, UA бота), PageSpeed Insights выдаёт 90+. И вы правы, когда гугл "притворяется" пользователем, то он увидит уже отрендеренную версию страницы, но уже плюс JS, аналитика и тд. и оценка будет 80+.
А на закрытые для определённых групп пользователей страницы, страницы в авторизованном режиме, в общем на не отрендеренные страницы - гугл уже не попадёт.
Да, у нас тоже были переживания по этому поводу. Помимо описанного вами случая, поисковики ещё собирают информацию из реального сеанса пользователя, в том числе когда он авторизован.
Консультировались по поводу случаев когда происходит бан страниц. Поисковые системы, когда обнаруживают существенные разницы в страницах, помечают их как подозрительные и отдают на верификацию человеку. Производится сверка страницы и бан выдаётся "если подменённый контент вводит пользователя в заблуждение".
Т.е. если для гугла сайт отдаёт страницу с ромашками и в поисковом индексе ромашки. Пользователь переходя из поисковой выдачи думает, что попадает на сайт про ромашки, а в реальности подменяется контент и пользователю отдаётся страница с покупкой Чебурашек - будет бан. Такой разницы у нас конечно нет.
Также добавлю, что проект категории "не для всех". При заходе на сайт пользователь попадает на страницу верификации. Это отдельная страница выдающаяся по любому адресу сайта. Т.е. в исходном состоянии поисковая система видит только страницу верификации и не индексирует контент.
У нас уже несколько лет, ещё до внедрения Vue.js, используется механизм определения поискового бота, я немного рассказал про него в статье. Когда на сайт заходит поисковик, то он не уходит на страницу верификации, а сразу видит весь контент и может его индексировать. И даже при таком условии у нас не возникало проблем с индексацией и банами.
Скажу честно, внушает доверие, что Puppeteer предлагают сами разработчики Lighthouse, как решение для веб-приложений, архитектура которых не предусматривает заложенный изначально SSR.
Есть риск, что гугл в будущем изменит свою политику? Только одному гуглу известно :) Риски есть всегда. Мы сделали пробу пера с реактивным фреймворком, почти не изменяя текущий код бекенда, результат нас устроил. А дальше уже будет по классике: Bitrix + GraphQL + Nuxt.js ))