Думаю, что мне повезло оказаться в сильных командах - сперва в РСЯ Яндекса, затем в высоконагруженном Lazada.com. Это может быть рабочим подходом - выбирать команду не по зарплате, а по знаниям руководителя, и у него учиться. Но есть и более управляемый способ - системно учиться по Teamlead roadmap: https://tlroadmap.io/.
Это один из путей развития Playground - удобство подключения к нему популярных IDE.
Нужно понимать, что Idea DevContainers и Playground - это смежные инструменты, а не взаимозаменяемые: * Цель Idea DevContainers - дать возможность спрятать инструменты для написания кода, билда, запуска хранилищ и т.п. в докер контейнеры. * Цель Playground - дать возможность любому разработчику любого сервиса в СберМаркет возможность запустить его без утомительной настройки, независимо от IDE, которую он использует. Playground не только запускает код, но и нужные ему базы данных, урлы для тестирования через web browser с хоста. В том числе, позволяет запускать в ci/cd, где IDE не существует. В Playground предусмотрен режим запуска в режиме "только хранилища" и это позволяет подключать к нему IDE на хосте или через DevContainers в той же docker сети.
Так что эти инструменты не противоречат друг другу и не заменяют друг друга, но у нас нет задачи заставить всех разработчиков в компании использовать один и тот же IDE. Наша задача - дать гибкость, достаточную для разных IDE в компании.
Верно, если запрос один и тот же, а ответ должен меняться, то параллельный запуск невозможен, так как такие запросы неразличимы в принципе. Но вы можете добавить в запрос скозной заголовок, по которому будете решать какой ответ отправить. Сквозной означает, что значение этого заголовка, полученное на вход API сервиса, будет пробрасываться в исходящие запросы к grpc-wiremock.
Привет! Да, как раз это и есть прямое назначение grpc-wiremock. До реализации grpc-wiremock мы пробовали использовать gripmock. Gripmock нам показался довольно сырым с точки зрения конфигурации матчинга, документации и отсутствия других преимуществ, описанных в статье.
Да, в статье показано, как дорого обходится микросервисная архитектура. Много узлов отказа и обслуживания, ненадежное сетевое взаимодействие вместо надежного вызова метода в монолите... Так что один из полезных выводов, который следует вынести из статьи - если у вас нет веских причин переходить на микросервисы - не делайте этого.
С другой стороны, если у вас больше 50ти команд, которые разрабатывают монолит, то как бы вы организовали совместную работу с кодовой базой?
Huginn - это название нашего внутреннего портала разработчика.
Зависимости мы отображаем в нем в разных представлениях: 1) Карта сервисов. Можно приблизить и посмотреть названия, можно в строке поиска найти свой сервис. Фактические связи - строятся на основании статистики реального взаимодействия, собранной с istio. Задекларированные связи - берутся из конфигов сервисов.
Карта сервисов
2) На карточке сервиса указаны его зависимости - другие сервисы и базы данных.
Зависимости в карточке сервиса
3) Карта связей топиков и сервисов
Карта связей топиков и сервисов
В рамках этого цикла статей планируем выпустить отдельную про Huginn.
Думаю, что мне повезло оказаться в сильных командах - сперва в РСЯ Яндекса, затем в высоконагруженном Lazada.com. Это может быть рабочим подходом - выбирать команду не по зарплате, а по знаниям руководителя, и у него учиться.
Но есть и более управляемый способ - системно учиться по Teamlead roadmap: https://tlroadmap.io/.
Это один из путей развития Playground - удобство подключения к нему популярных IDE.
Нужно понимать, что Idea DevContainers и Playground - это смежные инструменты, а не взаимозаменяемые:
* Цель Idea DevContainers - дать возможность спрятать инструменты для написания кода, билда, запуска хранилищ и т.п. в докер контейнеры.
* Цель Playground - дать возможность любому разработчику любого сервиса в СберМаркет возможность запустить его без утомительной настройки, независимо от IDE, которую он использует. Playground не только запускает код, но и нужные ему базы данных, урлы для тестирования через web browser с хоста. В том числе, позволяет запускать в ci/cd, где IDE не существует.
В Playground предусмотрен режим запуска в режиме "только хранилища" и это позволяет подключать к нему IDE на хосте или через DevContainers в той же docker сети.
Так что эти инструменты не противоречат друг другу и не заменяют друг друга, но у нас нет задачи заставить всех разработчиков в компании использовать один и тот же IDE. Наша задача - дать гибкость, достаточную для разных IDE в компании.
Верно, если запрос один и тот же, а ответ должен меняться, то параллельный запуск невозможен, так как такие запросы неразличимы в принципе.
Но вы можете добавить в запрос скозной заголовок, по которому будете решать какой ответ отправить. Сквозной означает, что значение этого заголовка, полученное на вход API сервиса, будет пробрасываться в исходящие запросы к grpc-wiremock.
Привет! Да, как раз это и есть прямое назначение grpc-wiremock.
До реализации grpc-wiremock мы пробовали использовать gripmock. Gripmock нам показался довольно сырым с точки зрения конфигурации матчинга, документации и отсутствия других преимуществ, описанных в статье.
Спасибо, уточнил формулировку - JavaScript
Здравствуйте!
Да, в статье показано, как дорого обходится микросервисная архитектура. Много узлов отказа и обслуживания, ненадежное сетевое взаимодействие вместо надежного вызова метода в монолите... Так что один из полезных выводов, который следует вынести из статьи - если у вас нет веских причин переходить на микросервисы - не делайте этого.
С другой стороны, если у вас больше 50ти команд, которые разрабатывают монолит, то как бы вы организовали совместную работу с кодовой базой?
Приветствую!
Huginn - это название нашего внутреннего портала разработчика.
Зависимости мы отображаем в нем в разных представлениях:
1) Карта сервисов. Можно приблизить и посмотреть названия, можно в строке поиска найти свой сервис. Фактические связи - строятся на основании статистики реального взаимодействия, собранной с istio. Задекларированные связи - берутся из конфигов сервисов.
2) На карточке сервиса указаны его зависимости - другие сервисы и базы данных.
3) Карта связей топиков и сервисов
В рамках этого цикла статей планируем выпустить отдельную про Huginn.