api это не внешний а свой пакет в котором заложено ФСЕ что надо для получения запроса и выдачи ответа

Обычно за логику и работу с репозиторием, аггрегацию данных из разных сервисов и бизнес логику все же отвечает сервис (юзкейс). Ну это если душнить уж, могут на интервью придраться

Вам указали место на панику, а дальше ваше дело принимать или нет) По опыту лишь скажу, что не надо быть столь уверенным, особенно с контекстом, где данные легко могут быть мутированы или переданы не того типа и все фенита ля комедия

Уже 4 года более 8 проектов без ля-комедия стабильно в проде работают

Обычно за логику и работу с репозиторием, аггрегацию данных из разных сервисов и бизнес логику все же отвечает сервис (юзкейс). Ну это если душнить уж, могут на интервью придраться

Разные fw и разные подходы есть, конечно можно прям в каждом шаге движения модели данных опять расставлять ловушки, но я за грамотное разделение логики без излишних переусложнений системы. Иначе потом случаются казусы когда в одном слое новую переменную чекают а в другом забыли, или еще хуже когда новый разраб вообще не в курсе какой слой проверок основной. А эти моменты я считаю важны в любом проекте. И еще одно правило - хочешь внести изменения в функции пакета который ты не пилил спроси у старшего что да как можно ли.

Эта битва будет вечной 😂

Мой пример взят из самого стандартного rest сервиса, не вижу смысла в нем создавать больше чем 4-5 слоев

а показать как этот product сохраняется?

вообще в запой уйдете 🤣

Понятно что валидаторы в самой модели настроены и есть еще пару специй под соусом при старте проекта, НО любой новичек не трогая другие пакеты обработки легко и просто пилит rest где все понятно и четко

Понятно что валидаторы в самой модели настроены и есть еще пару специй под соусом при старте проекта, НО любой новичек не трогая другие пакеты обработки легко и просто пилит rest где все понятно и четко

А в сторону grpc гетвея не смотрел?

Там клиент и сервер grpc, jsonrpc и swagger для них из протобафа автоматом генерится

А в сторону grpc гетвея не смотрел?

Да вот как раз есть времечко заныриваю туда, изучаю. Только генератор из схемы grahpql использовал в двух проектах.

А как работает эта странная перемкнная output?

подозреваю по-сишному(

там возвращать можно только одно значение, и если возращаемых несколько, идеоматично передавать их указателями в виде аргументов

А как работает эта странная перемкнная output?

она объявляется разными структурами в другом месте var output ProductFull и в api.MakeResponse принимается как any: func MakeResponse(c *fiber.Ctx, result []byte, obj any) error {...}

и внутри проверка и обработка всего что только возможно, все исключения в ответах из бд, пользовательские коды ошибок, тоже логирование можно

а зачем в урле указывать действие(create), это же нарушает рест

или массив var output []ProductShort

а зачем в урле указывать действие(create), это же нарушает рест

в смысле нарушает? как можно get put post delete нарушить? его только расширить роутом можно, тут еще как с фронтом договоришься.

она объявляется разными структурами в другом месте var output ProductFull и в api.MakeResponse принимается как any: func MakeResponse(c *fiber.Ctx, result []byte, obj any) error {...}

Жесть какая

Жесть какая

Так это локальная переменная для функции запрос отработал все изолированно передалось пережувалось и память очищается gc, зачем изобретать велосипед, пока где-то рефлексируют еще, тут за две недели с новичком все api для фронта с 60+ endpoints готово. Привыкли в модерн разработки команды раздувать на две кнопки три комадны))

или зачем ее по разному называть в разных функциях? есть идеи?

ну ок напишем тут var productArr []ProductShort передадим и что?

Думаю почему гоферы некоторые ругаются на го, теперь пазл сложился, есть впечатление что многие любят побольше кода пописать, побольше багов выявить и потом давай в рантайм че-то лезут, думают как gc переписать. 😆 В разработке - кратость сестра таланта))

ну ок напишем тут var productArr []ProductShort передадим и что?

Да просто вы объявляете переменную и сразу пустую передаете ее в метод. Пытаюсь понять, в чем смысл, она же потом не используется(то есть не модифаится), ну и очевидно никакого значения кроме своего типа в функцию не передает

Да просто вы объявляете переменную и сразу пустую передаете ее в метод. Пытаюсь понять, в чем смысл, она же потом не используется(то есть не модифаится), ну и очевидно никакого значения кроме своего типа в функцию не передает

Да тут согласен можно было и так сделать, и строк меньше: return api.MakeResponse(c, result, []ProductShort{}) скорее это для того чтоб визуально обозначить какую именно сущность передаем, тут оно третьим параметром легче не заметить и при копипасте оно может вернуть ошибку хотя из бд данные адекватные прилетели просто не в тот тип запихиваться будет.

Думаю почему гоферы некоторые ругаются на го, теперь пазл сложился, есть впечатление что многие любят побольше кода пописать, побольше багов выявить и потом давай в рантайм че-то лезут, думают как gc переписать. 😆 В разработке - кратость сестра таланта))

Не любим лишнего кода писать, но в основе концепции микросервисной архитектуры, микросервис окружает чужеродная среда, то есть данные на входе проходят валидацию. У вас микросервисы или монолит распределённый?

Да тут согласен можно было и так сделать, и строк меньше: return api.MakeResponse(c, result, []ProductShort{}) скорее это для того чтоб визуально обозначить какую именно сущность передаем, тут оно третьим параметром легче не заметить и при копипасте оно может вернуть ошибку хотя из бд данные адекватные прилетели просто не в тот тип запихиваться будет.

Безумие, конечно

Хоть бы дженерик взяли, и то польза была бы от этой технологии

Безумие, конечно

Не согласен, надо понять сначала что и для чего делается... там на выходе всегда один и тот же контракт json несмотря ни на что, c параметрами success, data, msg, code, time и для data разные сущности, с проверкой всего в одном месте что оно соответствует ожидаемому с фронта результату. Поэтому только предыдущая функция решает какую именно сущность возвращаем и что проверять или ерор если не то. А у вас одна критика очень даже частого рабочего решения, кроме фраз типа "жесть", "безумие", киньте кусок альтернативного варианта, если меньше строк кода вообще респект.

Не любим лишнего кода писать, но в основе концепции микросервисной архитектуры, микросервис окружает чужеродная среда, то есть данные на входе проходят валидацию. У вас микросервисы или монолит распределённый?

И то и то есть.

Хоть бы дженерик взяли, и то польза была бы от этой технологии

вы предлагаете что-то с потолка даже не вникнув в то для чего оно именно в этой конструкции кода может быть использовано... это не хорошо

ладно были бы хоть исходники перед глазами, тут да можно было что-то предложить попробовать зарефакторить один проброс, замерить показатели что быстрее на фейк данных etc...

Не любим лишнего кода писать, но в основе концепции микросервисной архитектуры, микросервис окружает чужеродная среда, то есть данные на входе проходят валидацию. У вас микросервисы или монолит распределённый?

Разве нельзя сделать валидации на точках входа из внешних систем, а в остальных микросервисах одного продукта не валидировать входные данные, воспользовавшись подходом code by contract?

Думаю почему гоферы некоторые ругаются на го, теперь пазл сложился, есть впечатление что многие любят побольше кода пописать, побольше багов выявить и потом давай в рантайм че-то лезут, думают как gc переписать. 😆 В разработке - кратость сестра таланта))

Мне кажется, вы троллите. Вы избыточную сложность не отрезали, а перенесли в скуль, где она...впрочем, это уже обсуждалось. В общем вы скрините верхушку айсберга и говорите, что это весь айсберг.

Разве нельзя сделать валидации на точках входа из внешних систем, а в остальных микросервисах одного продукта не валидировать входные данные, воспользовавшись подходом code by contract?

Можно, как показала практика, вообще не делать валидации при 100% уверенности, или при 100% экономии на расходы (встречал такое у нас и не раз). Но по концепции микросервисы могут делать разные команды, и людям свойственно ошибаться. :)

Можно, как показала практика, вообще не делать валидации при 100% уверенности, или при 100% экономии на расходы (встречал такое у нас и не раз). Но по концепции микросервисы могут делать разные команды, и людям свойственно ошибаться. :)

Спасибо за точку зрения, полезно.

Спасибо за точку зрения, полезно.

В разработке, как я понял, нет вообще каких то 100% верных решений, все очень гибко, и обычно бизнес решает как правильнее. Например бизнесу нужно быстро (иначе обойдут конкуренты), и покрытие тестами 0%, но проект взлетел. В такой ситуации я считаю что прав бизнес, он и денег даст так как смог заработать, а не: "все должно быть покрыто тестами."

Да подход и скорость выдачи функционала между маленькая средняя и крупная компания всегда будет в разы отличаться.

Мне кажется, вы троллите. Вы избыточную сложность не отрезали, а перенесли в скуль, где она...впрочем, это уже обсуждалось. В общем вы скрините верхушку айсберга и говорите, что это весь айсберг.

Не троллю а просто поделился альтернативным подходом используя больше мощь sql и acid подхода, которые вполне себе применимы даже в микросервисах

Не троллю а просто поделился альтернативным подходом используя больше мощь sql и acid подхода, которые вполне себе применимы даже в микросервисах

при таком подходе Го совсем не нужен, счастливой поддержки кода

при таком подходе Го совсем не нужен, счастливой поддержки кода

да нормально все поддерживается, есть отдельная репа для бд там так же как в схемах содержится актуальность и таблиц и функций, история изменений структуры бд (очень полезная штука кстати), коммиты как обычно, номер таски привязываем, да и еще и миграции сразу, пару bash скриптов которые новые и изменившиеся файлы в новую миграцию мержат, и вуаля, полная управляемость 🤗 Я вообще считаю что все что в бд происходит нельзя на самотек пускать, важно фиксировать все изменения, так как это во многих системах ни много ни мало все таки основное хранилище данных.

да нормально все поддерживается, есть отдельная репа для бд там так же как в схемах содержится актуальность и таблиц и функций, история изменений структуры бд (очень полезная штука кстати), коммиты как обычно, номер таски привязываем, да и еще и миграции сразу, пару bash скриптов которые новые и изменившиеся файлы в новую миграцию мержат, и вуаля, полная управляемость 🤗 Я вообще считаю что все что в бд происходит нельзя на самотек пускать, важно фиксировать все изменения, так как это во многих системах ни много ни мало все таки основное хранилище данных.

а как сделать blue-green deployment или не дай бог откат?

#вакансия #golang #go #midle #senior Всем привет! 📣Вакансия Golang-разработчик Всем привет! УСЛОВИЯ: ▫️Локация: возможна удаленная работа или же работа в офисе (готовы отталкиваться от пожеланий кандидата); Город Москва ▫️График: 5/2. ▫️Оформление по ТК РФ (расширенный ДМС). ▫️Оклад 💰 (от 150k до 450k в зависимости от опыта) 💡ЗАДАЧИ: Обязанности - Участие в проектировании архитектуры с использованием нашей платформы - Изучение новых технологий и внедрение их в проект - Реализация бизнес-фич - Работа с техническим долгом и написание авто- и unit-тестов - Непрерывно обучаться, совершенствовать свои знания и навыки 🔎ТРЕБОВАНИЯ: Опыт разработки на Golang от 2 лет Опыт разработки многопоточных приложений Опыт разработки Web-сервисов (REST, gRPC) Опыт работы с реляционными базами данных и брокерами сообщений Опыт работы с Unix-системами Желателен Опыт работы с нереляционными базами данных, такими как ElasticSearch, ClickHouse Опыт построения высоконагруженных сервисов В случae зaинтepeсoвaннoсти (и релевантности опыта!), пишитe в личку 📲 @Anastasialma

Я не эйчар)

а) но мой вопрос всë равно в силе ) вы ж где-то работаете и кого-то собесите?

а) но мой вопрос всë равно в силе ) вы ж где-то работаете и кого-то собесите?

Не хочу рекламировать тут рабовладельцев работодателей, отпишусь в личку)

Сколько аренда в месяц?

Не хочу рекламировать тут рабовладельцев работодателей, отпишусь в личку)

Рабовладельцы 😆👌🤣

На одном собесе меня спросили про вопрос передачи указателей и данных. Я сказал что в целом пофиг, можно передавать все по значению или по указателю. Все равно все сожрёт сеть и бд. А если нет, то надо уже профилировать и смотреть где конкретно можно выиграть, совсем не факт что это будет передача указателей) Но этот ответ интервьюера не устроил, он хотел конкретные цифры услышать. Это реально кринж.

Интервьюер ваш прав на все 146%. А вам стоит подучить чем отличается передача параметров по указателю и по значению и где применять то и другое. А уж заявление в стиле «потом отпрофайлим» это уж совсем красная лампочка, я б лично на этом месте с вами сразу попрощался. Так что это действительно кринж.

Интервьюер ваш прав на все 146%. А вам стоит подучить чем отличается передача параметров по указателю и по значению и где применять то и другое. А уж заявление в стиле «потом отпрофайлим» это уж совсем красная лампочка, я б лично на этом месте с вами сразу попрощался. Так что это действительно кринж.

а можете просветить, пожалуйста? или ссылку скинуть. интересно узнать.

а можете просветить, пожалуйста? или ссылку скинуть. интересно узнать.

Ну банально то, что у тебя при аппенде может быть ошибка, если слайс по значению передать

ну, такую базу я думаю тут понимают почти все) и причем тут ошибка, слайс по значению как раз таки передавать и стоит, просто мутировать его не надо, а надо возвращать новый слайс из функции/метода, как советуют разрабы языка. я спрашивал про тонкости работы с памятью скорее)

ну, такую базу я думаю тут понимают почти все) и причем тут ошибка, слайс по значению как раз таки передавать и стоит, просто мутировать его не надо, а надо возвращать новый слайс из функции/метода, как советуют разрабы языка. я спрашивал про тонкости работы с памятью скорее)

Ну интервьюер даже базу не услышал, он услышал: «похер как передавать»

ну, такую базу я думаю тут понимают почти все) и причем тут ошибка, слайс по значению как раз таки передавать и стоит, просто мутировать его не надо, а надо возвращать новый слайс из функции/метода, как советуют разрабы языка. я спрашивал про тонкости работы с памятью скорее)

Была конференция, Владимир Балун выступал, доклад был про память в Го

Была конференция, Владимир Балун выступал, доклад был про память в Го

а можете ссылку прислать, пожалуйста?

ну, такую базу я думаю тут понимают почти все) и причем тут ошибка, слайс по значению как раз таки передавать и стоит, просто мутировать его не надо, а надо возвращать новый слайс из функции/метода, как советуют разрабы языка. я спрашивал про тонкости работы с памятью скорее)

Да нет там ничего особенного, указатель на структуру весит 4/8 байт. Если структура с данными весит не сильно больше 4/8 байт, тогда выгодно передавать копию и не нужно её модифицировать, то вполне нормально передать по значению.

спасибо!

Ну банально то, что у тебя при аппенде может быть ошибка, если слайс по значению передать

А есть пример?

Да нет там ничего особенного, указатель на структуру весит 4/8 байт. Если структура с данными весит не сильно больше 4/8 байт, тогда выгодно передавать копию и не нужно её модифицировать, то вполне нормально передать по значению.

Так, а если 1000 байт весит, выгодно или нет?

Так, а если 1000 байт весит, выгодно или нет?

структура, которая весит 1 мб почти по мне так это лишняя нагрузка на память, если каждый раз копировать будем её

А есть пример?

Ну передавать слайс, выходить за капасити и не возвращать его, но это слишком банальный пример, согласен

Интервьюер ваш прав на все 146%. А вам стоит подучить чем отличается передача параметров по указателю и по значению и где применять то и другое. А уж заявление в стиле «потом отпрофайлим» это уж совсем красная лампочка, я б лично на этом месте с вами сразу попрощался. Так что это действительно кринж.

Тут мне кажется «правильно или не правильно» type of discussion Вопрос довольно странный, учитывая, что от места применения конкретного будет зависеть правильный ответ. А собеседующемуся - бесценный опыт! Когда задают подобный вопрос не городить сразу ответ, а вопросы задавать :)

Ну интервьюер даже базу не услышал, он услышал: «похер как передавать»

Именно так.

Тут мне кажется «правильно или не правильно» type of discussion Вопрос довольно странный, учитывая, что от места применения конкретного будет зависеть правильный ответ. А собеседующемуся - бесценный опыт! Когда задают подобный вопрос не городить сразу ответ, а вопросы задавать :)

Можно сделать скидку на то, что мы тут не знаем конкретную задачу, но не более того :))

Так, а если 1000 байт весит, выгодно или нет?

Слайс размером в 10тыс убегает на кучу, меньше - остаётся в стеке. 10 тыс элементов (не байт) в нижележащем массиве. Память на куче, указатель это всё не бесплатно, за этим всем должен ходить потом GC. Где-то должна быть граница, авторы провели её тут. Насколько она хороша - не знаю

И никто не увидел, что в ответе было: просто профайлить (промерять бечмарками.) Начались гадания. :)

Друзья, нигде не могу найти информацию есть ли какая то встроенная защита от коллизии в map, если есть как она работает?

Друзья, нигде не могу найти информацию есть ли какая то встроенная защита от коллизии в map, если есть как она работает?

Отвечает ChatGPT: Да, в языке Go есть встроенная защита от коллизий в map. Внутренний механизм работы map в Go включает в себя хэширование ключей, чтобы обеспечить быстрый доступ к значениям. Когда происходит коллизия (т.е. несколько ключей хэшируются в одно и то же значение), Go автоматически разрешает коллизии, используя метод цепочек (chaining) или открытое адресное хеширование (open addressing). В методе цепочек, если происходит коллизия, ключи помещаются в связанный список, связанный с этим хэшем. В методе открытое адресное хеширование происходит поиск следующего доступного слота в массиве, если возникает коллизия. Таким образом, встроенные механизмы хэширования и разрешения коллизий в map обеспечивают безопасное и эффективное использование этой структуры данных в языке Go.

Друзья, нигде не могу найти информацию есть ли какая то встроенная защита от коллизии в map, если есть как она работает?

Как мне думается любая хеш таблица должна уметь обрабатывать коллизию, и расширятся при большом количестве коллизий.

Друзья, нигде не могу найти информацию есть ли какая то встроенная защита от коллизии в map, если есть как она работает?

Там в принципе откидываются старшие биты хеша, и значения складываются в один бакет. Т.е. "коллизии" есть и постоянно

Отвечает ChatGPT: Да, в языке Go есть встроенная защита от коллизий в map. Внутренний механизм работы map в Go включает в себя хэширование ключей, чтобы обеспечить быстрый доступ к значениям. Когда происходит коллизия (т.е. несколько ключей хэшируются в одно и то же значение), Go автоматически разрешает коллизии, используя метод цепочек (chaining) или открытое адресное хеширование (open addressing). В методе цепочек, если происходит коллизия, ключи помещаются в связанный список, связанный с этим хэшем. В методе открытое адресное хеширование происходит поиск следующего доступного слота в массиве, если возникает коллизия. Таким образом, встроенные механизмы хэширования и разрешения коллизий в map обеспечивают безопасное и эффективное использование этой структуры данных в языке Go.

Открытой адресации в мапах го нет, насколько мне известно. Только чейнинг

Открытой адресации в мапах го нет, насколько мне известно. Только чейнинг

ну в стандартной нет, а sync.Map - это просто несколько хаков вокруг стандартного map

Ладно, если там используется чейнинг, что будет если один из бакетов переполнен, а хеш функция сгенерирует хеш для этого переполненого бакета, опять будет генерироваться новый хеш? А если он опять будет попадать в тот же бакет

Ладно, если там используется чейнинг, что будет если один из бакетов переполнен, а хеш функция сгенерирует хеш для этого переполненого бакета, опять будет генерироваться новый хеш? А если он опять будет попадать в тот же бакет

Создастся новый бакет и в него го рантайм положит новое значение, а из переполненного будет ссылка на новый

Если средний обьем бакета превысит допустимый, будет эвакуация - но это подробно описано в любой статье по мапам го

Ладно, если там используется чейнинг, что будет если один из бакетов переполнен, а хеш функция сгенерирует хеш для этого переполненого бакета, опять будет генерироваться новый хеш? А если он опять будет попадать в тот же бакет

После 6,5 коллизий в каждом бакете в среднем мапа перестраивается. Только один бакет переполниться не может, там равномерное распределение

После 6,5 коллизий в каждом бакете в среднем мапа перестраивается. Только один бакет переполниться не может, там равномерное распределение

А как именно механизм равного распределения работает ?