Решил я ворваться тоже в “Сезон Open Source”, но как обычно в стиле «?» а не вот эти вот ваши молнии.

gRPC - ох уж эти 4 буквы

Я думаю, что все, кто работает с Go, так или иначе работали с gRPC, просто по причине того, что инструмент слишком популярный (не без причины, конечно). Однако есть у него и ряд проблем, фактически они исходят из-за плохого toolset, но это нюансы:

• Отсутствие встроенного пакетного менеджера

• Разнообразие стилей

• Легкая возможность поломать обратную совместимость

• Неудобство в генерации (ох уж эти 10-строчные bash команды)

Так исторически сложилось, что хорошего тулсета у Proto никогда не было, однако это было ровно до момента возникновения Buf tool, который реально сильно упростил жизнь работы с proto файлами.

Затем в году таки давнем родился, и на самом деле это действительно была мана небесная.

Фактически Buf представляет собой:

• Удобный пакетный менеджер

• Удобный линтер

• Удобный генератор

• Удобный брейкинг-чекер

Но подробнее о них, как и о решениях, вы сможете прочитать в статье моего прошлого выступления на эту тему. А сейчас я хочу рассказать, как так началось то, что мы стали разрабатывать свой аналог исходя из проблем невозможности работы с buf

EasyP

После блокировки Buf первое время мы активно пользовались им через VPN, однако это явно не могло работать долго, а также не являлось решением, когда надо было внедряться в CI/CD.

В какой-то момент мы с Даниилом Подольским обсудили интересную идею: что если попробовать реализовать свой пакетный менеджер? Точнее, не так — сделать свой пакетный сервер, который имеет обратно-совместимый протокол с Buf CLI.

Почему так? Да потому что это был единственный способ обеспечить быструю миграцию и работу в рамках компании Yadro, чтобы переезд был бы "бесшовным" и можно было бы оставаться в рамках Buf CLI всё так же. Разработка своего CLI изначально сразу блокировалась из-за необходимости в оперативном переезде, в итоге было решено остаться на минимально функционирующем варианте.

В итоге, занявшись реверс-инженерингом протокола, я обнаружил забавную ситуацию: когда вы указываете в конфиге URL до самого пакета, он его оттуда не подгружает, а на самом деле идёт туда и узнаёт, где в реальности лежит пакет (даже если он лежит на том же самом домене). Дальше идёт, собирает метаинформацию, и лишь уже последним запросом подгружает сами пакеты.

Мы сгенерировали весь сервер, подсунули в конфигурацию адрес до нашего локалхост 8080 и стали через их CLI стучаться к себе на сервер.  Мы просто логировали каждое сообщение: что происходило и в какой момент. Как только мы где-то ломались, мы попросту начинали редактировать в этом месте код. В основном хардкодили какие-то значения. - Protub и buf: блеск, нищета и импортозамещение

Интересная встреча

Так вышло, что в одном из Go чатов ребята из PT искали решение той же самой проблемы, в итоге наткнулись как раз на доклад мой и взяли тестить сервер иииииии….. он паниковал при старте (так вышло, что одним из последних фиксов я допустил очень глупую багу) и мне написали об этом, в итоге случайно выяснилось, что товарищ который мне написал буквально мой сосед, мы в итоге пообщавшись и решили, а почему бы не встретиться и подумать, может сможем развить эту историю дальше? Так уже в команде стало три человека, так как к нам присоединился Василий Близнецов :)

А в итоге так и рождается наш инструмент, EasyP , мы с Василием (Близценовым) решили вдвоем сесть и начать разрабатывать полноценно конкурента. Но суть в том, что мы не хотели делать просто аналог, мы хотели сделать лучше, и взяли теперь уже проблемы не самого proto, а именно buf, и среди основных конечно же блокировка не умеет работать с приватными git хостингами в закрытом контуре, ну что же, вызов был принят и мы пошли пилить ?.

Go Mod

Суть в том, что buf работает со своим централизованным пакетным сервером, однако есть же go get , который фактически воспринимает любой git репозиторий, как пакетный сервер и может с него подтягивать.

Почему бы и нам не пойти таким путем?

Сказано - сделано, берем пакет: https://github.com/go-git/go-git

Наверное, самое популярное sdk для работы с git'ом в golang.

Пишем PoC:

1. спулить гит репу

2. прочитать proto файлы

3. переложить их "куда-то"

Все работает!

Но! Что будет, если будем использовать приватные репозитории? А ведь большинство компаний используют именно приватные репоизтории, даже если используют on-premise гит хостинги.

А как эти дела у go mod? Он же прекрасно тащит зависимости с приватных репоизториев. Да, есть нюансы с настройкой доступа. Обычно для доступов к приватным репозиториям используют или ssh конфиг или .netrc. В случае ssh выпускаем ключ, паблик часть прописываем в VCS системе, приватную часть оставляем у себя и указываем к конфиге ~/.ssh/config. С .netrc плюс/минус похожая история, выпускаем токен, прописываем локально.

Но как все эти конфиги «переварить»? Как это реализовано в go mod? Как он получает все ключи, токены для доступов?

А никак! :-) он просто использует git клиент системы, да‑да‑да буквально вызывает «os.Exec»

Так и чего? Какой вывод? Да все просто — мы читайте нас, подписываетесь на нас и поддерживайте нас, вступайте к нам в чатик, а мы сделаем лучше, чем любые альтернативы, и самое важное — действительно OpenSource :‑)

А также подписывайтесь на мой канал, там сейчас начнется розыгрыш билетов на GolangConf.