Добрый день! Вы правы, с 1.22 действительно можно писать mux..HandleFunc("GET /post/{id}", handler) и получать параметр через r.PathValue("id") - обязательно сделаю на это ремарку в статье.
Все же, в концепцию этого цикла, как по мне, больше вписывается реализация ручного парсера, потому «Разбираем net/http на практике» нацелен на понимание внутреннего устройства пакета и его реализаций. Написание такого парсера позволяет относиться к фреймворку не как к черному ящику , а как к удобному инструменту с предсказуемым поведением
В продакшене, конечно, ваш вариант более целесообразен !
Понимаю, что в некоторых местах архитектура проекта кажется трудной для восприятия, на такой случай Вы всегда можете обратиться к гитхабу проекта - https://github.com/Meedoeed/DeadDrop. Здесь очень легко разобраться с файлами и структурой сервиса!
Разделяю Ваше мнение по поводу относительных путей и постараюсь более явно их указывать в следующих статьях цикла!
Оставайтесь с DeadDrop! Спасибо большое за такой полезный и развернутый отзыв!
Вы правы, сейчас это действительно просто обертка, но есть несколько практических причин для такой реализации. В нашем случае особо важны две:
1) Функция runServer в последствии будет нести цель его конфигурации - мы добавим тайм-ауты (лимиты на время ответа сервера) и т.д. - вся эта логика будет лучше смотреться в одном централизованном месте (этой функции)
2) По сути в дополнение к первому пункту: мы здорово расширим эту функцию по ходу разработки: В ней будет лежать graceful shutdown , health чеки сервера и т.д
Информация
В рейтинге
618-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Добрый день! Вы правы, с 1.22 действительно можно писать mux..HandleFunc("GET /post/{id}", handler) и получать параметр через r.PathValue("id") - обязательно сделаю на это ремарку в статье.
Все же, в концепцию этого цикла, как по мне, больше вписывается реализация ручного парсера, потому «Разбираем net/http на практике» нацелен на понимание внутреннего устройства пакета и его реализаций. Написание такого парсера позволяет относиться к фреймворку не как к черному ящику , а как к удобному инструменту с предсказуемым поведением
В продакшене, конечно, ваш вариант более целесообразен !
Спасибо за внимательность и ценный комментарий!
Очень рад, что проект показалась вам интересным!
Понимаю, что в некоторых местах архитектура проекта кажется трудной для восприятия, на такой случай Вы всегда можете обратиться к гитхабу проекта - https://github.com/Meedoeed/DeadDrop. Здесь очень легко разобраться с файлами и структурой сервиса!
Разделяю Ваше мнение по поводу относительных путей и постараюсь более явно их указывать в следующих статьях цикла!
Оставайтесь с DeadDrop! Спасибо большое за такой полезный и развернутый отзыв!
Большое спасибо за обратную связь!
Вы правы, сейчас это действительно просто обертка, но есть несколько практических причин для такой реализации. В нашем случае особо важны две:
1) Функция runServer в последствии будет нести цель его конфигурации - мы добавим тайм-ауты (лимиты на время ответа сервера) и т.д. - вся эта логика будет лучше смотреться в одном централизованном месте (этой функции)
2) По сути в дополнение к первому пункту: мы здорово расширим эту функцию по ходу разработки: В ней будет лежать graceful shutdown , health чеки сервера и т.д