Зависит от команды. Если команда согласна на 172 символа - вперед.
У нас в команде есть пользователи, любящие и умеющие эффективно работать на мелких ноутах. Для них ограничение в 72 символа - очень важно.
Для себя лично пришел к выводу: мне может и не важно ограничение в 72 символа, но придерживаться почти ничего не стоит. И кто и когда будет листать этот репозитарий, я не знаю, поэтому на всякий случай лучше придерживаться рекомендаций, в том числе и на длину строки, чтобы им было приятно.
А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.
Это абсолютно справедливо. Для любого инструмента.
Одно из главных правил Agile-методологий – команда-исполнитель принимает от заказчика изменения/ дополнения на любой стадии проекта.
Неверное заблуждение.
Agile - не про покорность исполнителя, и прием любых изменений в любое время.
Agile - про отсутствие деления на исполнителя и заказчика. Есть команда, ответственная за результат. И лицо, принимающее ключевые решение по свойствам продукта, такой же член команды, как и все остальные.
И главный критерий использования Agile-подхода - это не простота или сложность проекта. А возможность коротких итераций для выпуска новых версий продукта. Можете выкатывать в продажу чайник новой версии каждые 1-4 недели, флаг Agile'а вам в руки. Не можете - вам Agile не нужен.
И изменение приоритетов и переобувание по фичам продукта происходит как раз между итерациями. Их так и называют "спринт" - короткий забег на заранее определенную дистанцию. Потом остановка, определение нового направления и дистанции, и новый короткий забег. Во время забега, понятно, не до изменения требований, надо просто бежать.
Аналогии производства ПО и материальных объектов, действительно, уместны. Но ограничено.
Разница как раз в материальности объектов. На условном заводе новую деталь можно начать испытывать только после ее изготовления, а это всегда некоторый срок. На условном сервере, новый код можно начать испытывать условно через пару минут после пуша.
Что будет если испытания прошли неудачно? С деталькой - надо будет делать новую версию, а это опять некоторый срок. С кодом - в общем случае через пару минут можешь запушить новую версию.
И это разница в подходах - фундаментально влияет на организацию труда.
Понятно, что всегда можно придумать пограничные случаи, когда новую версию кода выпускают раз в несколько дней, а детальки печатают за несколько минут. Но то исключения, а не правило.
Это связано с тем, что данные денормализованы и не требуют дорогостоящих соединений между таблицами.
Денормализация денормализации рознь. Есть кейсы, когда нормализация наоборот ускоряет манипуляции с данными.
Для монги главный фактор для использования: требуется дешевое горизонтальное масштабирование. Во всех остальных случаях: стоит подумать нужна ли реально монга, потому что потом будет больно с нее съезжать, т.к. честный ACID снимает кучу головняков, не только для "денежных" сервисов.
Не слушайте никого. Nginx подходит для абсолютного большинства задач Load Balancing, Reverse Proxy для абсолютного большинства систем. Шило на мыло в общем. Есть некоторое небольшое количества задач и систем, в которых вместо Nginx действительно лучше использовать его альтернативы.
получение нового рефреш-токена должно быть идемпотентным
справедливости ради, повторное обновление рефреш-токена ограничивают из-за безопасности. на случай, если его получил злоумышленник. и что лучше, идемпотентность обновления рефреш-токена или безопасность - еще не решили.
Все беда в том, что многие думают, что микросервисы - это ответ на решение технических проблем.
Нет. Микросервисы - это ответ на проблемы масштабирования команд разработки. И основной критерий микросервисности - за один микросервис отвечает ровно одна команда. И соответственно, каждая команда пилит свой сервис без оглядки на другие команды, ответственность только на уровне контракта по API. Если одна команда может пилить большой сервис, aka монолит, и бизнес устраивает скорость поставки - все замечательно, пилим монолит.
Согласен. Любые предложения, начинающиеся со смены стандартного порта, лично я дальше не читаю. Это маркер, что люди не совсем понимают сетевые реалии. Настоятельно рекомендую всем остальным поступать также.
Почему BRE, а не CEP (Complex Event Processing)?
зачем админку убираем с публичного домена - понимаю.
зачем админку убираем совсем с ингресс-контроллера - не понимаю.
ну да ладно...
а повесить админку на отдельный ингресс или игресс-контроллер?
https://dubbo.apache.org/
Зависит от команды. Если команда согласна на 172 символа - вперед.
У нас в команде есть пользователи, любящие и умеющие эффективно работать на мелких ноутах. Для них ограничение в 72 символа - очень важно.
Для себя лично пришел к выводу: мне может и не важно ограничение в 72 символа, но придерживаться почти ничего не стоит. И кто и когда будет листать этот репозитарий, я не знаю, поэтому на всякий случай лучше придерживаться рекомендаций, в том числе и на длину строки, чтобы им было приятно.
Это абсолютно справедливо. Для любого инструмента.
Неверное заблуждение.
Agile - не про покорность исполнителя, и прием любых изменений в любое время.
Agile - про отсутствие деления на исполнителя и заказчика. Есть команда, ответственная за результат. И лицо, принимающее ключевые решение по свойствам продукта, такой же член команды, как и все остальные.
И главный критерий использования Agile-подхода - это не простота или сложность проекта. А возможность коротких итераций для выпуска новых версий продукта. Можете выкатывать в продажу чайник новой версии каждые 1-4 недели, флаг Agile'а вам в руки. Не можете - вам Agile не нужен.
И изменение приоритетов и переобувание по фичам продукта происходит как раз между итерациями. Их так и называют "спринт" - короткий забег на заранее определенную дистанцию. Потом остановка, определение нового направления и дистанции, и новый короткий забег. Во время забега, понятно, не до изменения требований, надо просто бежать.
Аналогии производства ПО и материальных объектов, действительно, уместны. Но ограничено.
Разница как раз в материальности объектов. На условном заводе новую деталь можно начать испытывать только после ее изготовления, а это всегда некоторый срок. На условном сервере, новый код можно начать испытывать условно через пару минут после пуша.
Что будет если испытания прошли неудачно? С деталькой - надо будет делать новую версию, а это опять некоторый срок. С кодом - в общем случае через пару минут можешь запушить новую версию.
И это разница в подходах - фундаментально влияет на организацию труда.
Понятно, что всегда можно придумать пограничные случаи, когда новую версию кода выпускают раз в несколько дней, а детальки печатают за несколько минут. Но то исключения, а не правило.
Не увидел _service в описании схемы у Squidex:
И упоминания federation на https://github.com/squidex/squidex
Хехе, краткий вывод практиков из комментариев (и я к ним присоединяюсь): не используйте UUID, кроме случаев, где без UUID по какой-то причине нельзя.
Вы приятно удивитесь, если в Postgres создадите структуры аналогичные CH.
Как у Squidex дела с GraphQL Federation?
Денормализация денормализации рознь.
Есть кейсы, когда нормализация наоборот ускоряет манипуляции с данными.
Для монги главный фактор для использования: требуется дешевое горизонтальное масштабирование. Во всех остальных случаях: стоит подумать нужна ли реально монга, потому что потом будет больно с нее съезжать, т.к. честный ACID снимает кучу головняков, не только для "денежных" сервисов.
Не слушайте никого. Nginx подходит для абсолютного большинства задач Load Balancing, Reverse Proxy для абсолютного большинства систем. Шило на мыло в общем.
Есть некоторое небольшое количества задач и систем, в которых вместо Nginx действительно лучше использовать его альтернативы.
реальные внедренцы САПа думают немного по другому
справедливости ради, повторное обновление рефреш-токена ограничивают из-за безопасности. на случай, если его получил злоумышленник. и что лучше, идемпотентность обновления рефреш-токена или безопасность - еще не решили.
Все беда в том, что многие думают, что микросервисы - это ответ на решение технических проблем.
Нет. Микросервисы - это ответ на проблемы масштабирования команд разработки. И основной критерий микросервисности - за один микросервис отвечает ровно одна команда. И соответственно, каждая команда пилит свой сервис без оглядки на другие команды, ответственность только на уровне контракта по API.
Если одна команда может пилить большой сервис, aka монолит, и бизнес устраивает скорость поставки - все замечательно, пилим монолит.
Похоже вы переизобрели OIDC Device Authorization.
Согласен. Любые предложения, начинающиеся со смены стандартного порта, лично я дальше не читаю. Это маркер, что люди не совсем понимают сетевые реалии. Настоятельно рекомендую всем остальным поступать также.
Для полноты картины: https://apiblueprint.org/
Вижу скрины с кодом, сразу ставлю плюс!