Термин «изобретение колеса заново» может показаться неприятным для ушей большинства разработчиков. Но почему-то мне всегда нравится изобретать заново то, что существует. Всегда приятно учиться делать то, что делал кто-то другой. К счастью, большинство моих изобретений обычно являются просто экспериментами и никогда не публиковались, в основном они попадали в мусорное ведро через несколько месяцев, так что я никогда не заставлял моего коллегу чесаться в ушах.
Недавно я перенес на гитхаб один из своих экспериментов. Это библиотека для создания веб-приложений или веб-сервисов с использованием языка Go, в настоящее время она все еще находится в стадии разработки. Это началось как эксперимент по составлению шаблонных кодов, которые я обычно писал для веб-приложений или веб-сервисов.
Суть веб-фреймворков в том, что я слишком ленив, чтобы научиться их использовать, а большинство из них добавляет сложности. Что ж, термин «комплекс», наверное, слишком относительный, не так ли? Одна вещь, которую я считаю сложной, не всегда означает то же самое для других людей, наоборот.
Одна вещь, которую я считаю сложной, - это перенос сигнатуры обработчика из стандартной библиотеки, что-то вроде этого.
func Foo(ctx lib.Context)
Я сделал что-то подобное в проекте в прошлом году, и мне показалось, что я могу легко делать большинство вещей, когда могу просто связать все с контекстом, переданным в обработчик. В этом нет ничего плохого, мы должны писать код, который будет комфортно поддерживать нас и членов нашей команды.
Но время от времени кажется, что стандартная подпись обработчика - лучший выход. Итак, в моей веб-библиотеке маршрутизация зарегистрирована с использованием стандартного http.Handler. Таким образом, если я чувствую, что хочу заменить маршрутизатор, я могу просто заменить его без особых затрат. Еще лучше, если я позволю пользователю заменить встроенный маршрутизатор на свой, но в настоящее время он еще не поддерживается.
Самое интересное в использовании стандартной сигнатуры обработчика - это получение данных всего приложения, таких как настройки приложения. Здесь я много узнал о промежуточном программном обеспечении. Промежуточное ПО делает что-то до того, как запрос будет передан обработчику, и мы можем прикрепить данные к запросу через эти промежуточные программы, используя контекст запроса. Промежуточное ПО связывает друг друга с поведением FIFO, промежуточное ПО, добавленное первым, будет выполнено первым, и результат повлияет на следующие промежуточные ПО. Таким образом, мы можем поместить инициализированные данные всего приложения в первое промежуточное ПО, внести необходимые изменения в следующие промежуточные ПО и сохранить их в контексте запроса. Позже внутри обработчика мы можем получить данные из контекста, используя ключ, используемый для их сохранения.
Подводя итог, можно сказать, что использование стандартной подписи обработчика с промежуточным программным обеспечением может заменить необходимость использования настраиваемой подписи обработчика, поскольку мы можем передавать данные через контекст запроса. Но в первые дни, когда запрос не имеет контекста, настраиваемая подпись может быть действительно полезной.
