Это была моя статья, хоть и под другим аккаунтом (секретность в компании была высокая).
После этой компании я побывал еще в двух - в одной пришлось работать руками, чтобы завоевать авторитет и подтянуть ребят. Как итог, получилось внутри компании заложить основу для формирования Платформы Go разработки и сколотить комьюнити человек так на 90.
Сейчас получилось так, что работаю в команде, где стек совершенно другой, нежели у меня, поэтому в код уже не лезу и моя основная задача зарядить ребят на работу. Занимаюсь мотивацией и стратегическим планированием, чтобы все понимали, куда мы движемся.
Какая-то ерунда. Подходит только для бизнеслогики, где всегда есть одно и только одно действие. А если у меня два действия и второе я не могу сделать, если зафейлилось первое? А еще для лога нужно будет всю метаинформацию пробрасывать в самый низ...
>Хотя gRPC-Gateway относительно эффективен, введение дополнительного прокси-слоя может немного увеличить задержку обработки запросов
Не немножко, а достаточно существенно, ибо проц начинает жрать перегонка json туда-сюда.
Как решение, можно делать не через проксирование http трафика на gRPC порт, а регистрировать в mux методы, которые так же генерируются автоматически, но тогда появляется проблема сбора метрик, ибо сгенерированный код не дает возможность получить uri template. Мы решили эту проблему только через патчинг сгенерированного кода, ибо все другие решения содержали слишком много минусов.
Не слишком ли рисковано строить архитектуру приложения на основе внутренних механизмов репликации БД? Не говоря уже о том, что данный подход выглядит несколько странно/непривычно с архитектурной точки зрения.
Забыли упомянуть, что пакетам приходится принимать на вход конкретные типы или описывать интерфейсы глобально. Не получится внутри пакета А декларировать интерфейс, который он получает на вход, так, чтобы пакет В не знал об этом интерфейсе. Это идет вразрез с идеологией Go.
И да, отладка действительно превращается в кошмар. При запуске программы невозможно понять в каком месте что упало.
Еще один аргумент в пользу protobuf - его знает большинство разработчиков и не будет тратиться время на обучение вновь пришедших в команду.
Жду вторую часть с конкретными цифрами, ибо при выборе решения важно опираться на такие показатели, как размер сообщения, нагрузка на проц при кодировке/раскодировке и потребление памяти при этом.
Да, переходить советую — банально пальцы меньше скачут по клаве, да и появится шанс научиться печатать вслепую, если до сих пор было лень это сделать.
В русской раскладке пишу не вслепую :)
Сам уже 10 лет на DVORAK. Я разработчик — работаю только за своим компьютером, поэтому qwerty встречаю довольно редко. Шорткаты да — было больно, ничего не переназначал, просто привык к новому расположению. В JetBrains продуктах у меня стоит режим vim, поэтому работаю чаще через него. Переход на DVORAK у меня занял пару недель — я просто поменял себе раскладку, на второй монитор вывел картинку с раскладкой и продолжил работать.
Сейчас прохожу в яндекс на Go сеньора. Было 2 интервью с задачками, сейчас жду фидбэка по второму — уже 3 дня жду. Надеюсь, следующим этапом будет что-то отличное от алгоритмических задачек с литкода. Кстати, задачку про «функцию RLE» я тоже решал. :)
А вот это уже и решает команда. С одной стороны, без пробелов строка выглядит компактнее. С другой стороны, пробелы помогают отделить знак, что может помочь найти ошибку, если она есть. Язык тут тоже имеет значение. Я предпочитаю ставить пробелы. Но этот подход должен быть однообразным во всем коде, чтобы было легче быстро читать исходники.
И да, и нет :)
Это была моя статья, хоть и под другим аккаунтом (секретность в компании была высокая).
После этой компании я побывал еще в двух - в одной пришлось работать руками, чтобы завоевать авторитет и подтянуть ребят. Как итог, получилось внутри компании заложить основу для формирования Платформы Go разработки и сколотить комьюнити человек так на 90.
Сейчас получилось так, что работаю в команде, где стек совершенно другой, нежели у меня, поэтому в код уже не лезу и моя основная задача зарядить ребят на работу. Занимаюсь мотивацией и стратегическим планированием, чтобы все понимали, куда мы движемся.
Интересный подход к объяснению. Жду статьи, где будет так же рассказано про поведение гостей и хозяев в move/async мире :)
Какая-то ерунда. Подходит только для бизнеслогики, где всегда есть одно и только одно действие. А если у меня два действия и второе я не могу сделать, если зафейлилось первое? А еще для лога нужно будет всю метаинформацию пробрасывать в самый низ...
>Хотя gRPC-Gateway относительно эффективен, введение дополнительного прокси-слоя может немного увеличить задержку обработки запросов
Не немножко, а достаточно существенно, ибо проц начинает жрать перегонка json туда-сюда.
Как решение, можно делать не через проксирование http трафика на gRPC порт, а регистрировать в mux методы, которые так же генерируются автоматически, но тогда появляется проблема сбора метрик, ибо сгенерированный код не дает возможность получить uri template. Мы решили эту проблему только через патчинг сгенерированного кода, ибо все другие решения содержали слишком много минусов.
На сколько я вижу, кафка у вас является такой жииирной точкой отказа - что делать, если она свалится?
>То что Watch основан на внутреннем механизме репликации БД вообще восхитительно
А на сколько внутренний механизм гарантирует обратную совместимость? Не будет ли проблем при обновлении версий монги?
Не слишком ли рисковано строить архитектуру приложения на основе внутренних механизмов репликации БД? Не говоря уже о том, что данный подход выглядит несколько странно/непривычно с архитектурной точки зрения.
А какой процент команд используют ваш инструмент?
Перечисленые вещи легко инкапсулируются в пакетах и не лезут в main. И это не большое количество.
С другой стороны, если у тебя там штук 20 клиентов, коннекты к нескольким БД, то возможно, твой сервис стоит разделить на несколько микросервисов.
Конечно, всегда существуют исключения, но в большинстве своём у микросервиса небольшой main.
Возможно, стоит использовать Go для написания микросервисов, а не монолитов. ? Для монолитов жоэс всяких куча, там вам и DI сколько угодно.
Забыли упомянуть, что пакетам приходится принимать на вход конкретные типы или описывать интерфейсы глобально. Не получится внутри пакета А декларировать интерфейс, который он получает на вход, так, чтобы пакет В не знал об этом интерфейсе. Это идет вразрез с идеологией Go.
И да, отладка действительно превращается в кошмар. При запуске программы невозможно понять в каком месте что упало.
Еще один аргумент в пользу protobuf - его знает большинство разработчиков и не будет тратиться время на обучение вновь пришедших в команду.
Жду вторую часть с конкретными цифрами, ибо при выборе решения важно опираться на такие показатели, как размер сообщения, нагрузка на проц при кодировке/раскодировке и потребление памяти при этом.
В русской раскладке пишу не вслепую :)