Понятно что проблема наша. Но в любом нормальном языке стэк экономит кучу дорогого времени.
В 99% случав обработка ошибок это как тут уже написали
if err != nil { return err }
Можно все делать правильно что б по книжачке. Но реальность она другая немного.
Не понимаю сопротивления. Какие факты могут оспорить то что глядя на стэк сразу же понимаеш где что случилось, вне зависимости от того обернул кто то ошибку или нет.
И где тут стэк? Иди ищи по коду кто кого там вызвал. Это ад.
И предположение что все ну прям будут оборачивать все и вся... ну может в етнерпрайзе. А я вот в мире стартапов верчусь, там все плохо. И без стэка не выжить.
Из-за безисходности некоторые начинают панику кидать что бы иметь стэк... ну и вроде как библиотечки какие-то есть. Одним словом, мыши плакали но продолжали есть кактус.
Сегодня весь мир крутится вокруг апишек, разбора джейсонов и мапинга с одной структуры в другую. Зиро валюес это оно конечно красиво, но реальность такова что людям приходится писать вот такие вот библиотечки что бы не сойти с ума разбирая джейсоны где буквально все optional и никто ничего не обещает.
Ну если у вас в проде такой код то оно конечно да. А когда кода на 10К строчек, разные слои и флоу... и ошибка прилетает откуда-то очень изнутри, из какой нибудь библиотечки, в то удачи вам в 3 часа ночи на блокере разобраться что случилось. А если ошибка еще и с динамическим текстом то все еще веселее.
Ну серьезно, сколько лет прошло, а люди все равно сопротивляются удобствам. Нет ничего удобнее и быстрее чем посмотреть на стэк и понять где проблема началось и откуда конкретно прилетела ошибка.
Удобней чем? Хорошему IDE пофиг как это выглядит. Все что нужно мне как девелоперу, это возможность кликнуть и перейти в файл + автокомплит IDE который заимпортит файл и поставит правильный путь сам.
Заниматься настройкой всего это чуда и потенциальные проблемы с этим в будущем не стоят потраченного времени.
И я понимаю почему синьоры этим не занимались. Потому что есть более серьезные проблемы четь удобство путей к файликам. А еще синьеры понимают что если что-то поломается, они будут это чинить...
P.S.
Если когда нибудь это будет из коробки, это другой разговор.
а при обновлении модели в первую очередь нужно обновлять консьюмеры
Никак не могу понять что это значит. Например если я удалил поле которые не использовалось консюмером. Что мне обновлять там? Или же имеется ввиду ристарт что бы новая сема подтянулась?
Более того. Нужно еще правильно определить проблему с условным Редисом. А то так можно бесконечно ритраиться...
Мы например пришли к тому что мы будем падать на любых ошибках подключения к внешним сервисам (базам например). Но, мы сделали нормальный 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 женерики я не испытываю удовольствия?
Боялся читать... я ведь тех. лид. Но страхи не оправдались.
У нас у каждой команды есть свой тим лид и продакт менеджер. Их обязанности строго обозначены.
Все что касается менеджмента, приоритетов, спринтов ко мне не относится.
Но, мне дали самому построить роль и решать чем я буду заниматься. Я вырос в команде, поэтому отношения с девелоперами норм. Отношения с тим лидами и продуктами приходится немного выстраивать по новому, потому что от меня могут прилететь технические таски.
Но, до меня в компании были попытки "создания" тех лидов. Как и тог, люди просто ушли. Потому что это был тех лид на бумажке, а по факту никто не знал что с ним делать. Либо они так же оставались работать в спринтах, что убивало напрочь возможность тех лидить, либо убирали со спринтов но никто не понимал что дальше с тех лидом делать.
Т.е. оборачивать логгером все вызовы функций? =))
Потому как имея
err := MyFunc();if err != nil {log(line, err);}
не скажет вам в каком месте в MyFunc была ошибка если там
MyFunc() {err := func1()if err != nil {return err;}err := func2()if err != nil {return err;}err := func...N()if err != nil {return err;}}А в каждой такой функции есть еще функции функции... а там внутри еще и опенсорсные пекеджи...
Что только не сделаешь в отсутствие стэка.
Если бы это было удобнее, у этой либы не было бы 12к звездочек и 500 форков.
Понятно что всегда можно вырулить. А пока что, я мечтаю о GO но пишу на TS.
Простые вещи должно быть просто делать.
Понятно что проблема наша. Но в любом нормальном языке стэк экономит кучу дорогого времени.
В 99% случав обработка ошибок это как тут уже написали
if err != nil { return err }Можно все делать правильно что б по книжачке. Но реальность она другая немного.
Не понимаю сопротивления. Какие факты могут оспорить то что глядя на стэк сразу же понимаеш где что случилось, вне зависимости от того обернул кто то ошибку или нет.
И где тут стэк? Иди ищи по коду кто кого там вызвал. Это ад.
И предположение что все ну прям будут оборачивать все и вся... ну может в етнерпрайзе. А я вот в мире стартапов верчусь, там все плохо. И без стэка не выжить.
Из-за безисходности некоторые начинают панику кидать что бы иметь стэк... ну и вроде как библиотечки какие-то есть. Одним словом, мыши плакали но продолжали есть кактус.
Сегодня весь мир крутится вокруг апишек, разбора джейсонов и мапинга с одной структуры в другую. Зиро валюес это оно конечно красиво, но реальность такова что людям приходится писать вот такие вот библиотечки что бы не сойти с ума разбирая джейсоны где буквально все optional и никто ничего не обещает.
https://github.com/samber/lo - да да, это лодаш для го
В чем проблема завезти ну хотя бы obj?.optionlField?.optionalfield
Ну если у вас в проде такой код то оно конечно да. А когда кода на 10К строчек, разные слои и флоу... и ошибка прилетает откуда-то очень изнутри, из какой нибудь библиотечки, в то удачи вам в 3 часа ночи на блокере разобраться что случилось. А если ошибка еще и с динамическим текстом то все еще веселее.
Ну серьезно, сколько лет прошло, а люди все равно сопротивляются удобствам. Нет ничего удобнее и быстрее чем посмотреть на стэк и понять где проблема началось и откуда конкретно прилетела ошибка.
Пусть стек в ошибки завезут. А то иди пойми кто это ошибку кинул, если видишь только текст ошибки.
А может кто посоветовать базз ворды или почитать как тех. лиду вести троэкинг/менеджемент проектов, тасков и т.д?
Или использовать те же тулзы и приемы что используют тим лиды?
Удобней чем? Хорошему IDE пофиг как это выглядит. Все что нужно мне как девелоперу, это возможность кликнуть и перейти в файл + автокомплит IDE который заимпортит файл и поставит правильный путь сам.
Заниматься настройкой всего это чуда и потенциальные проблемы с этим в будущем не стоят потраченного времени.
И я понимаю почему синьоры этим не занимались. Потому что есть более серьезные проблемы четь удобство путей к файликам. А еще синьеры понимают что если что-то поломается, они будут это чинить...
P.S.
Если когда нибудь это будет из коробки, это другой разговор.
Никогда не понимал чем людям мешают ../../../
Они же там вверху, никому не мешают. Да и сразу видно откуда ноги растут, не нужно смотреть еще куда то...
Столько телодвижений что бы это все запустить. А если поломается, кто чинить будет =))
Никак не могу понять что это значит. Например если я удалил поле которые не использовалось консюмером. Что мне обновлять там? Или же имеется ввиду ристарт что бы новая сема подтянулась?
Более того. Нужно еще правильно определить проблему с условным Редисом. А то так можно бесконечно ритраиться...
Мы например пришли к тому что мы будем падать на любых ошибках подключения к внешним сервисам (базам например). Но, мы сделали нормальный 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 женерики я не испытываю удовольствия?
Так все таки сами практики бессмысленные или все таки неправильное использование практик является проблемой?
Боялся читать... я ведь тех. лид. Но страхи не оправдались.
У нас у каждой команды есть свой тим лид и продакт менеджер. Их обязанности строго обозначены.
Все что касается менеджмента, приоритетов, спринтов ко мне не относится.
Но, мне дали самому построить роль и решать чем я буду заниматься. Я вырос в команде, поэтому отношения с девелоперами норм. Отношения с тим лидами и продуктами приходится немного выстраивать по новому, потому что от меня могут прилететь технические таски.
Но, до меня в компании были попытки "создания" тех лидов. Как и тог, люди просто ушли. Потому что это был тех лид на бумажке, а по факту никто не знал что с ним делать. Либо они так же оставались работать в спринтах, что убивало напрочь возможность тех лидить, либо убирали со спринтов но никто не понимал что дальше с тех лидом делать.