index0h

Как определить свой уровень программирования?

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

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

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

	return id
}

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

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

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

Проверять данные в каждом методе - это вполне отличная практика, по сути это соблюдение интерфейса метода.
Но возвращать при этом null/false - практика хреновая, если ваш метод на вход требует int, а получил array - надо бросать исключение. Так вы будете знать, что внешний код, который использует ваш метод работает не корректно.

Для объектов настоятельно рекомендую использовать type hinting:

public function test(MyObject $object, $id)
{
    if (!is_int($id)) {
        throw new \InvalidArgumentException('Argument "id" must be int');
    } elseif ($id < 0) {
        throw new \InvalidArgumentException('Argument "id" must be positive');
    }
...

Если пишете на семерке, то и для скаляров и на вывод - тоже стоит указывать type hinting. Правда с выводом не всегда это можно делать, например возврата null, или что-то еще.

public function checkPositive(int $intData): bool

Для сокращения проверок можете мой пакет заюзать https://packagist.org/packages/ko-ko-ko/assert, он спроектирован под максимальную производительность и использование в каждом методе.

Стоит ли продолжать заморачиваться с проверкой передаваемых данных в каждой функции?

Да. За счет этого вы выигрываете в безопасности, надежности и времени поиска багов.

Перефразирую ваш вопрос: каково стояние дел у молотка по забиванию гвоздей?))

Где можно ознакомиться с состоянием дел у PHP?

php.net
habrahabr.ru
opennet.ru

Какой рантайм брать?

7-ка только-только вышла, пока что опасно. Берите 5.6

Какой фрейворк юзать?

Смотря какой проект.

Что с интернационализацией?

Если используется реализация из фреймворка - то, что в фреймворке. Если самопис - как напишите так и будет.

Люблю функции высшего порядка

В php их конечно можно использовать, но только там, где это необходимо. Вообще говоря это отличная практика по отстреливанию яиц.

он создан чтобы умирать

Все верно, это stateless язык, он так спроектирован, под свои задачи лучше пока не придумали.

А мне бы желательно запланировать на фронте возможность ещё и с вебсокета раздать уведомления.

Планируйте на здоровье, но на бэкенде под это лучше пойдет nodejs. Демоны на php конечно пишут, но это не целевое применение языка, такие дела.

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

В итоге я могу хоть 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?