Под работой в гугле автор подразумевает вбивание поисковых запросов для получения решения? То, что мини приложение в телеграме не стоит писать на нексте, поймет даже джун из конторы в златоусте
Абсолютная бездарность) Лучше бы с PHP / питонов или что там у вас переписали на нормальные ЯП вместо фантазирования с базами данных, из-за чего бизнес скоро умрет окончательно) Вижу что 4 года уже статей не было, похоже история подходит к концу
Но возможно ребята опозорились и в итоге переписали с процедур на бизнес логику на уровне приложения
Господи, ужасная статья, а люди ведь довольны и наделают ошибок) Правильно подметили, что это больше сборник каких-то никак не связанных заметок, чем описание цельного решения.
Моменты которые особо доставили:
Деплой в прод через docker compose
Балансировка через сырой nginx конфиг, написанный ручками
Секции про мониторинг, где сначала показано что графана и прометеус запускаются в докер компоузе, а потом секция в которой конфиги уже для кубернетиса!
Словарик user_data для хранения состояния! Это вообще прикол, в статье идет речь про высоконагруженных ботов и "масштабирование", а данные хранятся в словарике у каждой из реплик приложения. Естественно, когда юзер будет пользоваться ботом, запросы будут прилетать то в один инстанс, то в другой, и все эти данные будут максимально неконсистентные, что напрочь сломает логику) При этом рядом описано сравнение баз данных, которые как раз и должны использоваться как общее хранилище между репликами, и в особенности редис как кеш и средство для локов
Разработка высоконагруженных телеграм-ботов — это задача, требующая глубокого понимания архитектуры, безопасности и производительности. С правильным подходом и вниманием к деталям, вы сможете создать бота, который не только удовлетворит потребности пользователей, но и будет масштабируемым и надежным в любых условиях.
Полностью согласен, не стоит писать такие статьи без экспертизы
Вот написал точно то же самое в соседнем треде) Я уверен что микрофронты не нужны, если они не лежат в отдельных изолированных репах. Ведь тогда над ними не удобно будет работать отдельной команде со своими процессами. Думаю микрофронт должен лежать отдельно и предоставлять генерируемую паблик апи для взаимодействия с ним, а детали знать вообще не нужно, и реализация может лежать где угодно, это не должно волновать тех, кто берет этот микрофронт в зависимости
Люди слишком много думают, а на деле фсд очень даже простой) Когда делаешь страницу, для начала надо максимально все писать в pages, остальные слои нужны лишь при действительной необходимости, когда нужно использовать какую-то общую функциональность. Например, есть главная страница и страница записей, мы сделали страницу записей и вся ее модель (включая запрос и храние записей) находится в папке данной страницы. Потом добавилась фича, что надо открыть попап с предложением оформить запись (если их нет), и попап этот вылезает на главной. Выносим данные о записях в entities/appointments и можем использовать во всех страницах и фичах. Попап с предложением о записи на самом деле фича, но для начала можно засунуть и в главную страницу по структуре (если мало опыта с фсд). Потенциально просто этот попап может понадобиться и в других местах, и это уже точно должно будет находиться в фичах.
По определению "фича" это какое-то одно бизнес действие, и попап к этому как раз подходит. А "ентити" это какая-то бизнес сущность, используемая чаще всего по всему приложению. Вот например appointment как в примере выше, очень часто там еще находится user. Можно и session положить слегка нарушив методологию касательно кросс импортов (потому что это хоть и не полноценная бизнес сущность, но и не общая не зависимая от проекта штука из shared). Shared слой как раз про общие вещи, которые чаще всего можно скопировать и вставить в другой проект, и при этом они сразу будут работать без каких-то танцев, поскольку это просто независимые компоненты / абстракции / методы. Многие туда кладут session, как я уже говорил считаю это нарушением, так как сессия сильно зависит от конкретной апи.
Вот проблема fsd как раз в том, что есть такие спорные вещи и при этом нет строго принятого пути решения. Например, есть очень частая проблема с так называемыми layouts или templates (каркасы для страниц). Они почти всегда зависят от слоя виджетов, но методология не приветствует кросс импорты в одном слайсе. И выходит что их просто некуда положить по методологии - между страницами и виджетами нет слайсов) Очевидное и простое решение - сделать дополнительный слайс layouts/templates, но тем не менее его все еще не сделали, и идут даже ближе к какому-то computed слою внутри слайса, в котором можно импортировать из других слоев в том же слайсе.
Вот фсд простой как раз когда не стесняешься такие моменты решать, а не пытаешься какими-то костылями адаптировать их под методологию. Ведь если ты долго придумываешь решение, разбираешься как сделать по методологии и так далее, то стороннему человеку придется сделать тот же самый ресерч, чтобы разобраться в твоем решении, когда он его увидит. А методология должна наоборот это упрощать, чтобы новый человек почти сразу же понял что где лежит, и почему такое-то решение принято
Проблема nx в том что держать микрофронты в одной репе это как купить соковыжималку, но продолжать выжимать фрукты руками) Ведь главная суть микрофронтов в том, чтобы изолировать часть функциональности под какой-то общеизвестной паблик апи, и вынести куда-то отдельно, чтобы эту функциональность могла поддерживать какая-то другая команда со своими процессами. У них это все будет лежать в отдельной репе, а как делать мры, коммиты и так далее - они могут сами решать. Одна монорепа это ограничивает и вставляет палки в колеса - нужно делать как все, подтягивать изменения других команд, вероятно еще запускать ненужные микрофронты (если не удосужились нормально настроить запуск, что чаще всего и случится)
Поставил минус, так как нет самого сильного стейт-менеджера - эффектора. Но в принципе не удивительно, автор не русскоязычный, у них там проблемы с СТМ - всё заполонили проекты-однодневки вроде jotai, zustand и т.д, у которых авторы популярные опенсурсеры, пиарящие друг-друга. Ну и в комментах конечно же знакомые лица - те же самые мобхсеры, что и под каждой статьей про стейт-менеджмент. Такое ощущение, что это боты и им кто-то платит за комментарии.
counterSelectors.count ничем не короче писать в итоге чем selectCounterCount. Вот только второй вариант можно удобно автоимпортить и он рекомендуется стайлгайдом.
Это вопрос семантики и внешнего/внутреннего интерфейса.
Внутри файла нет никакого смысла уточнять к чему конкретно относится селектор — к модулю counter, или, например, users. Мы и так из контекста имеем об этом информацию. С припиской же, внутренний интерфейс становится переусложнен — имена более длинные и имеют больше визуального мусора, который не несет никакой ценности.
Другими словами, внутренний интерфейс пытается решить проблему внешнего, и из-за этого сам теряет удобство. В принципе, здесь можно провести аналогию с модулями: внутренний модуль пытается решить задачу своего родительского модуля, о котором он вообще не должен знать.
Используя scope/namespace/объект, мы решаем проблему на уровне внешнего интерфейса и не трогаем при этом внутренний.
Насчет "ничем не короче писать". Ну, я и не пытался сводить это к количеству символов. Мне кажется, логичнее группировать вещи, которые относятся к одной и той же сущности. Данный принцип используется везде, не только в программировании, и понятен человеку подсознательно.
Насчет "удобно автоимпортить". Не очень понял проблему. Мы знаем, что селектор относится к модулю counter, и знаем, как у нас именуется экспорт с селекторами. Пишем counterSelectors — редактор предлагает автоимпорт, и мы его делаем. После, нажимаем точку и видим все селекторы, относящиеся к данному модулю.
А reselect использовать только когда shallowEqual не работает. Ну то есть мы «инкапсулируем мемоизацию в другом месте», просто делать это приходится вдвое-втрое реже.
Это уже ведет к:
неконсистентности (совершенно разным подходам в разных местах)
невозможности использовать как входной параметр в мемоизированном селекторе (проверка аргументов всегда будет фейлиться)
И как я уже говорил, селектор не самодостаточный, вы просто это фиксите костылем в виде кастомного хука, по сути не получая ничего кроме потенциальных проблем с производительностью и специфичного кода, отличающегося от других проектов.
Ну и у useSelector не второй параметр — костыль, а весь вызов. Из-за того, что он не передает ownProps компонента в селектор
Согласен — было бы намного удобнее. Я бы вообще убрал параметр с кастомным компаратором, и вместо этого позволил пробрасывать произвольное число аргументов в селектор.
Не использовать селекторы сложнее, чем просто забрать по адресу из стора (возможно используя при этом что-то из ownProps). Соответственно все вычисления перелазят в слайсы-редьюсеры (это кстати и отлаживать проще). Но поскольку это не MobX / Effector и даже не $mol следить за пересчётом приходится самому.
Производные от исходных данных в редьюсере — катастрофа на большом проекте. У меня однажды в одной фиче было где-то 40, если не больше, селекторов, между которыми были довольно сложные зависимости, с точки зрения всей картины. Полагаю, в редьюсер это было бы невозможно засунуть и проект бы несчадно лагал при любом экшне.
Селекторы и в частности `reselect` как раз позволяют строить зависимости между различными данными и достаточно эффективно производить пересчеты. И особенно хорошо, когда абсолютно все получение данных и мемоизация разруливаются там же (проецируя на предложение с `shallowEqual`).
Не использовать Redux, раз они за 5 лет не смогли придумать нормальных computed полей. Особенно если саги не нужны.
Да, это один из посылов статьи)
И еще добавлю про саги — это как раз еще один костыль для редаксом, который дает ему возможность контролировать flow.
Более-менее жизнеспособное использование редакса строится именно из таких костылей. Саги — для control flow, селекторы — как замена всяким компьютедам, тулкит — как абстракция для некоторых продвинутых возможностей и фиксинга бойлерплейта.
Сам по себе редакс — просто очень примитивная технология без всего этого.
Во-первых, переопределяется другое, а именно - сравнение результата селектора с предыдущим. То есть, селектор все равно выполнится. Переопределение компаратора в большинстве случаев ничего не именит, если там не возвращается каждый раз новый объект, а вы не передали туда shallowEqual. Вообще выглядит так, будто этот комментарий должен цитировать совсем другую часть текста (там, где было про сравнение через ===.
Ну и во-вторых, второй параметр useSelector - костыль:
Вместо 1 места (в селекторе) надо во всех местах его использования указывать функцию-компаратор - это все усложняет и ведет к ошибкам
Как указал @Carduelisв этом комменте - банально все может сломаться на более вложенной структуре
Хуже производительность
Не кажется ли, что лучше инкапсулировать мемоизацию в другом месте, чтобы коду снаружи не надо было думать о том, что там вообще будет возвращается и нужно ли это как-то отдельным способом сравнивать? При этом, такой подход изначально более эффективен, так как ничего лишнего каждый рендер не выполняется.
Под работой в гугле автор подразумевает вбивание поисковых запросов для получения решения? То, что мини приложение в телеграме не стоит писать на нексте, поймет даже джун из конторы в златоусте
Абсолютная бездарность) Лучше бы с PHP / питонов или что там у вас переписали на нормальные ЯП вместо фантазирования с базами данных, из-за чего бизнес скоро умрет окончательно) Вижу что 4 года уже статей не было, похоже история подходит к концу
Но возможно ребята опозорились и в итоге переписали с процедур на бизнес логику на уровне приложения
Это перевод какой-то статьи из 2018 года?
Господи, ужасная статья, а люди ведь довольны и наделают ошибок) Правильно подметили, что это больше сборник каких-то никак не связанных заметок, чем описание цельного решения.
Моменты которые особо доставили:
Деплой в прод через docker compose
Балансировка через сырой nginx конфиг, написанный ручками
Секции про мониторинг, где сначала показано что графана и прометеус запускаются в докер компоузе, а потом секция в которой конфиги уже для кубернетиса!
Словарик user_data для хранения состояния! Это вообще прикол, в статье идет речь про высоконагруженных ботов и "масштабирование", а данные хранятся в словарике у каждой из реплик приложения. Естественно, когда юзер будет пользоваться ботом, запросы будут прилетать то в один инстанс, то в другой, и все эти данные будут максимально неконсистентные, что напрочь сломает логику) При этом рядом описано сравнение баз данных, которые как раз и должны использоваться как общее хранилище между репликами, и в особенности редис как кеш и средство для локов
Полностью согласен, не стоит писать такие статьи без экспертизы
Вот написал точно то же самое в соседнем треде) Я уверен что микрофронты не нужны, если они не лежат в отдельных изолированных репах. Ведь тогда над ними не удобно будет работать отдельной команде со своими процессами. Думаю микрофронт должен лежать отдельно и предоставлять генерируемую паблик апи для взаимодействия с ним, а детали знать вообще не нужно, и реализация может лежать где угодно, это не должно волновать тех, кто берет этот микрофронт в зависимости
Люди слишком много думают, а на деле фсд очень даже простой) Когда делаешь страницу, для начала надо максимально все писать в pages, остальные слои нужны лишь при действительной необходимости, когда нужно использовать какую-то общую функциональность. Например, есть главная страница и страница записей, мы сделали страницу записей и вся ее модель (включая запрос и храние записей) находится в папке данной страницы. Потом добавилась фича, что надо открыть попап с предложением оформить запись (если их нет), и попап этот вылезает на главной. Выносим данные о записях в entities/appointments и можем использовать во всех страницах и фичах. Попап с предложением о записи на самом деле фича, но для начала можно засунуть и в главную страницу по структуре (если мало опыта с фсд). Потенциально просто этот попап может понадобиться и в других местах, и это уже точно должно будет находиться в фичах.
По определению "фича" это какое-то одно бизнес действие, и попап к этому как раз подходит. А "ентити" это какая-то бизнес сущность, используемая чаще всего по всему приложению. Вот например appointment как в примере выше, очень часто там еще находится user. Можно и session положить слегка нарушив методологию касательно кросс импортов (потому что это хоть и не полноценная бизнес сущность, но и не общая не зависимая от проекта штука из shared). Shared слой как раз про общие вещи, которые чаще всего можно скопировать и вставить в другой проект, и при этом они сразу будут работать без каких-то танцев, поскольку это просто независимые компоненты / абстракции / методы. Многие туда кладут session, как я уже говорил считаю это нарушением, так как сессия сильно зависит от конкретной апи.
Вот проблема fsd как раз в том, что есть такие спорные вещи и при этом нет строго принятого пути решения. Например, есть очень частая проблема с так называемыми layouts или templates (каркасы для страниц). Они почти всегда зависят от слоя виджетов, но методология не приветствует кросс импорты в одном слайсе. И выходит что их просто некуда положить по методологии - между страницами и виджетами нет слайсов) Очевидное и простое решение - сделать дополнительный слайс layouts/templates, но тем не менее его все еще не сделали, и идут даже ближе к какому-то computed слою внутри слайса, в котором можно импортировать из других слоев в том же слайсе.
Вот фсд простой как раз когда не стесняешься такие моменты решать, а не пытаешься какими-то костылями адаптировать их под методологию. Ведь если ты долго придумываешь решение, разбираешься как сделать по методологии и так далее, то стороннему человеку придется сделать тот же самый ресерч, чтобы разобраться в твоем решении, когда он его увидит. А методология должна наоборот это упрощать, чтобы новый человек почти сразу же понял что где лежит, и почему такое-то решение принято
Проблема nx в том что держать микрофронты в одной репе это как купить соковыжималку, но продолжать выжимать фрукты руками) Ведь главная суть микрофронтов в том, чтобы изолировать часть функциональности под какой-то общеизвестной паблик апи, и вынести куда-то отдельно, чтобы эту функциональность могла поддерживать какая-то другая команда со своими процессами. У них это все будет лежать в отдельной репе, а как делать мры, коммиты и так далее - они могут сами решать. Одна монорепа это ограничивает и вставляет палки в колеса - нужно делать как все, подтягивать изменения других команд, вероятно еще запускать ненужные микрофронты (если не удосужились нормально настроить запуск, что чаще всего и случится)
Форматирование вышло из чата?)
20 лет в айти, 30 тысяч оклада - как идеально описать пхпшника
Эффектор - нелепо и смешно, так и зафиксируем
+15
Поставил минус, так как нет самого сильного стейт-менеджера - эффектора. Но в принципе не удивительно, автор не русскоязычный, у них там проблемы с СТМ - всё заполонили проекты-однодневки вроде jotai, zustand и т.д, у которых авторы популярные опенсурсеры, пиарящие друг-друга. Ну и в комментах конечно же знакомые лица - те же самые мобхсеры, что и под каждой статьей про стейт-менеджмент. Такое ощущение, что это боты и им кто-то платит за комментарии.
Собственно одна из особенностей MobX заключается в том, что он также не имеет инструмента для control flow =) А вот эффектор лишен этого недостатка.
Эта рекомендация вообще для новичков. В доке очень много плохого кода.
В больших приложениях с таким именованием и подходами все превращается в мусорку.
Собственно эта строчка и делает экспорт в виде объекта) Там внутри все селекторы. В смысле не редактор ничего не подтянет?)
Это вопрос семантики и внешнего/внутреннего интерфейса.
Внутри файла нет никакого смысла уточнять к чему конкретно относится селектор — к модулю
counter, или, например,users. Мы и так из контекста имеем об этом информацию. С припиской же, внутренний интерфейс становится переусложнен — имена более длинные и имеют больше визуального мусора, который не несет никакой ценности.Другими словами, внутренний интерфейс пытается решить проблему внешнего, и из-за этого сам теряет удобство. В принципе, здесь можно провести аналогию с модулями: внутренний модуль пытается решить задачу своего родительского модуля, о котором он вообще не должен знать.
Используя scope/namespace/объект, мы решаем проблему на уровне внешнего интерфейса и не трогаем при этом внутренний.
Насчет "ничем не короче писать". Ну, я и не пытался сводить это к количеству символов. Мне кажется, логичнее группировать вещи, которые относятся к одной и той же сущности. Данный принцип используется везде, не только в программировании, и понятен человеку подсознательно.
Насчет "удобно автоимпортить". Не очень понял проблему. Мы знаем, что селектор относится к модулю
counter, и знаем, как у нас именуется экспорт с селекторами. ПишемcounterSelectors— редактор предлагает автоимпорт, и мы его делаем. После, нажимаем точку и видим все селекторы, относящиеся к данному модулю.Кстати, а что за стайлгайд?
README.mdуreselect?Это уже ведет к:
И как я уже говорил, селектор не самодостаточный, вы просто это фиксите костылем в виде кастомного хука, по сути не получая ничего кроме потенциальных проблем с производительностью и специфичного кода, отличающегося от других проектов.
Согласен — было бы намного удобнее. Я бы вообще убрал параметр с кастомным компаратором, и вместо этого позволил пробрасывать произвольное число аргументов в селектор.
Производные от исходных данных в редьюсере — катастрофа на большом проекте. У меня однажды в одной фиче было где-то 40, если не больше, селекторов, между которыми были довольно сложные зависимости, с точки зрения всей картины. Полагаю, в редьюсер это было бы невозможно засунуть и проект бы несчадно лагал при любом экшне.
Селекторы и в частности `reselect` как раз позволяют строить зависимости между различными данными и достаточно эффективно производить пересчеты. И особенно хорошо, когда абсолютно все получение данных и мемоизация разруливаются там же (проецируя на предложение с `shallowEqual`).
Да, это один из посылов статьи)
И еще добавлю про саги — это как раз еще один костыль для редаксом, который дает ему возможность контролировать flow.
Более-менее жизнеспособное использование редакса строится именно из таких костылей. Саги — для control flow, селекторы — как замена всяким компьютедам, тулкит — как абстракция для некоторых продвинутых возможностей и фиксинга бойлерплейта.
Сам по себе редакс — просто очень примитивная технология без всего этого.
Во-первых, переопределяется другое, а именно - сравнение результата селектора с предыдущим. То есть, селектор все равно выполнится. Переопределение компаратора в большинстве случаев ничего не именит, если там не возвращается каждый раз новый объект, а вы не передали туда
shallowEqual. Вообще выглядит так, будто этот комментарий должен цитировать совсем другую часть текста (там, где было про сравнение через===.Ну и во-вторых, второй параметр
useSelector- костыль:Вместо 1 места (в селекторе) надо во всех местах его использования указывать функцию-компаратор - это все усложняет и ведет к ошибкам
Как указал @Carduelisв этом комменте - банально все может сломаться на более вложенной структуре
Хуже производительность
Не кажется ли, что лучше инкапсулировать мемоизацию в другом месте, чтобы коду снаружи не надо было думать о том, что там вообще будет возвращается и нужно ли это как-то отдельным способом сравнивать? При этом, такой подход изначально более эффективен, так как ничего лишнего каждый рендер не выполняется.
Киберпанк 2077 (трейлер)