Спасибо! Точное количество частей пока не планировал - хочу двигаться от основ к более практическим темам и смотреть по ходу, насколько подробно стоит разбирать каждую. Материала по Kubernetes много, так что продолжение точно будет :)
Добрый день! Вы правы, с 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 чеки сервера и т.д
Информация
В рейтинге
70-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Большое спасибо! Новая часть уже доступна в профиле!
Спасибо, добавлю обязательно!
Спасибо! Исправлю!
Рад стараться! Спасибо за теплый отзыв!
Набросок с текстом сделать можно в любом графическом редакторе, стилизовать через ChatGPT
Спасибо за внимание и теплые отзывы, исправлю)
Большое спасибо за отзыв! Рад помочь!
Большое спасибо, буду стараться дальше)
Большое спасибо за тёплый отзыв! Новая статья уже в профиле)
Большое спасибо за теплый отзыв, буду стараться дальше !
Спасибо! Точное количество частей пока не планировал - хочу двигаться от основ к более практическим темам и смотреть по ходу, насколько подробно стоит разбирать каждую. Материала по Kubernetes много, так что продолжение точно будет :)
Здравствуйте, добавил в начало! Спасибо за комментарий!
Большое спасибо за отзыв! Продолжение уже вышло, буду рад, если уделите время)
Большое спасибо за тёплый отзыв, сегодня-завтра будет вторая часть, постараюсь также подробно все объяснить!
Спасибо за отзыв! Постараюсь поскорее !
Добрый день! Вы правы, с 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 чеки сервера и т.д