Comments 11
мда, честно, статья ни о чем, плюс еще и технически не очень грамотная, мягко говоря. Все вышеописанное называется очень просто — middleware и описано уже миллион раз за многие годы и гораздо в более правильном виде.
Спасибо за комментарий.
Согласен с вами, статья получилась очень ограниченной. Она раскрывает только один маленький аспект проектирования middleware на Golang

Полный код приведен в репозитории.

Метод Process будет таким образом бесконечно прирастать if'ами и увеличивать таким образом цикломатическую сложность? Я, конечно, понимаю, что в реальных проектах всякое бывает, но зачем же это тащить как пример? К тому же ваш код слишком изобилует частностями из вашего проекта, что лишний раз показывает, что выбранный подход неуниверсален. Я бы рекомендовал вам подумать над универсализацией решения, оформления его в библиотеку на github и потом уже попробовать снова создать пост на хабре.


P. S. И да, как верно выше отметили, попутно ознакомьтесь с концепцией middleware.

Полностью согласен. В реальном проекте Process значительно сложнее.

Чтобы снизить цикломатическую сложность кода, все If сделаны без вложений с многочисленными точками выхода.
В примере метод Process содержит то, что по минимуму необходимо. Сложно представить проект в котором бы не было аутентификации, токенов, или не было бы потребности в периодическом логировании HTTP трафика.

Полный код приведен в репозитории.
В качестве детализации/реализации концепции middleware можно рассмотреть реверсный прокси, например, nginx, который решает большую (не всю без экзотики типа openresty, вроде бы) часть перечисленных задач с не очень доступной Вашей функции производительностью плюс ещё много всякого полезного умеет.
Вариант с реверсивным прокси для задач аутентификации, логирования HTTP трафика, поддержки токинов тестировался на Apache — отличное решение.
Только заказчик не захотел поддерживать и сопровождать еще один сервер приложений.

Поэтому и появилась эта статья — все что нужно можно легко сделать на Golang без использования дополнительных серверов приложений.
Gin пробовал для тестовых целей.
Но вариант без сторонних библиотек показал выше производительность.
Удалось получить до 15 000 [#/sec] с одного физического ядра.
Для простых задач описанный вариант отлично подходит.
Например, в таком варианте был реализован REST API к IBM MQ
Но вариант без сторонних библиотек показал выше производительность.
Удалось получить до 15 000 [#/sec] с одного физического ядра.

И что, 10k rps с ядра вас вас бы не устроил? какая у вас текущая нагрузка?

Если ваш вопрос "по текущей нагрузке", относится к REST API к IBM MQ, то там не нужно было более 1000 rps.
Там проблема с производительностью была в другом – каждое XML сообщение нужно было нормализовать (канонизация) по стандарту RFC 3076, завернуть его в транспортный пакет и посчитать для всего пакета HMAC с хэш-функцией ГОСТ-34.11.94.

Only those users with full accounts are able to leave comments. Log in, please.