index0h

https://confluence.atlassian.com/bitbucket/manage-...

Используйте указатели в мапе

Потому, что сложно читать и дебажить так как ваш код выполняется в хрен знает какой последовательности. Ваш метод на 6 строк, как пример - так себе. Если метод на 300-400, и этих goto штук 15? Не запуская код с таймером, выпишите на бумажку что будет выведено на экран в таком примере (там всего 50 строк).
Код с goto пишется один раз, а дальше выбрасывается.

З.Ы. Конкретно ваш пример стоит делать в цикле и рекурсия вам тут тоже не нужна.

func () (id string) {
	for id = generateString(32); unique(id); id = generateString(32) {
	}

	return id
}

phantomJS

Со всей силы не стоит. Базовая инициализация приложения не должна (по хорошему) иметь ничего общего с вашей бизнес логикой (БЛ). В вашем случае это грубое нарушение SOLID (SRP).
Пример из серии "что-то пошло не так": ваш подготовленный запрос в процессе выполнения изменился, код его использующий будет ожидать старого поведения, но отвалится (это в лучшем случае) только после выполнения запроса, а там может быть что угодно. Как результат: поведение методов, использующих эти запросы меняется, без изменения их кода. Подобные ошибки ищутся долго.

-- upd --

Глобальные публичный переменные, как правило, это плохая идея)) Что вы будете делать, если у вас появится еще одно подключение к БД? Переписывать весь код?

У вас функция Save делает select, зачем? Это ж явное противоречие названию

Что касается подключения к БД - рекомендую вынести это в файл настроек, либо флаг запуска.

По простому: hash = someFunc(secret + message) добавляется в запрос/ответ. При этом секретный ключ должен присутствовать и на сервере и на клиенте.

Есть альтренативный вариант: https://ru.wikipedia.org/wiki/Сервер_криптографиче...

Как вариант можно посмотреть в сторону OAuth2, так же не обделите вниманием LDAP

Golang по умолчанию компилируется в 1 бинарь. Да, можно подключать shared либы, да можно собирать, но язык заточен не под это.
Что бы подключать функционал - гуглите на тему "golang unsafe", "golang load dynamic library". Но вообще говоря - это со всей силы не golang-way.

каждый модуль использовать как микросервис

вполне вариант

представить не могу как расширить функцию парсинга команд

Вам нужен некий резолвер, который будет заполняться мета данными о ваших командах в процессе старта приложения. Далее на основании собранных данных нужно будет настраивать парсер команд.

Если же вы хотите нечто эдакое сделать с помощью отдельных микросервисов - потребуется как минимум еще один, который будет распределять действия между остальными. Например через сервер очередей, либо rpc. В любом случае протокол общения между сервисами вам придется спроектировать. А если запуск через консоль - это еще один клиент. Грубо говоря эта штука может выглядеть так:

[client] <-??-> [client-app] <-rpc|queue|...-> [main-server] <-rpc|queue|...=>[modules]

jshint
jscs
uglify-js
https://codeclimate.com/
тесты-тесты-тесты

З.Ы. Будьте готовы к тому, что в случае работы в команде - 99.99% ваш gjs придется выкинуть. Очень рекомендую по тыкать на досуге live templates в WebStorm

Магические текстовки нужно заменить на константы.

В итоге я могу хоть 800к логов загнать в бд без большой нагрузки на неё.

Круть. За какой период времени? Какое железо? Нагрузка и на редис и на БД постоянная?

Чем ваш логгер лучше https://github.com/Sirupsen/logrus ?

-- --

Посмотрел статью на хабре, увы там комментировать возможности не имею.

Кровь из глаз((

0. Посмотрите logrus и переименуйте статью на "еще один логгер". Ваш логгер не гибкий, примите за исходную.

1.

Данные в редисе

вы правда думаете кто-то будет это читать?))

2.

Я долго бился голов об клавиатуру искал багу в коде...

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

3.

1 000 000 записей в мускуль добавилось за 25мл.сек

Что-то слабо верится(( Сколько выполняется запись просто из файла, такого же объема данных. Интересует сравнение времени.

4.

правда в редис эти данные писались около 6 минут

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

5.

конфиг

Кровь из глаз, конфиги если уже json делаете - хотя бы делайте человеко понятными, не используйте массивы там, где должны быть объекты!!!

6.

библиотека

То, что вы делаете в init - это как минимум богомерзко((( Ваш логгер абсолютно не управляем. Его настройка приколочена 100-тыми говздями и заварена арматурой, как у вас вообще возникла мысль говорить о гибкости?))

7.

//Путь к файлу с конфигами
config_file string = "/home/v-smerti/localhost/api/src/microService/config/log.json"

8.

демон

Вы хоть сами смотрели?))

9. Вы нигде не обрабатываете ошибку отправки почты, это вообще как? Если связь с сервером нарушено - логов не будет?))

10. SQL:
`id` int(11) NOT NULL AUTO_INCREMENT,
Я надеюсь вы осмысленно допускаете отрицательные id.

11. SQL:
`type` text NOT NULL,
эт пи*дец.

12. SQL:
KEY `type` (`type`(191))
Если не секрет - почему не 192?

Недавно решал такую же проблему:
Первый раз пробовал просто хардкодом, примерно так:
+ не жалко переписать полностью
- слабо конфигурабельно

Вторая попытка - упор на конфигурабельность но так же средствами чистого go:
+ можно настроить практически все
- тяжело поддерживать.

Третья попытка:
Переписал на базе самописного сервис-локатора примерно так:
+ мало кода, все настройки в yaml
- процесс инициализации не контролируем

Четвертая попытка:
Создана структура под конфигурацию, наполняется данными через viper + запускается через cobra примерно так:
+ в настройки выносится только необходимое, а не вообще все, как в случае с сервис локатором
+ процесс инициализации полностью контролируемый

В общем могу по рекомендовать следующее:
1. создайте структуру для всей вашей конфигурации приложения;
2. записывайте туда пользовательские настройки при начале инициализации;
3. для всех опциональных настроек обязательно должны быть значения по умолчанию;
4. не гонитесь за максимальной гибкостью, это приведет вас в тупик;
5. непосредственно создание компонентов выполняйте на базе сформированного объекта конфигурации, не стоит вытягивать отдельно каждую настройку через viper или его аналоги.

Задача шаблонизатора - собрать строку из шаблона(ов), которые строки по сути + внедрить в них пользовательские данные. Шаблонизатору все равно теги у вас в этих строках, или не теги, все что его интересует - синтаксические конструкции самого шаблонизатора, для подстановки данных.

Веду к следующему - если вам не нужно показывать часть шаблона - пропишите условие.

Не буферизированнй канал заблокирует гортину до момента, пока с него ничего не прочитают.
Буферизированный канал заблокирует горутину только в том случа, если все буфер забит И происходит попытка еще одной записи. Как только будет выполнено чтение из канала - горутина разблокируется.

В случае, если горутина всего одна (только функция main) и канал ее заблокирует - программа выпадет с ошибкой так как все горутины блокированны - выполнять нечего.

Открывайте сначала терминал, уже в нем свою программу. А не запускайте ее в консольном режиме.

Читаем про RBAC

- Хочу выстралить себе в ногу, эти подойдут?
- Берите разрывные, так надежнее))

---------

Глобальные переменные - это зло, вы ни в коем случае НЕ ДОЛЖНЫ ЭТОГО ХОТЕТЬ!

Хэши типа ваших имеют смысл только в очень критичных по производительности на чтение местах. Если это так - ваш код вполне оптимален. Да, выглядит стремно, но скорость будет высокая, при условии, что вы выбираете по конкретным ключам, а не перебором.
В противном случае - лучше таки на структурах (если хотите сэкономить чутка на памяти - указателях на структуры).
Пример, что привел SilentFl - вполне ок.

Не забывайте, что слайсы / мапы - опасны потому, что передаются по ссылке и в случае конкурентного доступа - у вас будет каша из данных. Посему данные храним в приватных переменных и наружу торчата геттеры/сеттеры с sync.RWMutex