История изменений
Исправление derlafff, (текущая версия) :
Есть ли у кого-либо опыть использования Golang в столь сложных проектах?
Бекенд, 25К строк кода, 25 таблиц (число мало, поскольку мы на микросервисах и данные разбросаны). Сойдет?
Может ли кто-нибудь подсказать примеры столь сложных проектов с открытым исходным кодом?
Не видел
Есть ли у кого-нибудь веские аргументы не делать этот переход на Golang?
Есть проблемы, но в целом с ними жить можно и они устраивают. Питон по моему мнению хуже.
Может ли кто-то рассказать, как решить те проблемы, которые были мной выше описаны в Golang?
Ну, самая главная ошибка, которая возникала — хотелось больше «сокрытия реализации», поэтому сначала пытались разбивать все на кучу пакетов. Но, как известно, в go нельзя циклически импортировать пакеты и идея провалилась. Если посмотреть на даже больше опенсорц-пакеты — там тоже практически все находится буквально в нескольких пакетах. Это не неудобно, просто другой способ организации.
Структура проекта выглядит как-то так: http://storage5.static.itmages.ru/i/16/0921/h_1474438233_4783744_64393b43f3.png
Во-вторых, ORM. Используем gorm (https://github.com/jinzhu/gorm), и у него есть добрая куча проблем. В целом жить можно, но если упор на производительность, то я бы взял https://github.com/go-pg/pg (вроде, оно, точно не помню) и реализовать плюшки gorm поверх. Но с проблемами go-pg/pg я не знаком, поэтому точно сказать не могу.
Достаточно продвинутое ООП для реализации сложной логики
Продвинутое ООП != сложая логика. Придется использовать несколько другие паттерны, я полагаю. Сам не любитель терминального ООП головного мозга, поэтому с этим проблем не было.
Еще про микросервисы: из-за них по-полной сейчас огребаем с транзакциями (и из-за gorm тоже), но в целом жить можно. Деплой удобен, сервисы маленькие, поддерживаемые и независимые, правда, ядро у нас толстовато. В качестве шины используем grpc и nats, первый — зрел и прекрасен.
На качество гитхаболиб я бы не полагался — в целом они ужасно, ужасно жирные (за немногими хорошими исключениями), и чаше лучше реализовать что-то самостоятельно.
Возможность рефлексии в языке совращает, но лучше сразу копипастить/использовать кодогенерацию, поскольку это место придется переписывать. Но в целом с использованием interface{} проблем нет, я про более продвинутые случаи. Относится и к дефолтным json и protobuf-энкодерам — нужно заменять на версии с кодогенерацией для адекватной производительности (например, https://github.com/pquerna/ffjson).
Задавайте свои вопросы.
Исправление derlafff, :
Есть ли у кого-либо опыть использования Golang в столь сложных проектах?
Бекенд, 25К строк кода, 25 таблиц (число мало, поскольку мы на микросервисах и данные разбросаны). Сойдет?
Может ли кто-нибудь подсказать примеры столь сложных проектов с открытым исходным кодом?
Не видел
Есть ли у кого-нибудь веские аргументы не делать этот переход на Golang?
Есть проблемы, но в целом с ними жить можно и они устраивают. Питон по моему мнению хуже.
Может ли кто-то рассказать, как решить те проблемы, которые были мной выше описаны в Golang?
Ну, самая главная ошибка, которая возникала — хотелось больше «сокрытия реализации», поэтому сначала пытались разбивать все на кучу пакетов. Но, как известно, в go нельзя циклически импортировать пакеты и идея провалилась. Если посмотреть на даже больше опенсорц-пакеты — там тоже практически все находится буквально в нескольких пакетах. Это не неудобно, просто другой способ организации.
Структура проекта выглядит как-то так: http://storage5.static.itmages.ru/i/16/0921/h_1474438233_4783744_64393b43f3.png
Во-вторых, ORM. Используем gorm (https://github.com/jinzhu/gorm), и у него есть добрая куча проблем. В целом жить можно, но если упор на производительность, то я бы взял https://github.com/go-pg/pg (вроде, оно, точно не помню) и реализовать плюшки gorm поверх. Но с проблемами go-pg/pg я не знаком, поэтому точно сказать не могу.
Достаточно продвинутое ООП для реализации сложной логики
Продвинутое ООП != сложая логика. Придется использовать несколько другие паттерны, я полагаю. Сам не любитель терминального ООП головного мозга, поэтому с этим проблем не было.
Еще про микросервисы: из-за них по-полной сейчас огребаем с транзакциями (и из-за gorm тоже0, но в целом жить можно. Деплой удобен, сервисы маленькие, поддерживаемые и независимые, правда, ядро у нас толстовато. В качестве шины используем grpc и nats, первый — зрел и прекрасен.
На качество гитхаболиб я бы не полагался — в целом они ужасно, ужасно жирные (за немногими хорошими исключениями), и чаше лучше реализовать что-то самостоятельно.
Возможность рефлексии в языке совращает, но лучше сразу копипастить/использовать кодогенерацию, поскольку это место придется переписывать. Но в целом с использованием interface{} проблем нет, я про более продвинутые случаи. Относится и к дефолтным json и protobuf-энкодерам — нужно заменять на версии с кодогенерацией для адекватной производительности (например, https://github.com/pquerna/ffjson).
Задавайте свои вопросы.
Исходная версия derlafff, :
Есть ли у кого-либо опыть использования Golang в столь сложных проектах?
Бекенд, 25К строк кода, 25 таблиц (число мало, поскольку мы на микросервисах и данные разбросаны). Сойдет?
Может ли кто-нибудь подсказать примеры столь сложных проектов с открытым исходным кодом?
Не видел
Есть ли у кого-нибудь веские аргументы не делать этот переход на Golang?
Есть проблемы, но в целом с ними жить можно и они устраивают. Питон по моему мнению хуже.
Может ли кто-то рассказать, как решить те проблемы, которые были мной выше описаны в Golang?
Ну, самая главная ошибка, которая возникала — хотелось больше «сокрытия реализации», поэтому сначала пытались разбивать все на кучу пакетов. Но, как известно, в go нельзя циклически импортировать пакеты и идея провалилась. Если посмотреть на даже больше опенсорц-пакеты — там тоже практически все находится буквально в нескольких пакетах. Это не неудобно, просто другой способ организации.
Структура проекта выглядит как-то так: http://storage5.static.itmages.ru/i/16/0921/h_1474438233_4783744_64393b43f3.png
Во-вторых, ORM. Используем gorm (https://github.com/jinzhu/gorm), и у него есть добрая куча проблем. В целом жить можно, но если упор на производительность, то я бы взял https://github.com/go-pg/pg (вроде, оно, точно не помню) и реализовать плюшки gorm поверх. Но с проблемами go-pg/pg я не знаком, поэтому точно сказать не могу.
Достаточно продвинутое ООП для реализации сложной логики
Продвинутое ООП != сложая логика. Придется использовать несколько другие паттерны, я полагаю. Сам не любитель терминального ООП головного мозга, поэтому с этим проблем не было.
Еще про микросервисы: из-за них по-полной сейчас огребаем с транзакциями (и из-за gorm тоже0, но в целом жить можно. Деплой удобен, сервисы маленькие, поддерживаемые и независимые, правда, ядро у нас толстовато. В качестве шины используем grpc и nats, первый — зрел и прекрасен.
На качество гитхаболиб я бы не полагался — в целом они ужасно, ужасно жирные (за немногими хорошими исключениями), и чаше лучше реализовать что-то самостоятельно.
Возможность рефлексии в языке совращает, но лучше сразу копипастить/использовать кодогенерацию, поскольку это место придется переписывать. Но в целом с использованием interface{} проблем нет, я про более продвинутые случаи. Относится и к дефолтным json и protobuf-энкодерам — нужно заменять на версии с кодогенерацией для адекватной производительности (например, https://github.com/pquerna/ffjson).