Не очень вчитывался, но у меня вроде посложнее: - на внешний сигнал стопа закрываем прием новых запросов (у меня http-сервер), доделываем имеющиеся запросы, сервер по завершении обработки завершается и кидает ок в канал - по сигналу закрываются соединения с ресурсами, чтобы не потерять данные, - и потом выход из main (или жесткий шатдаун по истечении второго времени). И потому есть контекст на управление сервером, есть контекст запросов внутри сервера, и есть контекст на приложуху с ресурсами - данные в одну сторону. И каналы для ответов. Потому долго ковырялся.
Всё не настолько плохо, чтобы тащить новую зависимость. Мне не зашел "uber/fx". И за несколько дней разобрался в теме - задача красиво остановить сильно сложнее, чем запустить. Пучок каналов, несколько контекстов, waitgroups для внешних сервисов - и готово. Решение на пару сотен строк, разбросанных по модулям. Я за отсутствие магии в разработке, если что.
Добрых лучиков! Это кусок текста из "примерно в начале", где я набрасываю, что это не мой выбор. И там речь больше про чтение логов в chrome-for-devs. И в принципе работает - там текст же. Но ГОРАЗДО УДОБНЕЕ писать больше букв. В первую очередь, есть правило наименования переменных - чем дальше от места использования тем длиннее. И здесь по сути название очень далекой функции. Потому не надо сокращать. Про идентификаторы в путях типа "users/:id" подробно в разделе "о входящих данных". Если кроме одного идентификатора ничего не нужно - то ок. На этом REST API держится. Но если пересылать больше данных, которые уже в query/body И ДОПОЛНИТЕЛЬНО парсить путь - да зачем?! А если не пихать в путь, то сильно просто парсить входящие данные по ОДНОЙ модели с валидатором.
Вертушка - наоборот раскидывала входящие звонки на дежурных в разных офисах. А поднимать старые звонки через CRM было больнее, да. Я какое-то время назад вернулся в разрабы со своей идеей из недвижки. Долго пилил, теперь учусь продавать проект. Рекламу бросил давать еще до пандемии, но иногда делаю сделки - вот недавно меня нашла заказчица через 8 лет. С видео и аи в продажах недвиги не вижу перспектив - эффект мал, а трудоемкость высокая. А продвижение услуг - это НОВЫЕ контакты, то есть надо собрать клиентов (а не пользователей как в циан) в одном месте и свести с риелторами, которых надо фильтровать (не как в циан). Причем собрать на фоне перегретого информационного шума. Если так, то фантастика! Здесь просто общаемся, мне было приятно вспомнить что-то старое.
Стоит сначала определить, кто такой риелтор (у каждого риелтора своё определение профессии). Я склонен называть риелтора "доверенным специалистом". И сказал бы не о контент-голоде (обычно всякие страшилки) - а об отсутствии реальных контактов. Раньше с телефонной вертушки нормально клиентов набирали, и это то качество, которое не дает никакой контент (особенно сгенерированный) - клиент выбирает "своего" риелтора во многом по речи - громкость, чистота речи, понятность, и даже скорость и тембр. И приходит на личную встречу уже теплый. "Ведущие соцсети" - это имиджевая реклама, такое себе мало кто может позволить. И не всем надо - какие-то клиенты предпочитают тишину и кулуарность. З.Ы. РиЭлтор - это конкретно член Российской Гильдии Риэлторов. Грамотно писать "риелтор", но РГР зарегистрировало товарный знак "риэлтор". А называть себя таким словом может только тот, кто платит членские взносы. Риелтор - это устоявшееся название, которым любой себя может назвать.
Видео вообще в недвижке не нужно, от нейронки тем более. В первичке и так полно обмана, где соседнюю промзону или пустырь изображают на схеме взрослым лесом. Во вторичке база для ручной фильтрации (ну вы и так поняли после 100 собесов) - минимум времени на объявление по типовому шаблону. И смотреть видео будет никто. Есть общий тренд на то, что выбирают по фотографиям (витрина), а при визите уже подтверждают свое решение. Видео сработает для нестандартных объектов, которые невозможно сравнить с соседями - и уже другая оценка объекта. В целом рад, что вы опрашивали именно риелторов - обычно их почему-то игнорируют, когда что-то в недвижке хотят поменять.
Думаю, что зависит от назначения приложения. У меня сервер обслуживает сайт. И умеет всё с данными - это бизнес. А из сервисов там cron, рассылка и sse...
Entity/use_cases - это популярные слои. Походу я напутал. Use_cases решает "сложные" операции - типа "умные". И может вызывать entity и db. И entity - слой только про одну сущность. Типа здесь должно быть просто CRUD-операции, но внезапно разрастается из-за логики проксирования - нельзя в db минуя entity. И разделение на модули выше уровнем - я такое видел. И вот use_cases умеет всякие штуки, типа запрашивать данные из связанных сущностей. И один модуль запросто встретится с другим - функция из организаций вызывает список рабочих групп другого модуля. А рабочие группы вызывают полномочия участника в организации на переименование. Логично выделить такие "сложные" функции в отдельный слой, который может. И это получается супер слой, который чересчур сложен. И выше пишу - этот супер слой отлично распиливается в обработчики, но уже не тупые.
Уточню, что не структуры данных. А цикл импортов. Сущности великолепно себя чувствуют по отдельности - разные ветки и ок. А есть бизнес-слои "одного уровня", где они встречаются. И когда два слоя entity стучатся друг к другу - цикл. И не получается дублировать структуры, как в typescript - в го это разные структуры. Придумываются всякие DTO, которые идентичны оригиналу, но есть экспортируемые поля через методы (или дубликат структуры с преобразованием 1-к-1) - вот это костыль, имхо. Я порешал тему, подняв логику на обработчики - вообще 0 циклов. И хорошо читается код - например, всё про патч объекта ушло в http-обработчик. Вроде как не логично, но работать сильно проще. Оказалось, что запрос через очередь не будет пересекаться с запросом от сайта - разная логика и разные входящие данные. Потому за год не было конфликта в логике.
Модели DTO весьма странные штуки, которые, имхо, появились в go из другого языка. В go стоит передавать данные как аргументы. Но когда полей много, и их порядок сложен, то возникает соблазн объединить в один объект. Норм если точечно, но если юзать везде, то вдруг оказывается, что их также надо поддерживать. И это горькая пилюля. Пример зацикленности - организация и рабочая группа как часть. Организация знает и спрашивает вложенные рабгруппы. Но в рабгруппе хочется узнать про организацию, и кто ее директор. И "в лоб" уже цикл. Разруливается, но если таких много - персона и участник организации и туда-обратно. Вот про такие границы между сущностями я думал. Логика сверху-вниз - это обычное явление. Есть варианты с тем что верх и что вниз - у кого-то это снизу-вверх, но тождественно. И тут есть споры - можно ли сверху-вниз стучаться, минуя слои - из верхней логики сразу в слой данных, например. Если упираться и последовательно проксироваться через слои, то при росте количества функций выглядит весьма уродски. Транзакции тоже создают вопросы. ИМХО, должны быть на верхнем уровне (все последующие у меня принимают универсальный интерфейс), потому что наверху "оркестратор" решает: удачно закоммитился, то создаем сообщение об обновлении. Если транзакция ниже слоем, то возникает сложность вернуть в предыдущее состояние.
Не очень понятно, что вы предлагаете. В принципе все делят на слои, а как - это уже "все мужчины имеют свой способ избавления от последней капли". Понятно выделение слоя данных, а вот с бизнес-логикой не все понятно - где границы связности сущностей?! База в том, что сущности без связности вообще не работают. А если связывать в логике, то голанг видит зацикленность импортов. Кто-то разбивает через интерфейсы, это весьма тяжело поддерживать, когда много сущностей связано с многими сущностями. При этом не вижу ценности делать "тупые контроллеры" - я обнаружил, что этот слой очень ценен, так как обладает особенной логикой (https://habr.com/ru/articles/901938/). Например: http-обработчик проверяет доступ через jwt-токен, и выдает http-ошибку, а обработчик из очереди не будет проверять доступ перед исполнением, и выдает ошибку только в логгер. И такой подход юзаю уже год - код легко поддерживать, изменения вносить очень удобно. Пока кризиса не предвижу.
Наблюдаю в статье "привычный набор техник". В ключе "примени технику - получи результат". И напомню, что "кризис - это состояние, когда старые методы не действуют". То есть если чел выгорел - это ранее примененные методы уже подействовали. И далее "попробуйте новенькое" - смена стимулов (внешнее же воздействие!), чтобы чел на выдохе отработал пару месяцев, пока начальство новый грейд не закрыло. Если говорить о действительно хорошем сроке работы - 20-40 лет стажа в одной компании как раньше было нормой, то окажется, что все мотивы и стимулы давно придуманы и описаны.
Вспомнилась недавняя история с Яндекс. К собеседованию порешал литкод, но не больше десятка, конечно - не яндексом единым, как говорится. Первый собес отлично. Второй из двух задач - первая отлично всё, вторая про разбор строки - для сложности n нужно было знать какой-то замысловатый метод, который кроме как на литкоде не встретишь. Я вот не встретил. Получил отказ на втором этапе - поначалу думал, что лицом (или возрастом) не вышел. Типа ошибки вроде как нужны, чтобы посмотреть как думает кандидат. А если по памяти решить - то не интересно. Но это не про Яндекс, конечно. Следующий рекрутер пояснила, что в Яндексе типа в сапера играешь, ошибся - всё. И я вот в очередной раз разочаровался в людях. Параллельно была задачка второго этапа ВК - там не литкод, а "сложные вводные", интервьювер сам путался в своей же задаче. Решил, даже во время уложился, но чем-то всё равно не угодил, но так и не узнал чем. Имхо, "общий трек" только с голодухи можно пройти. Долбиться в стописот задач. И задрачивать собесы. Обычно рекрутеры и интервьюверы сами не знают "под кого" ищут. Потому "ищут волшебника - находят сказочника". Мне вот любопытно, есть ли "не голодные" специалисты, которые хотят на новом месте делать тоже самое, что и на старом? Имхо, всегда лезешь в новое, где что-то точно не знаешь.
В этот раз комменты вгоняют в тоску. И у меня сложилось мнение, что сводятся счеты по личным обидкам. Как раз к Петру я проходил первый собес - позитив и вообще "хорошо поговорили", но "уже нашли спеца в команду", а на общем треке в Озон столкнулся уже с формальным подходом. Про сервис обсуждали чуть больше чем два абзаца здесь - решает задачу не разраба, а бизнеса, потому что облака ни разу не дешевое удовольствие. VDS сильно дешевле. Статья вообще общеразвивающая на тему испытательного срока, и ни разу не про сервис. Я вот вляпался в коммуникации в команде и вылетел с испытательного, потому скажу, что статья полезная. Типа памятки перед новой командой и компанией.
Давно гоняю json-чики, и есть имхо по теме: 1. В json всегда кладу структуры с тегами, вместо map[string]any. И в проекте есть строго одно место где формирую map[string]any - и это не про json, а потом вставляю в html-шаблон. Еще можно парсить данные из бд в мапу - sqlx. Но зачем?! Кроме того, структуру можно подшить в доку openApi. То есть пример с мапой считаю вредным. Разве что полезно знать, что мапу тоже можно сериализовать... 2. В моем net/http сначала надо писать данные, а потом писать 200 OK. Иначе браузер закончит промис, не прочитав данные. Но эта тема не по свежим следам, просто пишу, что порядок важен. 3. Понимаю, что пример с "pages" - это способ натянуть сову на глобус, но почему так сложно вместо `[]byte(fmt.Sprintf("%s pages", pages))`?!
Впечатление от статьи, что автор ждет комментариев. И вот наследю. Конкретно наблюдаю наброс на "перфекционизм" - профессионалы задрачивают на долю процента. То же самое в профессиональном спорте - доля секунды решает всё, а обывателям ход на минуты. И такой перфекционизм выставляется нездоровым по психологии. Ему противопоставляется норма - обывательское "а мне больше и не надо". Но вспомним другое значение слова "перфекционизм", на этот раз из философии - https://ru.wikipedia.org/wiki/Перфекционизм_(философия) И как-то красок в руке становится больше одной!
Я топлю за tailwind + ui-radix/primitives => свой kit. Но по скорости это скорее неторопливо, потому что в kit влезаю, когда тошнит от бэкенда. Начинал со стилей в ms word и css в dreamweaver. На современном react юзал bootstrap, но без компонентов - всырую шпаклевал классами из bootstrap. В принципе работало. Потом последовательно узнал shadcn, radix-ui и tailwind. На этом этапе уже понял, что tailwind мне по душе. И нравились radix-ui/themes, но они плюсут свой контекст css-классов, и у меня продукт включает два набора css, что заметно полнит. Сейчас выпиливаю themes, оставляю tailwind+redix-ui/primitives по примеру shadcn. Длиннющие перечни классов tailwind лечатся переносом строк "x "+"y" или cn(...), которая join'ит строки. Пример посмотрите в shadcn. И еще там же есть cva(), которая позволяет пропсами настраивать компоненты - а логика из primitives.
Обработка ошибки в враппере - интуитивно понятный подход, я тоже так делаю, хоть и через структуру в контексте - кроме 200 бывает 204, и обрабатываю случай, когда закомментил логику в обработчике. Тогда выбрасываю 418. А вот добавление ошибки к сигнатуре `func (w,r)` - тупиковый путь, ИМХО. Хотя бы потому, что сильно ломается совместимость, и появляются новые костыли. И мне очень нравится оригинальная сигнатура без ошибки - она СИЛЬНО отличает код http-обработчика от обычного модуля. Подробнее писал здесь: https://habr.com/ru/articles/901938/ Вкратце: обработчику доступны разные http-коды, бизнес-логика знает только error. И выходит, что какой-то слой должен отделять мух от котлет - мне зашло оставить в обработчике, теперь "умный обработчик" знает часть логики (статья об этом). Были возражения типа "этот слой не для этого". Здесь наверно надо определить термины. Выделяю http-слой, который реально транспорт и легко заменяется шиной данных. А есть http-слой, который обслуживает web-клиент со своей логикой и ресурсами, и который никогда не будет принимать данные из других протоколов. Это две большие разницы!
Не очень вчитывался, но у меня вроде посложнее:
- на внешний сигнал стопа закрываем прием новых запросов (у меня http-сервер), доделываем имеющиеся запросы, сервер по завершении обработки завершается и кидает ок в канал
- по сигналу закрываются соединения с ресурсами, чтобы не потерять данные,
- и потом выход из main (или жесткий шатдаун по истечении второго времени).
И потому есть контекст на управление сервером, есть контекст запросов внутри сервера, и есть контекст на приложуху с ресурсами - данные в одну сторону. И каналы для ответов. Потому долго ковырялся.
Всё не настолько плохо, чтобы тащить новую зависимость. Мне не зашел "uber/fx". И за несколько дней разобрался в теме - задача красиво остановить сильно сложнее, чем запустить. Пучок каналов, несколько контекстов, waitgroups для внешних сервисов - и готово. Решение на пару сотен строк, разбросанных по модулям.
Я за отсутствие магии в разработке, если что.
Добрых лучиков! Это кусок текста из "примерно в начале", где я набрасываю, что это не мой выбор. И там речь больше про чтение логов в chrome-for-devs. И в принципе работает - там текст же. Но ГОРАЗДО УДОБНЕЕ писать больше букв. В первую очередь, есть правило наименования переменных - чем дальше от места использования тем длиннее. И здесь по сути название очень далекой функции. Потому не надо сокращать.
Про идентификаторы в путях типа "users/:id" подробно в разделе "о входящих данных". Если кроме одного идентификатора ничего не нужно - то ок. На этом REST API держится. Но если пересылать больше данных, которые уже в query/body И ДОПОЛНИТЕЛЬНО парсить путь - да зачем?! А если не пихать в путь, то сильно просто парсить входящие данные по ОДНОЙ модели с валидатором.
Вертушка - наоборот раскидывала входящие звонки на дежурных в разных офисах. А поднимать старые звонки через CRM было больнее, да.
Я какое-то время назад вернулся в разрабы со своей идеей из недвижки. Долго пилил, теперь учусь продавать проект. Рекламу бросил давать еще до пандемии, но иногда делаю сделки - вот недавно меня нашла заказчица через 8 лет.
С видео и аи в продажах недвиги не вижу перспектив - эффект мал, а трудоемкость высокая. А продвижение услуг - это НОВЫЕ контакты, то есть надо собрать клиентов (а не пользователей как в циан) в одном месте и свести с риелторами, которых надо фильтровать (не как в циан). Причем собрать на фоне перегретого информационного шума. Если так, то фантастика!
Здесь просто общаемся, мне было приятно вспомнить что-то старое.
Стоит сначала определить, кто такой риелтор (у каждого риелтора своё определение профессии). Я склонен называть риелтора "доверенным специалистом". И сказал бы не о контент-голоде (обычно всякие страшилки) - а об отсутствии реальных контактов. Раньше с телефонной вертушки нормально клиентов набирали, и это то качество, которое не дает никакой контент (особенно сгенерированный) - клиент выбирает "своего" риелтора во многом по речи - громкость, чистота речи, понятность, и даже скорость и тембр. И приходит на личную встречу уже теплый.
"Ведущие соцсети" - это имиджевая реклама, такое себе мало кто может позволить. И не всем надо - какие-то клиенты предпочитают тишину и кулуарность.
З.Ы. РиЭлтор - это конкретно член Российской Гильдии Риэлторов. Грамотно писать "риелтор", но РГР зарегистрировало товарный знак "риэлтор". А называть себя таким словом может только тот, кто платит членские взносы. Риелтор - это устоявшееся название, которым любой себя может назвать.
Видео вообще в недвижке не нужно, от нейронки тем более. В первичке и так полно обмана, где соседнюю промзону или пустырь изображают на схеме взрослым лесом.
Во вторичке база для ручной фильтрации (ну вы и так поняли после 100 собесов) - минимум времени на объявление по типовому шаблону. И смотреть видео будет никто. Есть общий тренд на то, что выбирают по фотографиям (витрина), а при визите уже подтверждают свое решение. Видео сработает для нестандартных объектов, которые невозможно сравнить с соседями - и уже другая оценка объекта.
В целом рад, что вы опрашивали именно риелторов - обычно их почему-то игнорируют, когда что-то в недвижке хотят поменять.
Думаю, что зависит от назначения приложения. У меня сервер обслуживает сайт. И умеет всё с данными - это бизнес. А из сервисов там cron, рассылка и sse...
Entity/use_cases - это популярные слои. Походу я напутал. Use_cases решает "сложные" операции - типа "умные". И может вызывать entity и db. И entity - слой только про одну сущность. Типа здесь должно быть просто CRUD-операции, но внезапно разрастается из-за логики проксирования - нельзя в db минуя entity. И разделение на модули выше уровнем - я такое видел.
И вот use_cases умеет всякие штуки, типа запрашивать данные из связанных сущностей. И один модуль запросто встретится с другим - функция из организаций вызывает список рабочих групп другого модуля. А рабочие группы вызывают полномочия участника в организации на переименование.
Логично выделить такие "сложные" функции в отдельный слой, который может. И это получается супер слой, который чересчур сложен. И выше пишу - этот супер слой отлично распиливается в обработчики, но уже не тупые.
Уточню, что не структуры данных. А цикл импортов. Сущности великолепно себя чувствуют по отдельности - разные ветки и ок. А есть бизнес-слои "одного уровня", где они встречаются. И когда два слоя entity стучатся друг к другу - цикл. И не получается дублировать структуры, как в typescript - в го это разные структуры. Придумываются всякие DTO, которые идентичны оригиналу, но есть экспортируемые поля через методы (или дубликат структуры с преобразованием 1-к-1) - вот это костыль, имхо.
Я порешал тему, подняв логику на обработчики - вообще 0 циклов. И хорошо читается код - например, всё про патч объекта ушло в http-обработчик. Вроде как не логично, но работать сильно проще. Оказалось, что запрос через очередь не будет пересекаться с запросом от сайта - разная логика и разные входящие данные. Потому за год не было конфликта в логике.
Модели DTO весьма странные штуки, которые, имхо, появились в go из другого языка. В go стоит передавать данные как аргументы. Но когда полей много, и их порядок сложен, то возникает соблазн объединить в один объект. Норм если точечно, но если юзать везде, то вдруг оказывается, что их также надо поддерживать. И это горькая пилюля.
Пример зацикленности - организация и рабочая группа как часть. Организация знает и спрашивает вложенные рабгруппы. Но в рабгруппе хочется узнать про организацию, и кто ее директор. И "в лоб" уже цикл. Разруливается, но если таких много - персона и участник организации и туда-обратно. Вот про такие границы между сущностями я думал.
Логика сверху-вниз - это обычное явление. Есть варианты с тем что верх и что вниз - у кого-то это снизу-вверх, но тождественно. И тут есть споры - можно ли сверху-вниз стучаться, минуя слои - из верхней логики сразу в слой данных, например. Если упираться и последовательно проксироваться через слои, то при росте количества функций выглядит весьма уродски.
Транзакции тоже создают вопросы. ИМХО, должны быть на верхнем уровне (все последующие у меня принимают универсальный интерфейс), потому что наверху "оркестратор" решает: удачно закоммитился, то создаем сообщение об обновлении. Если транзакция ниже слоем, то возникает сложность вернуть в предыдущее состояние.
Не очень понятно, что вы предлагаете. В принципе все делят на слои, а как - это уже "все мужчины имеют свой способ избавления от последней капли".
Понятно выделение слоя данных, а вот с бизнес-логикой не все понятно - где границы связности сущностей?! База в том, что сущности без связности вообще не работают. А если связывать в логике, то голанг видит зацикленность импортов. Кто-то разбивает через интерфейсы, это весьма тяжело поддерживать, когда много сущностей связано с многими сущностями.
При этом не вижу ценности делать "тупые контроллеры" - я обнаружил, что этот слой очень ценен, так как обладает особенной логикой (https://habr.com/ru/articles/901938/). Например: http-обработчик проверяет доступ через jwt-токен, и выдает http-ошибку, а обработчик из очереди не будет проверять доступ перед исполнением, и выдает ошибку только в логгер.
И такой подход юзаю уже год - код легко поддерживать, изменения вносить очень удобно. Пока кризиса не предвижу.
Посмотрел с интересом. А ссылка на канал битая
Наблюдаю в статье "привычный набор техник". В ключе "примени технику - получи результат". И напомню, что "кризис - это состояние, когда старые методы не действуют". То есть если чел выгорел - это ранее примененные методы уже подействовали. И далее "попробуйте новенькое" - смена стимулов (внешнее же воздействие!), чтобы чел на выдохе отработал пару месяцев, пока начальство новый грейд не закрыло.
Если говорить о действительно хорошем сроке работы - 20-40 лет стажа в одной компании как раньше было нормой, то окажется, что все мотивы и стимулы давно придуманы и описаны.
Вспомнилась недавняя история с Яндекс. К собеседованию порешал литкод, но не больше десятка, конечно - не яндексом единым, как говорится. Первый собес отлично. Второй из двух задач - первая отлично всё, вторая про разбор строки - для сложности n нужно было знать какой-то замысловатый метод, который кроме как на литкоде не встретишь. Я вот не встретил. Получил отказ на втором этапе - поначалу думал, что лицом (или возрастом) не вышел. Типа ошибки вроде как нужны, чтобы посмотреть как думает кандидат. А если по памяти решить - то не интересно. Но это не про Яндекс, конечно. Следующий рекрутер пояснила, что в Яндексе типа в сапера играешь, ошибся - всё. И я вот в очередной раз разочаровался в людях.
Параллельно была задачка второго этапа ВК - там не литкод, а "сложные вводные", интервьювер сам путался в своей же задаче. Решил, даже во время уложился, но чем-то всё равно не угодил, но так и не узнал чем.
Имхо, "общий трек" только с голодухи можно пройти. Долбиться в стописот задач. И задрачивать собесы. Обычно рекрутеры и интервьюверы сами не знают "под кого" ищут. Потому "ищут волшебника - находят сказочника".
Мне вот любопытно, есть ли "не голодные" специалисты, которые хотят на новом месте делать тоже самое, что и на старом? Имхо, всегда лезешь в новое, где что-то точно не знаешь.
В этот раз комменты вгоняют в тоску. И у меня сложилось мнение, что сводятся счеты по личным обидкам.
Как раз к Петру я проходил первый собес - позитив и вообще "хорошо поговорили", но "уже нашли спеца в команду", а на общем треке в Озон столкнулся уже с формальным подходом. Про сервис обсуждали чуть больше чем два абзаца здесь - решает задачу не разраба, а бизнеса, потому что облака ни разу не дешевое удовольствие. VDS сильно дешевле.
Статья вообще общеразвивающая на тему испытательного срока, и ни разу не про сервис. Я вот вляпался в коммуникации в команде и вылетел с испытательного, потому скажу, что статья полезная. Типа памятки перед новой командой и компанией.
Давно гоняю json-чики, и есть имхо по теме:
1. В json всегда кладу структуры с тегами, вместо map[string]any. И в проекте есть строго одно место где формирую map[string]any - и это не про json, а потом вставляю в html-шаблон. Еще можно парсить данные из бд в мапу - sqlx. Но зачем?! Кроме того, структуру можно подшить в доку openApi. То есть пример с мапой считаю вредным. Разве что полезно знать, что мапу тоже можно сериализовать...
2. В моем net/http сначала надо писать данные, а потом писать 200 OK. Иначе браузер закончит промис, не прочитав данные. Но эта тема не по свежим следам, просто пишу, что порядок важен.
3. Понимаю, что пример с "pages" - это способ натянуть сову на глобус, но почему так сложно вместо `[]byte(fmt.Sprintf("%s pages", pages))`?!
Впечатление от статьи, что автор ждет комментариев. И вот наследю.
Конкретно наблюдаю наброс на "перфекционизм" - профессионалы задрачивают на долю процента. То же самое в профессиональном спорте - доля секунды решает всё, а обывателям ход на минуты. И такой перфекционизм выставляется нездоровым по психологии. Ему противопоставляется норма - обывательское "а мне больше и не надо".
Но вспомним другое значение слова "перфекционизм", на этот раз из философии - https://ru.wikipedia.org/wiki/Перфекционизм_(философия)
И как-то красок в руке становится больше одной!
Я топлю за tailwind + ui-radix/primitives => свой kit. Но по скорости это скорее неторопливо, потому что в kit влезаю, когда тошнит от бэкенда.
Начинал со стилей в ms word и css в dreamweaver. На современном react юзал bootstrap, но без компонентов - всырую шпаклевал классами из bootstrap. В принципе работало. Потом последовательно узнал shadcn, radix-ui и tailwind. На этом этапе уже понял, что tailwind мне по душе. И нравились radix-ui/themes, но они плюсут свой контекст css-классов, и у меня продукт включает два набора css, что заметно полнит. Сейчас выпиливаю themes, оставляю tailwind+redix-ui/primitives по примеру shadcn.
Длиннющие перечни классов tailwind лечатся переносом строк "x "+"y" или cn(...), которая join'ит строки. Пример посмотрите в shadcn.
И еще там же есть cva(), которая позволяет пропсами настраивать компоненты - а логика из primitives.
Обработка ошибки в враппере - интуитивно понятный подход, я тоже так делаю, хоть и через структуру в контексте - кроме 200 бывает 204, и обрабатываю случай, когда закомментил логику в обработчике. Тогда выбрасываю 418.
А вот добавление ошибки к сигнатуре `func (w,r)` - тупиковый путь, ИМХО. Хотя бы потому, что сильно ломается совместимость, и появляются новые костыли. И мне очень нравится оригинальная сигнатура без ошибки - она СИЛЬНО отличает код http-обработчика от обычного модуля. Подробнее писал здесь: https://habr.com/ru/articles/901938/
Вкратце: обработчику доступны разные http-коды, бизнес-логика знает только error. И выходит, что какой-то слой должен отделять мух от котлет - мне зашло оставить в обработчике, теперь "умный обработчик" знает часть логики (статья об этом).
Были возражения типа "этот слой не для этого". Здесь наверно надо определить термины. Выделяю http-слой, который реально транспорт и легко заменяется шиной данных. А есть http-слой, который обслуживает web-клиент со своей логикой и ресурсами, и который никогда не будет принимать данные из других протоколов. Это две большие разницы!
Да. Видел "сетевую папку". Поторопился с выводом ;)