Виктор Кожухарь

Как гофер с 1.13 версии могу предложить следующие рассуждения:

1) Нормальная общепризнанная и безболезненная ORM отсутствует. Самая популярная - GORM, где-то на втором месте - ent. Обе в целом как-то соответствуют ожиданиям, но имеют свои особенности. Кто в GORMе делал джоин - в цирке не смеется.
2) Из за того что в большинстве нормальных проектов ORMы не используются очень быстро привыкаешь писать именно SQL. Ты ещё на стадии аналитики рисуешь все эти create table и select from в голове, потом просто вставляешь в код.
3) Производительность GORM сделала в мире го репутацию всем ORMкам как очень плохому решению.

Лично я делю всех гоферов на 4 типа: бывшие джависты, бывшие пхпшники, бывшие питонисты и непосредственно гоферы - те у кого го первый или основной язык. В большинстве наблюдаемых случаев ORM в го пытаются затащить бывшие джависты по старой привычке: вот у нас в спринге был ORM значит и здесь возьмём. Клинический случай - когда такой бывший джавист становится тим или тех-лидом и делает ORM обязательным. Сколько видел таких случаев - каждый раз в результате команда ходит плюётся.

Ну и да, есть ORMки основанные на генерации кода, но самая популярная - GORM основана на рефлексии и иногда магии, это очень сильно бьет по производительности и иногда может стать "бутылочным горлышком" приложения.

Git + docker

Решил сделать переход с MD5 на SHA256

Первая ошибка.
Переходить нужно сразу на password_hash
На переходный период реализовать две системы аутентификации. Сначала пробуете по старой (md5), если неудача, то password_verify
После удачной аутентификации хешируете пароль новым алгоритмом.

Проблема решается постепенным переводом пользователей на новое хранение пароля по мере их входа в систему.
В момент аутентификации пользователя нам известен его пароль, поэтому если новый хэш для пользователя не определён, то аутентифицируем его по старому методу, генерируем и сохраняем новый хэш, удаляем старый хэш.
И, конечно же, надо забыть о самодельных системах хэширования и использовать стандартные password_hash и password_verify.

md5 или подобный хеш
из плюсов, он позволит не хранить копии, если кто-то зальет картинку еще раз

У меня в одном из проектов есть десяток живых интеграций с инфоклиникой :)

1. Они отлично отвечают на вопросы.

2. У вас странный url. У инфоклиники есть центральный шлюз https://api.infoclinica.ru/api/xml
Там все те же самые xml, но без soap.

3. XML запрос мы собираем руками и просто отправляем post в body.
TS.1 - это `date('YmdHis')`
MSH.10 - рекомендуется уникальный для каждого запроса

4. Там есть определенная пляска с подписью запроса сертификатом, на centos так и не заработало, пришлось виртуализироваться

Относительно простое решение такое:

• У вас есть какой-то сервер сокетов, который постоянно запущен и поддерживает соединения с клиентами.
  
• У вас есть какой-то сервер очередей.
  
• Сервер сокетов слушает сервер очередей и, при получении нужных данных, рассылает их клиентам.
  
• По крону срабатывает скрипт, который кладёт данные в очередь.
  

строка
promise.then(onFullfiled).catch(onRejected);
на самом деле работает как
promise.then(onFullfiled, err => {throw err;}).then(v => v, onRejected);

Если имеем дело с зарезолвленным/зареджекченным промисом, то здесь первый then ставит микротаск в очередь сразу, а второй - только по выполнении микротаска от первого.

соответственно, для примера

const promises = [
  Promise.reject('rejected1'),
  Promise.reject('rejected2'),
  Promise.resolve('resolved'),
];

микротаски составили такую очередь:

1) err => {throw err;}
2) err => {throw err;}
3) onFullfiled
4) onRejected,
5) onRejected
6) v => v,

Где пункты 1-3 добавились на цикле, а 4-6 по мере выполнения первых трёх.

вот так и вышло, что onFullfiled вылез вперед.

С какого количества записей индексация имеет смысл?

С того момента, когда планировщик начал показывать приличную разницу, как только получаете прирост - используйте индексацию, не получаете - не используйте.

Сделал выборку по определенному имени, вышло 75-90 мсек.
SELECT name FROM users WHERE name='Mike';
Добавил индекс CREATE INDEX name_idx ON users (name);
Выборка так и осталась в пределах 75-85 мсек.

Вы сами задали вопрос и сразу же ответили на него...

1) Подскажите какую лучше поставить операционную систему? Если Linux, то в сторону каких дистрибутивов смотреть. Хотелось бы удалённо подключаться к этому ПК для мониторинга или обновления файлов с github.

Proxmox или другой гипервизор

2) Актуален ли для подобного Docker или слишком много ресурсов будет отнимать?

Актуален.

3) Правильно ли запускать различные сайты просто на разных портах роутера?

Лучше использовать прокси (я бы использовал traefik или nginx).

5) Раз выполняется проброс порта, то как это обезопасить?

Как раз стоит изучить решения по защите (nginx Bunker, geoip, crowdsec)

https://go.dev/play/p/eDi3J3Zzcdg

package main

import "fmt"

type MyError struct {
	Message string
}

func (e MyError) Error() string {
	return e.Message
}

func (e MyError) Smth() {
}

type SomeInterface interface {
	Smth()
}

func main() {
	var err SomeInterface
	err = MyError{"Something went wrong"}

	// Проверяем, реализует ли err интерфейс error
	if _, ok := err.(error); ok {
		fmt.Println("err реализует интерфейс error")
	} else {
		fmt.Println("err НЕ реализует интерфейс error")
	}
}

У вас получилось, что тип переменной err это структура, но нужно чтобы тип был каким-нибудь интерфейсом.

В моем примере я создал интерфейс SomeInterface и добавил вашему типу метод, чтобы он этому интерфейсу удовлетворял. Теперь данный ассершн имеет смысл.

P.S. С пустым интерфейсом тоже работать будет https://go.dev/play/p/Yz0M1Wzopua