чорд, не сдержался

Никак не могу понять, в чем разница между Serve и ListenAndServe?

Никак не могу понять, в чем разница между Serve и ListenAndServe?

внуть заглянул?

Никак не могу понять, в чем разница между Serve и ListenAndServe?

Лисн и серв принимает стринг в виде адреса, а серв принимает стректуру листенера

Это я понял

А существенная разница в чем?

У серва указано что он создает горутину под каждый запрос

а listenAndServe как поступает?

внутрь загляни. это один и тот же код

То есть разницы никакой?

функционально никакой

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

Понял

Кстати, как работает writeTimeout?

на самом деле - листенера, передающегося отдельно, можно замокать

Поставил writeTimeout 10 sec

Сделал задержку в хендере запроса на 15 сек

Но соединение не разорвалось

Клиент дождался 15 секунд и получил ответ

Почему так?

writeTimeout - это таймаут на операцию записи в сокет

он случится может только если буфер сокета переполнен

Значит неправильно понял смысл

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

А ReadTimeout

Что делает он в таком случае?

а вот тут - данных в сокете не образовалось за указанное время

То есть, например, у клиента медленная сеть и тело запроса долго доходит до клиента?

И в таком случае сервер закрывает соединение с клиентом?

ага

на самом деле - тут тоже довольно специальные условия нужны

клиент отправляет данные пакетами

и в современных сетях медленно - это не медленно доставляемые пакеты, а большие интервалы между пакетами

на что там read timeout действует - я не помню

А есть ли существенный смысл ставить write read таймауты?

на "прочесть целиком" или на "прочесть хоть кусочек"

ну - какие-то надо ставить

Ого!

Ого!

?

?

Щорс же банил его) видимо, отмотал своё

а, это человек-закройзасобойфорточку?

Про форточку не помню)

А ну - который заходил в чат и выходил постоянно

Ага, он самый

чату, imo, нужен тамбур %)

чату, imo, нужен тамбур %)

Так он итак есть: https://t.me/goflood

Когда нужно начинать делить прогу на микросервисы, и до каких пор достаточно корутин? Есть ли какой нибудь менеджер горутин?

Когда нужно начинать делить прогу на микросервисы, и до каких пор достаточно корутин? Есть ли какой нибудь менеджер горутин?

пока тормозить не начнет

вообще не от этого зависит

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

Не надо делать микросервисы ради микросервисов

Когда нужно начинать делить прогу на микросервисы, и до каких пор достаточно корутин? Есть ли какой нибудь менеджер горутин?

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

ни у кого нет норм примера, как писать в unix socket и слушать с него респонс? Я уже всю голову сломал((( sock := `/tmp/geth.ipc` conn, _ := net.Dial("unix", sock) method := `{...}\n` num, err := conn.Write([]byte(method)) Write же возвращает количество записанных byte

На этапе проектирования каждой итерации/спринта или всего проекта?

на этапе разработки архитектуры

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

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

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

Вот хороший пример такой статьи

The article by Paul Dix calls “The Decomposable Monolith: Long Live the Monolith, Long Live Services!” Code examples are available but without a code highlighting ? #architecture #development #microservices https://www.influxdata.com/blog/decomposable-monolith-long-live-monolith-long-live-services/

Надеюсь ссылка на другой канал не противоречит правилам чата

ERROR: S client not available

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

так и я советую то же самое! монолит существенно дешевле в разработке, так что на этапе MVP лучше микросервисы отложить. но вот "вытащим из монолита изолированный сервис" - это утопия.

так и я советую то же самое! монолит существенно дешевле в разработке, так что на этапе MVP лучше микросервисы отложить. но вот "вытащим из монолита изолированный сервис" - это утопия.

Не правда, я недавно побил монолит на несколько подпрограмм, легче жить стало

вам просто повезло, коллега

не надо личный опыт абсолютизировать

вам просто повезло, коллега

Возможно ☺️

не надо личный опыт абсолютизировать

Как правило мвп пиши GOвнокод, потом, если проект взлетит подопрете это все костылями ?

да, и этот подход оправдан

не все, правда, готовы в этой содомии участвовать

Веками отработанная тактика ?

Пример Amazon говорит что даже в огромном монолите это возможно https://thenewstack.io/led-amazon-microservices-architecture/

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

“We went through the code, and pulled out functional units that served a single purpose, and we wrapped those with a web service interface,” he said. For example, there was a single service that rendered the “Buy” button on the retailer’s product detail pages. Another had the function of calculating the correct tax during checkout.

Цитата от Rob Brigham

Кто как хочет так и... а потом что-то становится мейнстримом

“We went through the code, and pulled out functional units that served a single purpose, and we wrapped those with a web service interface,” he said. For example, there was a single service that rendered the “Buy” button on the retailer’s product detail pages. Another had the function of calculating the correct tax during checkout.

это ровно то, о чем я

Аналогично! Видимо у нас полное согласие )

Господа, есть интересная задача. Есть две реляции в БД: условно реляция A и реляция B. Нужно написать конфигурационный файлик, который бы "маппил" A.columnX_1 -> B.columnZ_2 (т.е. каждый атрибут реляции А на атрибут реляции B) Из Go этот файлик прочитать и на основании этих данных строить SQL-запросы. Если кто сталкивался с подобным таском и подскажет, буду благодарен.

А конфигурационный файлик прям везде разный будет?

Нет, структура таблиц, по-идее. меняться не будет

Суть этого таска - обновить колонки в реляции B на основании данных в A.

а?!

Это очень краткий вопрос, честно, не совсем понял "посыла". Не могли бы Вы чуть-чуть развернутее, пожалуйста?

Я так думаю, что подразумевается, что ничего не понятно про "обновление колонок на основании данных". Можно тоже чуть чуть развёрнутее? Update a set col1 = b.col2 ?

Странный таск...

Или вообще имена колонкам поменять?)

А по моему все просто, надо просто внимательно читать что написал автор

Берем из файла настроек структуру и из базы а в соответсвии с этой структурой переносим в базу б данные

Берем из файла настроек структуру и из базы а в соответсвии с этой структурой переносим в базу б данные

>Из Go этот файлик прочитать и на основании этих данных строить SQL-запросы. Это попахивает тем, что автор чего-то не договаривает

Ну тогда вообще { "tableX.name": "tableY.first_name", ... } Я сделаль