https://teletype.in/@malishokus/obzoriknig Рекомендую вот здесь поискать по обзорам. Пишет Сергей - образованный и толковый трейдер buy-side, в отличие от большинства sell-side (впаривателей)
Смотрел, выглядит хорошо: и feature exposure, и experiment exposure удобно сделаны, в growthbook сделали совместимое с этим «стандартом» апи, отлично работает год с лишним в проде и на фронте, и на беке. С перфом проблем нет: прокси внутри кластера поднимается легко (в стандарте этого не было, в реализациях есть), в клиент (сервис или бек, которые сплитует) скидывается конфиг, поэтому на один под достаточно 1 запроса в минуту
А больше там ничего и не надо, сервис, который примет колбеки и закинет в кх и можно ехать
Обучение разработчиков прошло не без проблем, но они бы были везде: - главная абстракция тут — это фича флаг, он уже привязывается к экспу или другому роллауту, поэтому если выкатить на precentage rollout exposure не придет, всё понятно, но требует привыкания - клиенты _должны_ реализовать кэширование конфига у себя и вынести колбеки в очередь, но это легко сделать 1 раз на язык и везде юзать либу - интеграция помогает запускать больше экспов, НО нужны аналитики, чтобы: правильно посчитать MDE, определить неймспейсы и рассказать про математику продактам, разобраться с движками для подсчета и тд, без этого будет не data driven - с exposure нужно осторожно: легко «оптимизировать» и зарезолвить все нужные фичи, но это сломает аналитику
Все проблемы минорные, мне апи и идея очень нравится, для контекста: я завозил growthbook в организацию на ~100 инженеров, делал сервис для принятия колбеков, джавый стартер для интеграции и помогал другим разобраться
Ну какие проблемы мы словили при массовом внедрении: - Выяснилось, что современные react разработчики очень плохо умеют с этим работать, они привыкли готовить приложения определенным образом, по шаблону и у большинства не было понимания, что такое код работающий на сервере, какие есть нюансы, как его готовить, где водораздел клиентского кода и серверного. Многие пытались на нексте соорудить привычные react-redux-mobx-whatever приложения и получался дикий оверхед и по сложности кодовой базы и по дебагу этого хозяйства. - Пытались некст горизонтально масштабировать и георезервировать - ловили кучу проблем с инвалидацией, неконсистентностью кэшей, сетевые запросы не всегда уходили куда надо. - Приложения стали этакими сцепленными монолитами, просто раскидать статику по s3 и поставить перед ними nginx уже не хватало - нужно было значительно усложнять пайплайны. - Были попытки сделать на этом всем подобие микрофронтовых оркестраторов, но тоже отказались из-за оверхеда. Ну и некст откровенно не для этого создавался. - Намучались с server actions, они тогда только появились и не все понимали как их готовить (мало кто из команды видел PHP вживую 😀 и понимал как это - отправлять данные POST обновлением страницы)
Если резюмировать, то я просто понял границы nextjs и где его можно применять. И лучше не тащить в него какой-то лютый кастом и всякие модные стейт менеджеры, а просто юзать "по инструкции". Ну и просто упаковать в контейнер, а не раскидывать по CDN с кучей реверс проксей. В совокупности с каким нибудь tailwind и например при отсутствии людей на бэке (команды нет например, а делать запросы к IDP или БД надо) очень даже хороший инструмент для шаблонных приложений.
