Видимо сложность вот в чем: есть у нас абстрактный пользователь, у него дефолтные 2 запроса в секунду, дальше он зарегался у нас и вошел, окей, мы теперь говорим ему, что у него 5 запросов в секунду. Но при этом, если у этих пользователей набирается, ну представим себе что 20к запросов в сутки, мы говорим им пока. Но пользователь он допустим бабки еще кидает, то у него будет 10 запросов в секунду, но максимум 100к, а если кидает прям хорошо бабок, то и лимиты повыше.
И еще такой момент, к некоторым апи отдельные тротлеры привязаны, например у нас глобально — 10rps для пользователя, есть /api/a и есть /api/b где отдельный троттлер на 5rps, но всего у нас для пользователя 10rps. Ну то есть в некоторых случаях мы должны проверить аж три раза что пользователь может это сделать — глобально, в целом и частный случай.
Так вот, как это быстро сделать при помощи конфигов нжинса, когда есть пяток способов изменить стейт у пользователя?
Расскажу про пару случаев из жизни, примерно два года назад побеседовал человека, 11 лет опыта разработки, две компании с громким именем, далеко не посредственные проекты, зная специфику нашего проекта спрашиваю про всякие штуки связанные с многопоточностью, на что получаю невразумительный ответ, что не нужна она в начале 2018 года и все проблемы можно решить при помощи подхода Х, так как это был уже третий вопрос по делу, на который этот сеньор софтвейр енжинер не смог толком ответить (а собственно решение уже принято), время — вечер, и рабочий день у меня закончился, то цепляюсь за его ответ и предлагаю посмотреть код, и вместе решить, как можно этот подход применить (ладно, тут еще был один фактор, я немного сменил область деятельности и активно знакомился с этим подходом, личный интерес...).
После часа общения, он приходит в состояние ступора, потому что он никогда раньше не работал с приложениями у которых есть внутренний богатый стейт, и это внутри как-то общается между собой. Оба приходим к выводу, что в нашем случае подход Х можно использовать лишь частично, потому что особого профита он не даст.
Кстати, он тем же вечером сам ответил, что не готов пойти к нам работать, потому что неинтересно ему. Ему не интересно писать кучу кода, своими руками.
Случай второй, собеседуем другого сеньора, он категорически отказывается писать код, и рассуждает как бы он это сделал и что бы применил из фреймворков, подходов, мой коллега улыбается, так как они это все уже прошли, и сейчас хотят к себе человека, который будет готов писать код, бизнес логика в некоторых местах достаточно сложная и требуется понимание того, что творишь. Как итог склонили кандидата показать код своего пет прожекта, банальное ревью на 15 минут выявило несколько проблем, в том числе и с перфомансов. Вдобавок — пару багов.
Я уверен на больше чем сто процентов, что если человек, начнет ее придумывать, по остаткам воспоминаний о ней и будет это озвучивать, то встречными вопросами и подсказками вместе с интервьювером они придут к этому алгоритму и это будет засчитан как нехилый такой плюс.
У друзей сейчас та же самая история, давайте все писать реактивно, и так же, если метод делает какую-то бизнес логику, и даже не думает лезть во внешние сервисы, он должен быть реактивным. В результате чего куча проблем на ровном месте
Это правда, есть много разных способов себе навредить, но этот пост по сути вырос, как у комментатора выше, из доведение использования одной из технологий до абсурда, ну а ранним утром в понедельник мне действительно нечего было делать, и я решил немного поиграться с реактивной совсем в ином контексте
Ох, из последнего, с чем пришлось столкнуться, была задача — для каждого пользователя необходимо сделать троттлинг по запросам, например не чаще двух запросов в секунду от одного пользователя. Первоначальная реализация была через таблицу в обычной базе данных, работала плохо и очень часто неправильно, с последующими костылями стала работать лучше, но скорость оставляла желать лучшего. Реализация c редисом была лучше, но так же имела свои минусы. По итогу я плюнул и написал свою реализацию, которая работает уже как полгода, выдерживает примерно 100-1500 запросов в секунду (при нагрузочном тесте использовались показатели примерно в 10 раз выше).
У меня однажды на собеседовании была задача, написать потокобезопасный map с открытой адресацией, но при этом я это делал на своем ноутбуке, у меня был доступ ко всему интернету, уже подготовленный проект с тестами и у меня было чуть больше двух часов времени и потом я объяснял почему я сделал именно так. И не смотря на то, что это было адски сложно, это было на самом деле круто. И да, за два часа написать это правильно — нереально, если только ты постоянно такие штуки не пишешь. Но важно было то, как я это сделал.
Я согласен с тем, что спрашивать на собеседования про алгоритмы сортировки это моветон, хотя есть много интересных задач, которые очень быстро и легко решаются, например при использовании того же mergesort/heapsort.
Да и в целом, как можно доверять человеку, который, например не знает отличия list от set или, например, не может инвертнуть простое сапомисное дерево из нод c value, left, right. Ну и понятия не имеет, что такое сложность алгоритма.
Почему-то многие считают, что алгоритмы это что-то такое непоколебимое и не подвержено изменению, но в какой-то момент эти люди узнают, что на основе многих современных алгоритмов можно решать очень эффективно вполне реальные бизнес задачи.
Если человек прекрасно знает алгоритмы и структуры данных, то в большинстве случаев, он так же неплохо понимает как правильно следует использовать все те инструменты, которые он использует каждый день, плюсы, минусы и ограничения технологий, потому что все алгоритмы и структуры данных, как раз таки про ограничения, чем придется жертвовать ради того, что бы это работало быстро и не отбирало всю свободную память.
Люди, которые только и умеют брать инструмент и его использовать, умеют только брать инструменты, которые за них давно уже выбрали и использовать их, причем иногда так, что хочется плакать.
— нормальный senior не станет кодить с нуля, а вкрячит библиотечный метод или фреймворк который все это делает, тем он и отличается от junior-а.
Вот так и появляются сеньоры, которые не способны сами написать и 10 строчек кода, а если дело касается не стандартного флот — достал из базы, поменял пару значений, перевернул в другой объект, кинул дальше — то код получается на уровне того, что пишут джуты-самоучки.
Занимательный факт, большинство людей, которые считают, что не нужно ничего знать самому, нужно только взять библиотеку и впихнуть, работают с этим стандартным флоу и считают, что остальные области не существуют как факт. А все то, чем они пользуются пишет какой-то мегамозг, потому что ему больше нечем заняться
И еще такой момент, к некоторым апи отдельные тротлеры привязаны, например у нас глобально — 10rps для пользователя, есть /api/a и есть /api/b где отдельный троттлер на 5rps, но всего у нас для пользователя 10rps. Ну то есть в некоторых случаях мы должны проверить аж три раза что пользователь может это сделать — глобально, в целом и частный случай.
Так вот, как это быстро сделать при помощи конфигов нжинса, когда есть пяток способов изменить стейт у пользователя?
После часа общения, он приходит в состояние ступора, потому что он никогда раньше не работал с приложениями у которых есть внутренний богатый стейт, и это внутри как-то общается между собой. Оба приходим к выводу, что в нашем случае подход Х можно использовать лишь частично, потому что особого профита он не даст.
Кстати, он тем же вечером сам ответил, что не готов пойти к нам работать, потому что неинтересно ему. Ему не интересно писать кучу кода, своими руками.
Случай второй, собеседуем другого сеньора, он категорически отказывается писать код, и рассуждает как бы он это сделал и что бы применил из фреймворков, подходов, мой коллега улыбается, так как они это все уже прошли, и сейчас хотят к себе человека, который будет готов писать код, бизнес логика в некоторых местах достаточно сложная и требуется понимание того, что творишь. Как итог склонили кандидата показать код своего пет прожекта, банальное ревью на 15 минут выявило несколько проблем, в том числе и с перфомансов. Вдобавок — пару багов.
На редис там и так хорошая нагрузка была, поэтому было принято решение использовать что-то еще
Да и в целом, как можно доверять человеку, который, например не знает отличия list от set или, например, не может инвертнуть простое сапомисное дерево из нод c value, left, right. Ну и понятия не имеет, что такое сложность алгоритма.
Люди, которые только и умеют брать инструмент и его использовать, умеют только брать инструменты, которые за них давно уже выбрали и использовать их, причем иногда так, что хочется плакать.
Вот так и появляются сеньоры, которые не способны сами написать и 10 строчек кода, а если дело касается не стандартного флот — достал из базы, поменял пару значений, перевернул в другой объект, кинул дальше — то код получается на уровне того, что пишут джуты-самоучки.
Занимательный факт, большинство людей, которые считают, что не нужно ничего знать самому, нужно только взять библиотеку и впихнуть, работают с этим стандартным флоу и считают, что остальные области не существуют как факт. А все то, чем они пользуются пишет какой-то мегамозг, потому что ему больше нечем заняться