в микросервисах вообще теряется понятие энтити, потому что нет этого самого энтити

Связь где? Пофиг на энтити

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

Он ничего не пропускает. Просто кому-то следовало упороться кем-нить вроде эванса.

Особенно если этот кто-то пытается строить что-то большое.

Блин, жёстко тут у вас однако)

Андрюх, дай человеку потешить ЧСВ, пропусти мимо ушей/глаз))

Очередной слив... взррслые-то есть. Какой к чёрту чсв?

Да я вообще не в теме, я только учусь)

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

Микросевис это типа докера?

Ты не поверишь... прочесть стоит про баундед контекст, который ты заюзал в весьма сомнителтном контексте. Если ещё конструктивнее https://www.ozon.ru/context/detail/id/5497184/

вам кстати привели пример, где bounded context не сработал

Начни с этогл

если вы не согласны, поделитесь сокровенным знанием

вам кстати привели пример, где bounded context не сработал

Он сработал бы и вполне успешно

Давай от обратного:что ему бы помешало сработать?

зачем мне обратное, расскажи в чем он сработал

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

Во всем. Полностью изолированные контексты за общей аркестрацией. Изи. Еслм захочешь предметно и конструктивно - велкам. Если снова сливы в духе чсв, можно идти работать

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

стейтом чего? что такое доменная модель?

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

сколько контекстов ты здесь видешь7

тебе обрисовали, нет?

вводная не менялась, все тот же случай

на вопрос ответь

он рассказывает про bounded context и пропускает факт, что многие системы имеют разное представление об объекте, например, кастомер для CRM подсистемы - это набор контактных данных + история общения, кастомер для пеймент подсистемы - payment token + история платежей, и так далее

ясна.

у меня плохие новости: это не он пропускает.

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

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

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

customers | discuss | payments в дискусе нет связи с пользователем. Есть связь с отправителем\получателем и сообщенькой. Если айдишники участника совпадают с пользователем - изи катка. Если нет, рядом оркестрация, которая предоставляет реляцию. что меняется во взаимодействии с платежами - вопрос риторический. Выше тебе Богдан накинул за Udi, посмотри на досуге

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

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

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

да уже до меня 2 поколения эти картинки рисовали...) когда ж дойдёт)

Эванс, Вернон, тот же Udi... бери, читай\смотри, практикуй и будет понимание, как вопрос закрывается. Нет жешь, надо обязательно поспорить. Ради чего только :)

Народ Как пагинацию сделать? Вот такая структура:

{ "total": 200, "per_page": 15, "current_page": 1, "last_page": 14, "next_page_url": "https://vuetable.ratiw.net/api/users?page=2", "prev_page_url": null, "from": 1, "to": 15, "data": [ {...}, {...} //... ] }

need help

объявил тип type Cities []City

как теперь по нему итерироваться?

обратно он не кастуется в массив

аа все, я забыл звездочку

спс

у меня был указатель на тот тип

need help

https://play.golang.org/p/KnwHfvUMmJQ

http://sweetohm.net/article/go-interfaces.en.html

Надоело писать мне вообщем роуты Есть вот у меня интерфейс типа type Controller interface { Get(id string) (interface{}, error) } и как бы у меня много моделек, которые реализуют этот интерфейс(пустой интерфейс потому что разные структуры) Так вот есть у меня роут на Get

func GetOneNote(w http.ResponseWriter, r *http.Request) { vars := mux.Vars(r) id := vars["id"] note_id := vars["note_id"] note, err := db.Note{}.Get(id, note_id) if err != nil { log.Println("err is ", err) returnLoginFailed(w) return } json.NewEncoder(w).Encode(map[string]interface{}{ "success": "success", "note": note, }) }

роуты такие все одинаковые

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

Get(id)

вопрос как оптимизировать, написать один роут и его использовать много раз, или лучше просто нагенерировать роутов

через go generate

?

странно что context.WithTimeout и прочие не принимают nil как parentContext.. есть причина тому что разрабы пришли именно к такому, опасному (becase memory access violation), интерфейсу нежели вставить банальную if ctx == nil {ctx = Background()}?

Так А пагинацию данных делал кто?

Так А пагинацию данных делал кто?

в чём вопрос?

Привет, кто работал с mgo? подскажите есть ли возможность получить objectid созданного документа при Insert?

Народ Как пагинацию сделать? Вот такая структура:

В чем проблема берешь задаешь skip limit. И отдаешь

Привет, кто работал с mgo? подскажите есть ли возможность получить objectid созданного документа при Insert?

там вроде есть функция, returnlastid что ли

там вроде есть функция, returnlastid что ли

Э, не, так нельзя. Вдруг между моим insert и моим запросом returnlastid кто-то еще успеет что-то инсертнуть

Э, не, так нельзя. Вдруг между моим insert и моим запросом returnlastid кто-то еще успеет что-то инсертнуть

типичная проблема кэширования части динамического массива. Проблема довольно сложная, но в принципе решается так: § 1. в запросе на чанк списка указываются параметры: limit, sort и after. Где limit это максимальный размер чанка, sort это поле, по которому мы сортируем список и after - значение того-же типа что и поле, по которому сортируем, которое указывает на последний элемент который у нас есть. § 1.1. при первом запросе, скажем первых 10 элементов, after можно не указывать. § 1.2. если поле по которому мы сортируем - не уникальное, тогда нужно помимо значения after указывать index нашего последнего элемента § 2. в ответе отдаём некий revision number (это может быть уникальное число или UUID идентификатор), который указывает на версию списка. § 3. revision обязательно должна быть обновлена в случае обновления массива (удаление, перемещение, добавление, любые мутации) § 4. по revision мы определяем, актуален ли cache который мы уже имеем на стороне клиента. Если ревизии на клиенте и в очередном ответе сервера рознятся - нужно удалять все прежде закэшированные чанки массива на клиенте поскольку они уже не актуальны § 4.1. если речь идёт об infinite scroll'е то можно после удаления имеющихся страниц cache'а снова загрузить -1 и +1 страницы относительно актуальной страницы для улучшения UX

давно тебя не было, братан. ты каждое утро?

так надолго пропадет, начнем волноваться хД

Доброго времени суток. Где можно найти примеры хороших веб-серверов? Что б можно было посмотреть как нормальные люди делают)

Доброго времени суток. Где можно найти примеры хороших веб-серверов? Что б можно было посмотреть как нормальные люди делают)

https://github.com/nginx/nginx

https://github.com/nginx/nginx

Видно я не то спросил? я имел ввиду рест-сервер на го

ща тебе swagger прорекламируют

rest-server? что за термин такой?

rest-server? что за термин такой?

А как правильно?

rest api framework? хм

rest-service или http-server

Тогда думаю я имею ввиду сервис.

https://nordicapis.com/7-frameworks-to-build-a-rest-api-in-go/

первая ссылка гугле)