Более того. Нужно еще правильно определить проблему с условным Редисом. А то так можно бесконечно ритраиться...
Мы например пришли к тому что мы будем падать на любых ошибках подключения к внешним сервисам (базам например). Но, мы сделали нормальный graceful shutdown (что кстати имеет свои подводные камни) и у нас есть автоматический скейлинг.
Если у меня в команде будет решать тот кто делает, то потом не разгребешь. Если люди новые в команде да еще и без синьеров, то нужно сначала говорить что делать, добиваться того что бы понимали почему они это делают, и только когда они вырастут можно давать решать.
После 5 лет использования голого експресса с самописными обертками в стартапе после +100500 девелоперов которые приходили и уходили (вы даже представить себе не можете как сервисы выглядят изнустри), уже 2 года с NestJS, и результаты только положительные.
Правда мы и NestJS оборачиваем в собственный фреймворк, который позволяет генерировать рабочие темплейты со структурой onion/clean architecture + готовыми инжекторами ко всем тулзам/базам мы используем, тем самым более менее ограничивая и направляя девелоперов писать в определенном стиле, который можно легко тестировать, понимать и рефакторить, сосредоточившись на написании бизнес логики.
NestJS это Java Spring/ASP.NET MVC на минималках, поэтому многим девелоперам сравнительно легко в него зайти.
З.Ы.
Ошибки депенденси действительно все еще вызывают дискомфорт, но после полного понимания как оно работает становится легче.
Мне все еще кажется что graphql может быть идеальным инструментом когда он идет в одну таблицу/коллекцию где ВСЕ данные уже собраны. Т.е. read side от CQRS. Фронтендеры и клиенты получают унифицированный язык и это хороше.
А вот когда туда запихивают запросы к разным сущностям, базам, коллекциям, я даже не представляю как оно может нормально работать при нагрузке.
Ну это то что я и предлагаю в решении на SQL. Переезжаем на sql и копируем пермишены в локальную базу по которой производится поиск данных с фильтрами по различным полям + определенному работнику можно видеть определенны листинги.
В монге это ничего не дает потому что нет джоинов...
Мой поинт в том что везде обсуждаются красивые решения по доступу по id к какому-то агрегату. Это сравнительно легко. Да, есть ньюансы, но если делать правильно можно разделить логику пермишенов и бизнес логику.
Но вот как только нужно фильтровать сет данных, получается очень тяжелый кауплинг к пермишенам если нам приходится копировать всегда релейшены в локальную базу... либо пермишены достаются из другого хранилища, и убивается перформанс когда передаются например 10K монговских айдишников в квери в виде $in: [...ids]
Мне интересно как люди имплементируют проверку доступа к документам/филдам в рипортах когда у нас many to many и гранулярность по id
Объясню.
Есть работник. Работнику разрешают доступ к определенномым ресурсам с определенными айдишниками. Например, работнику Worker_1 можно "видеть" листинги с айдишниками Listing_1, Listing_2, .... ,без ограничений. Worker_2 тоже может видеть те же листинги и другие. Мэни ту мэни...
И есть GUI/API поиска всех листингов в системе. Продукт манагеры хотят что бы работнику показывались только листинги которые ему можно смотреть.
Сегодня у нас это реализовано в лоб с фильтрацией в базе (монга). Что то вроде:
allowedListingIds = permissions.getAllowedListingIds(workerId); // пермишены хранятся где то в редисе
Когда-то любил дженерики на жаве когда под андроид писал. Ждал женерики на го. Никак не могу побороть дискомфорт от этого вырвиглазного синтакса :/
Да, понимаю зачем и почему синтаксис именно такой. Да, думаю привыкну... и все же, не покидает меня чувство что в той же жаве или c# женерики очень просто и понятный концепт с очень простым синтаксисом. Тут же в "простом го" и на дженерики надо еще правила использования помнить...
Почему глядя на go женерики я не испытываю удовольствия?
Боялся читать... я ведь тех. лид. Но страхи не оправдались.
У нас у каждой команды есть свой тим лид и продакт менеджер. Их обязанности строго обозначены.
Все что касается менеджмента, приоритетов, спринтов ко мне не относится.
Но, мне дали самому построить роль и решать чем я буду заниматься. Я вырос в команде, поэтому отношения с девелоперами норм. Отношения с тим лидами и продуктами приходится немного выстраивать по новому, потому что от меня могут прилететь технические таски.
Но, до меня в компании были попытки "создания" тех лидов. Как и тог, люди просто ушли. Потому что это был тех лид на бумажке, а по факту никто не знал что с ним делать. Либо они так же оставались работать в спринтах, что убивало напрочь возможность тех лидить, либо убирали со спринтов но никто не понимал что дальше с тех лидом делать.
Благодаря OMG Essence можно за две недели освоиться с реальным проектом, который рассчитан на десятилетие разработки и внедрения
А если проект рассчитан на 1-3 месяца разработки роллаут, стоит ли заморачиваться? Например в контексте стартапа, где работа идет над внутренними проектами, которые пилятся быстро так как важен time to market.
Кто может быть заинтересован во внедрении этого стандарта в стартапе? Например я как тех. лид. не вижу как я могу заинтересовать разработчиков заниматься этим, хотя мне лично это интересно так как я являюсь техническим лидом нескольких проектов одновременно, но не являюсь менеджером.
Кто должен этим заниматься (всем тем что описано в статье)? Team Lead? Project manager? Кто несет ответственность за апдейт документов и состоянии?
Не понимаю почему минуса. Тоже интересует этот вопрос, особенно в контексте agile. Вот приходит новый человек в команду/компанию. Его самого сначала нужно научить этому методу, и потом уже возможно, оно за 2 недели разберется в проекте.
Согласовать требования? А вы точно в стартапах работали? Речь идет именно от стартапах а не обычно продукте для клиента.
Возьмите любой стартап который не умер на старте и продержался хотя бы 3-4 года... откройте сорс код в гите посмотрите коммиты... от initial и до настоящего времени. И попробуйте найти хоть какие-то документы связанные с коммитами =))
Если это не военная, атомная, или медицинская промышленность, где любой апдейт программы согласовывается месяцами если не годами по очень жестким ISO, то фичер делается очень быстро что бы дать клиенту хоть что-то, и уже потом напильником... потому что через месяц может оказаться так что не взлетело и клиенту оно уже не нужно... и потеря времени и денег будет минимальна.
Очень важную роль играет израильский менталитет. Там где американцы или немцы будут пытаться делать все по правилами и по книжечке, израильтяне найдут обходной путь, который пусть и не будет давать 100% результат, но все таки будет решать проблему хотя-бы частично.
У нас популярен вот такой рассказ. Извините что на английском (Oren-Shamir):
Imagine you're an executive in a big American company that makes home appliances. Your market research team suggests that people may want to have straight bananas, since Americans love to slice bananas up and put them in a sandwich or a cereal bowl, and straight bananas are easier to slice.
You decide to try and solve this problem using both of your R&D teams. One is located in the US and the other in Israel. You call the two team leaders and tell them what you need - a machine that bends bananas backwards to straighten them up.
The American team leader says they will get right on it. The next morning he posts a job opening on Linkedin, looking for a banana expert. He hires a guy from CalTech who knows everything there is to know about the molecular structure of bananas. He also hires two more engineers and an industrial designer. Initially.
After around 24-30 months of hard work, you have a sleek, shiny new machine that bends bananas backwards and produces perfect, straight as an arrow bananas 100% of the time, with any kind of banana that currently exists. It costs about 300 dollars and needs as much power as a small refrigerator.
At the same time, the Israeli team leader listens to you for about 3 minutes then interrupts to say that this is a really stupid idea. He doesn't know anybody who slices bananas. Israelis just eat them. Although we usually do peel them first. He suggests you might want to build a machine that peels bananas.
After a long, frustrating meeting you give up. But on his way home, the Israeli team leader thinks about what you asked him to do, and while he still thinks it's a stupid idea, he likes the challenge. The next morning he calls a couple of friends from the Kibuts who grow bananas and then he lets you know that his team will have a machine ready within a week.
After exactly 11 days the machine is indeed ready and a demonstration is scheduled. The machine is made out of spare parts of Uzi guns and costs 13$ to build. It also functions as an emergency torch. It looks like a scaled down model of a tractor accident. It also produces perfect, straight as an arrow bananas... in about 62.5% of the cases. 37% of the bananas are either broken, squashed or toasted beyond recognition. About half a percent of the bananas mysteriously disappear.
When you note these shortcomings to the Israeli team they look at you with complete puzzlement. The machine, they would tell you, does exactly what you asked for and the PRD never stated it has to do it to ALL the bananas you throw at it. Some bananas are obviously defected. Besides, it was a stupid idea to begin with.
So this is how we are:
We're really good at improvising
We think we're smarter than most
We help each other out
We prefer to cut corners, and get to the chase
We say exactly what we think (but we're not always happy with criticism)
We LOVE to argue. We argue with our commanders in the army, with our professors in the university and with our bosses at work. We have a "healthy" disrespect for authority
В монолите очень сложно следить за тем кто и что делает и кто какие модули импортит.
Все таки в трушных микросервисах кодовая база на порядок меньше, доступ к коду имеют только реальные овнеры, так что никто ничего там не изменит без открытия нового пиара и никто не заюзает твой модуль так что тебе что бы что-то изменить нужно тестировать пол системы.
Да, в монолите нужно следить за архитектурой. И в любом монолите все начинается красиво. Папочки всякие, модули.... а потом через 5 лет и +100500 разработчиков через которых прошел этот код все превращается в кашу.
Микросервисы конечно приезжают со своими проблемами, но все таки ряд проблем они решают очень хороше.
Т.е. подход "созидателя" и "разрушителя" - переключить свой образ мышления с одного подхода на другой - практически невозможно
Есть какие-то исследования что бы это утверждать? Ну джуниоры может быть и не могут в силу отсутствия опыта. Но не вижу причин что бы разработчик с 10+ лет опыта не понимал как он может сломать собственный код. Наоборот, он реально понимает что и как там работает и может накидать еще десятки кейсов как это сломать.
Другое дело что ему как разработчику не интересно заниматься QA.
Для меня QA это хакер не минималках. И я не думаю что существуют хорошие хакеры которые сами не являются программистами. Поэтому не могу согласиться с утверждением что разработчики не могут делать QA в силе разного мышления. Там много других причин.
Странно читать. Мы наоборот переходим с раббита на кафку в местах где нужны несколько консюмеров, для декаплинга доменов, где нужен order of messages например в скопе аккаунта или на более гранулярном уровне например reservation, или нужна sequence обработка что бы уменьшить оверхед работы optimistic concurrency.
Раббит попрежнему используем для round robin обработки, ритраев, роутинга и т.д.
Я думаю что все таки зависит от целей и бизнеса. Так категорично менять раббит на кафку везде мы бы не стали.
Более того. Нужно еще правильно определить проблему с условным Редисом. А то так можно бесконечно ритраиться...
Мы например пришли к тому что мы будем падать на любых ошибках подключения к внешним сервисам (базам например). Но, мы сделали нормальный graceful shutdown (что кстати имеет свои подводные камни) и у нас есть автоматический скейлинг.
100%
Если у меня в команде будет решать тот кто делает, то потом не разгребешь. Если люди новые в команде да еще и без синьеров, то нужно сначала говорить что делать, добиваться того что бы понимали почему они это делают, и только когда они вырастут можно давать решать.
После 5 лет использования голого експресса с самописными обертками в стартапе после +100500 девелоперов которые приходили и уходили (вы даже представить себе не можете как сервисы выглядят изнустри), уже 2 года с NestJS, и результаты только положительные.
Правда мы и NestJS оборачиваем в собственный фреймворк, который позволяет генерировать рабочие темплейты со структурой onion/clean architecture + готовыми инжекторами ко всем тулзам/базам мы используем, тем самым более менее ограничивая и направляя девелоперов писать в определенном стиле, который можно легко тестировать, понимать и рефакторить, сосредоточившись на написании бизнес логики.
NestJS это Java Spring/ASP.NET MVC на минималках, поэтому многим девелоперам сравнительно легко в него зайти.
З.Ы.
Ошибки депенденси действительно все еще вызывают дискомфорт, но после полного понимания как оно работает становится легче.
Мне все еще кажется что graphql может быть идеальным инструментом когда он идет в одну таблицу/коллекцию где ВСЕ данные уже собраны. Т.е. read side от CQRS. Фронтендеры и клиенты получают унифицированный язык и это хороше.
А вот когда туда запихивают запросы к разным сущностям, базам, коллекциям, я даже не представляю как оно может нормально работать при нагрузке.
Еще никто меня не смог переубедить :/
Ну это то что я и предлагаю в решении на SQL. Переезжаем на sql и копируем пермишены в локальную базу по которой производится поиск данных с фильтрами по различным полям + определенному работнику можно видеть определенны листинги.
В монге это ничего не дает потому что нет джоинов...
Мой поинт в том что везде обсуждаются красивые решения по доступу по id к какому-то агрегату. Это сравнительно легко. Да, есть ньюансы, но если делать правильно можно разделить логику пермишенов и бизнес логику.
Но вот как только нужно фильтровать сет данных, получается очень тяжелый кауплинг к пермишенам если нам приходится копировать всегда релейшены в локальную базу... либо пермишены достаются из другого хранилища, и убивается перформанс когда передаются например 10K монговских айдишников в квери в виде $in: [...ids]
Мне интересно как люди имплементируют проверку доступа к документам/филдам в рипортах когда у нас many to many и гранулярность по id
Объясню.
Есть работник. Работнику разрешают доступ к определенномым ресурсам с определенными айдишниками. Например, работнику Worker_1 можно "видеть" листинги с айдишниками Listing_1, Listing_2, .... ,без ограничений. Worker_2 тоже может видеть те же листинги и другие. Мэни ту мэни...
И есть GUI/API поиска всех листингов в системе. Продукт манагеры хотят что бы работнику показывались только листинги которые ему можно смотреть.
Сегодня у нас это реализовано в лоб с фильтрацией в базе (монга). Что то вроде:
allowedListingIds = permissions.getAllowedListingIds(workerId); // пермишены хранятся где то в редисеlistingsCollection.find({...., _id: {$in [...allowedListingIds]};А теперь представьте когда на воркере 10k айдишников... перформанс гамно как в базе так и в коде.
Не передавать айдишники в базу и фильтровать в рантайме - будет еще хуже...
Вижу 2 решения
1- переезд на sql и копировать пермишены в базу листингов, и джоинить на уровне базы
2 - остаемся в монге, и дуплицируем листинг пер работник и фильтровать по listing.workerId
Хранить список работников на листинге мы не можем потому что их может быть неограниченно количество и мы упремся в 16мб монги.
В итоге база увеличится в разы + проблема множественных апдейтов...
з.ы.
Лонг стори шорт, не получается придумать что-то что будет работать быстро без копирования либо пермишинов либо данных.
Когда-то любил дженерики на жаве когда под андроид писал. Ждал женерики на го. Никак не могу побороть дискомфорт от этого вырвиглазного синтакса :/
Да, понимаю зачем и почему синтаксис именно такой. Да, думаю привыкну... и все же, не покидает меня чувство что в той же жаве или c# женерики очень просто и понятный концепт с очень простым синтаксисом. Тут же в "простом го" и на дженерики надо еще правила использования помнить...
Почему глядя на go женерики я не испытываю удовольствия?
Так все таки сами практики бессмысленные или все таки неправильное использование практик является проблемой?
Боялся читать... я ведь тех. лид. Но страхи не оправдались.
У нас у каждой команды есть свой тим лид и продакт менеджер. Их обязанности строго обозначены.
Все что касается менеджмента, приоритетов, спринтов ко мне не относится.
Но, мне дали самому построить роль и решать чем я буду заниматься. Я вырос в команде, поэтому отношения с девелоперами норм. Отношения с тим лидами и продуктами приходится немного выстраивать по новому, потому что от меня могут прилететь технические таски.
Но, до меня в компании были попытки "создания" тех лидов. Как и тог, люди просто ушли. Потому что это был тех лид на бумажке, а по факту никто не знал что с ним делать. Либо они так же оставались работать в спринтах, что убивало напрочь возможность тех лидить, либо убирали со спринтов но никто не понимал что дальше с тех лидом делать.
А также в snowflake :/
А если проект рассчитан на 1-3 месяца разработки роллаут, стоит ли заморачиваться? Например в контексте стартапа, где работа идет над внутренними проектами, которые пилятся быстро так как важен time to market.
Кто может быть заинтересован во внедрении этого стандарта в стартапе? Например я как тех. лид. не вижу как я могу заинтересовать разработчиков заниматься этим, хотя мне лично это интересно так как я являюсь техническим лидом нескольких проектов одновременно, но не являюсь менеджером.
Кто должен этим заниматься (всем тем что описано в статье)? Team Lead? Project manager? Кто несет ответственность за апдейт документов и состоянии?
Не понимаю почему минуса. Тоже интересует этот вопрос, особенно в контексте agile. Вот приходит новый человек в команду/компанию. Его самого сначала нужно научить этому методу, и потом уже возможно, оно за 2 недели разберется в проекте.
Может сразу в польскую нотацию?
https://ru.wikipedia.org/wiki/Польская_запись
Согласовать требования? А вы точно в стартапах работали? Речь идет именно от стартапах а не обычно продукте для клиента.
Возьмите любой стартап который не умер на старте и продержался хотя бы 3-4 года... откройте сорс код в гите посмотрите коммиты... от initial и до настоящего времени. И попробуйте найти хоть какие-то документы связанные с коммитами =))
Если это не военная, атомная, или медицинская промышленность, где любой апдейт программы согласовывается месяцами если не годами по очень жестким ISO, то фичер делается очень быстро что бы дать клиенту хоть что-то, и уже потом напильником... потому что через месяц может оказаться так что не взлетело и клиенту оно уже не нужно... и потеря времени и денег будет минимальна.
Очень важную роль играет израильский менталитет. Там где американцы или немцы будут пытаться делать все по правилами и по книжечке, израильтяне найдут обходной путь, который пусть и не будет давать 100% результат, но все таки будет решать проблему хотя-бы частично.
У нас популярен вот такой рассказ. Извините что на английском (Oren-Shamir):
Imagine you're an executive in a big American company that makes home appliances. Your market research team suggests that people may want to have straight bananas, since Americans love to slice bananas up and put them in a sandwich or a cereal bowl, and straight bananas are easier to slice.
You decide to try and solve this problem using both of your R&D teams. One is located in the US and the other in Israel. You call the two team leaders and tell them what you need - a machine that bends bananas backwards to straighten them up.
The American team leader says they will get right on it. The next morning he posts a job opening on Linkedin, looking for a banana expert. He hires a guy from CalTech who knows everything there is to know about the molecular structure of bananas. He also hires two more engineers and an industrial designer. Initially.
After around 24-30 months of hard work, you have a sleek, shiny new machine that bends bananas backwards and produces perfect, straight as an arrow bananas 100% of the time, with any kind of banana that currently exists. It costs about 300 dollars and needs as much power as a small refrigerator.
At the same time, the Israeli team leader listens to you for about 3 minutes then interrupts to say that this is a really stupid idea. He doesn't know anybody who slices bananas. Israelis just eat them. Although we usually do peel them first. He suggests you might want to build a machine that peels bananas.
After a long, frustrating meeting you give up. But on his way home, the Israeli team leader thinks about what you asked him to do, and while he still thinks it's a stupid idea, he likes the challenge. The next morning he calls a couple of friends from the Kibuts who grow bananas and then he lets you know that his team will have a machine ready within a week.
After exactly 11 days the machine is indeed ready and a demonstration is scheduled. The machine is made out of spare parts of Uzi guns and costs 13$ to build. It also functions as an emergency torch. It looks like a scaled down model of a tractor accident. It also produces perfect, straight as an arrow bananas... in about 62.5% of the cases. 37% of the bananas are either broken, squashed or toasted beyond recognition. About half a percent of the bananas mysteriously disappear.
When you note these shortcomings to the Israeli team they look at you with complete puzzlement. The machine, they would tell you, does exactly what you asked for and the PRD never stated it has to do it to ALL the bananas you throw at it. Some bananas are obviously defected. Besides, it was a stupid idea to begin with.
So this is how we are:
We're really good at improvising
We think we're smarter than most
We help each other out
We prefer to cut corners, and get to the chase
We say exactly what we think (but we're not always happy with criticism)
We LOVE to argue. We argue with our commanders in the army, with our professors in the university and with our bosses at work. We have a "healthy" disrespect for authority
We love challenges and dislike wasted talent
We like to tell stories
ПХП покинул лет 8 назад... в NODEJS мы используем datadog. Подключаешь библиотеку и из коробки получаешь очень много плюшек. Привем трейсинга:
Вроде как и для пхп есть либа: https://github.com/DataDog/dd-trace-php
Но, дорого...
В монолите очень сложно следить за тем кто и что делает и кто какие модули импортит.
Все таки в трушных микросервисах кодовая база на порядок меньше, доступ к коду имеют только реальные овнеры, так что никто ничего там не изменит без открытия нового пиара и никто не заюзает твой модуль так что тебе что бы что-то изменить нужно тестировать пол системы.
Да, в монолите нужно следить за архитектурой. И в любом монолите все начинается красиво. Папочки всякие, модули.... а потом через 5 лет и +100500 разработчиков через которых прошел этот код все превращается в кашу.
Микросервисы конечно приезжают со своими проблемами, но все таки ряд проблем они решают очень хороше.
Есть какие-то исследования что бы это утверждать? Ну джуниоры может быть и не могут в силу отсутствия опыта. Но не вижу причин что бы разработчик с 10+ лет опыта не понимал как он может сломать собственный код. Наоборот, он реально понимает что и как там работает и может накидать еще десятки кейсов как это сломать.
Другое дело что ему как разработчику не интересно заниматься QA.
Для меня QA это хакер не минималках. И я не думаю что существуют хорошие хакеры которые сами не являются программистами. Поэтому не могу согласиться с утверждением что разработчики не могут делать QA в силе разного мышления. Там много других причин.
Странно читать. Мы наоборот переходим с раббита на кафку в местах где нужны несколько консюмеров, для декаплинга доменов, где нужен order of messages например в скопе аккаунта или на более гранулярном уровне например reservation, или нужна sequence обработка что бы уменьшить оверхед работы optimistic concurrency.
Раббит попрежнему используем для round robin обработки, ритраев, роутинга и т.д.
Я думаю что все таки зависит от целей и бизнеса. Так категорично менять раббит на кафку везде мы бы не стали.
Но вот некоторые вещи из статьи пригодятся!
Вот я и пытаюсь понять чем обычный nock для мокинга выходящих http запросов не подходит?