Ещё немного и получатся haskell абстракции. Второй пример особенно ужасен, если между вызовами через пару лет вставят код и будут надеяться, что он не выполнится, если ранее возникла ошибка.
У меня два варианта
— слух что они собирались влить 20 лярдов в блокировку по сигнатурам не слух
— это была блокировка прокси внутри страны. Многие дц стоят до блокировок. Т.е. стоит монитор на выходе из страны и при попытке идти на сервера TG — бан
Мне нравится делать
docker-compose up
в корне монорепы и получать целиком рабочий проект. И эту команду выполняет каждый разработчик каждый день и она редко ломается, показывает как проект работает целиком. Монорепа уменьшает страхи сделать ещё один подпроект в виде микросервиса (в большой компании вам нужно пройти все круги ада на одобрение такого и рассказать всей команде, что нужно запускать +1 проект в деве). Единый процесс CI/CD, который крайне просто менять, потому что он один, а не 10+ в разных проектах (infrastructure as code, сейчас код деплоя лежит рядом с кодом приложения).
На другой стороне примеры проектов с десятком репозиториев, которые поддерживаются уже второй-третий год. Чтобы запустить каждый нужно немного магии, немного магии * 10 — это крайне МНОГО магии. Часто граф зависимостей не описан.
В идеальной компании полирепозиторий — хорошо, но такий крайне мало. В стартапе на 3-5 человек 10 репозиториев не нужны.
PS. Мы держим каждый frontend на react отдельно, потому что чисто фронтендщики не хотят заморачиваться или это не позволяет делать windows без боли. А весь бек лежит в монорепе.
Я несколько раз повторил, что это зависит от проекта и задачи, привел несколько вариантов решения. а вы выбрали простейший и говорите, что он «не для пользователя». Вам нужно — пишите. А я ради события, которое раз в год происходит не буду писать код, который нужно поддерживать, тестировать и не сломать через пару лет. Каждый день — напишу, каждую неделю — напишу, а увольнения админа в вакуме — нет.
Иначе мы получим базу отозванных токенов запросы к которой будут сравнимы по затратам с запросами профиля пользователя
В примере с уволенным админом достаточно держать в ENV переменной что-то вроде BLACKLIST_JWT через запятую. Вы не каждый день увольняете людей, поэтому так можно. Современный процессы continuous deployment позволяют менять env в течении пары минут.
Или ещё проще — делать blacklist на уровне балансера (nginx без проблем через map и if). Или в redis держать backlist jwt. Все очень сильно зависит от задач и проекта. Очень часто не нужно ничего навороченного.
Это вопрос инвалидации JWT в принципе. И решается кучей разных способов. Можно делать blacklist, можно отзывать secret, можно делать шардирование secret и отзывать один из 10 к примеру (чтобы 90% не вылетали) и тп.
Залить эпоксидкой же, само напрашивается.
karnage.io
zombsroyale.io
moomoo.io
примеры небанальных поглощалок
www.hashicorp.com/blog/load-balancing-strategies-for-consul
Там не указан traefik, но это можно просто в его доке посмотреть (в разделе Consul Catalog).
Легкий аналог redux/react-redux для react/preact от разработчика preact.
ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BD%D0%B3%D0%B5%D1%80%D1%81%D0%BA%D0%B0%D1%8F_%D0%BD%D0%BE%D1%82%D0%B0%D1%86%D0%B8%D1%8F
— слух что они собирались влить 20 лярдов в блокировку по сигнатурам не слух
— это была блокировка прокси внутри страны. Многие дц стоят до блокировок. Т.е. стоит монитор на выходе из страны и при попытке идти на сервера TG — бан
Хотя на один из них при первой проверке был красный.
docker-compose up
в корне монорепы и получать целиком рабочий проект. И эту команду выполняет каждый разработчик каждый день и она редко ломается, показывает как проект работает целиком. Монорепа уменьшает страхи сделать ещё один подпроект в виде микросервиса (в большой компании вам нужно пройти все круги ада на одобрение такого и рассказать всей команде, что нужно запускать +1 проект в деве). Единый процесс CI/CD, который крайне просто менять, потому что он один, а не 10+ в разных проектах (infrastructure as code, сейчас код деплоя лежит рядом с кодом приложения).
На другой стороне примеры проектов с десятком репозиториев, которые поддерживаются уже второй-третий год. Чтобы запустить каждый нужно немного магии, немного магии * 10 — это крайне МНОГО магии. Часто граф зависимостей не описан.
В идеальной компании полирепозиторий — хорошо, но такий крайне мало. В стартапе на 3-5 человек 10 репозиториев не нужны.
PS. Мы держим каждый frontend на react отдельно, потому что чисто фронтендщики не хотят заморачиваться или это не позволяет делать windows без боли. А весь бек лежит в монорепе.
В примере с уволенным админом достаточно держать в ENV переменной что-то вроде BLACKLIST_JWT через запятую. Вы не каждый день увольняете людей, поэтому так можно. Современный процессы continuous deployment позволяют менять env в течении пары минут.
Или ещё проще — делать blacklist на уровне балансера (nginx без проблем через map и if). Или в redis держать backlist jwt. Все очень сильно зависит от задач и проекта. Очень часто не нужно ничего навороченного.
apapacy промазал, для вас ответ.