Мы как раз занимаемся интеграцией Istio. Но вот есть проблемка и спецы говорят что простого решения нету.
Проблема что у нас уже есть где-то 1000 сервисов. Часть из них разговаривают по http. Бывают даже цепочки вызовов.
Так вот есть какое-то ограничение что если я один сервис добавляю в мешь, что другой сервис который не в мешь не сможет до него достучаться.
Какой сервис должен быть занесен первым в мешь на данный момент узнать не возможно. Может быть topological sort все х сервисов может помочь но не уверен есть циклы).
Задеплоить все и сразу в мешь это надо делать downtime. Не можем.
Девопсы предлагают делать копии сервисов, заносить их в мешь и так по цепочке... и менять хотсны к копиям сервисов у тех сервисов которые к ним стучатся. Мне кажется это не реально и криво...
Приходилось ли кому интегрировать мешь в существующую систему? Не верю что нет подхода по-проще.
Самой большой проблемой загрузки файлов была всегда связка browser-server.
Я помню времена когда загрузчики писались на флешь, что бы можно было много файлов загружать, делать resume.
Конечно сегодня дела обстоят лучше. Но вот у меня стоит задача сделать загрузку до 3k файлов с браузера. Все еще не решил, идти в сторону обычного загрузчика с браузера, или все таки упороться в маутинг хранилища как диска в операционке. Но кажется задача не простая.
Понятно что проблема наша. Но в любом нормальном языке стэк экономит кучу дорогого времени.
В 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 на минималках, поэтому многим девелоперам сравнительно легко в него зайти.
З.Ы.
Ошибки депенденси действительно все еще вызывают дискомфорт, но после полного понимания как оно работает становится легче.
Мы как раз занимаемся интеграцией Istio. Но вот есть проблемка и спецы говорят что простого решения нету.
Проблема что у нас уже есть где-то 1000 сервисов. Часть из них разговаривают по http. Бывают даже цепочки вызовов.
Так вот есть какое-то ограничение что если я один сервис добавляю в мешь, что другой сервис который не в мешь не сможет до него достучаться.
Какой сервис должен быть занесен первым в мешь на данный момент узнать не возможно. Может быть topological sort все х сервисов может помочь но не уверен есть циклы).
Задеплоить все и сразу в мешь это надо делать downtime. Не можем.
Девопсы предлагают делать копии сервисов, заносить их в мешь и так по цепочке... и менять хотсны к копиям сервисов у тех сервисов которые к ним стучатся. Мне кажется это не реально и криво...
Приходилось ли кому интегрировать мешь в существующую систему? Не верю что нет подхода по-проще.
Смотю на наш легаси с node 8 и плачу =))
Самой большой проблемой загрузки файлов была всегда связка browser-server.
Я помню времена когда загрузчики писались на флешь, что бы можно было много файлов загружать, делать resume.
Конечно сегодня дела обстоят лучше. Но вот у меня стоит задача сделать загрузку до 3k файлов с браузера. Все еще не решил, идти в сторону обычного загрузчика с браузера, или все таки упороться в маутинг хранилища как диска в операционке. Но кажется задача не простая.
Жава вроде и так кросс платформенная... зачем?
Где работающему человеку взять время на все эти сертификации? 😥
Я когда то пилил проектына реакте + експресс.
Сегодня пилю на nest.js бэк, под фронт на реакте который пилится другими людьми.
Для чего конкретно придуман Next.JS?
Т.е. оборачивать логгером все вызовы функций? =))
Потому как имея
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 на минималках, поэтому многим девелоперам сравнительно легко в него зайти.
З.Ы.
Ошибки депенденси действительно все еще вызывают дискомфорт, но после полного понимания как оно работает становится легче.