Пример из монги

db.collection(foo).find({document:_id}).sort({createdAt:1}).limit(1)

Где поле document связь с коллекцией Document

По такому же принципу можно и в SQL

Точняк

Спасибо

Доброго. Есть ли какие статьи для понимания работы микросервисов в nest и того как их формировать?

В той же доке есть все что нужно для этого. МС-ы не очень то и зависят от языка, по большей часть нужно понимать саму логику и 1000% подумать а нужно ли это вам.

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

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

Так что конкретно не понятно ? Или просто почитать/узнать про них нужно ?

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

"все сервисы будут знать друг о друг" => это правильно и не нужно боятся этого.

"Работа с пользователями" => когда нужен пользователь просто идем в users-ms, но обычно используют тот же JWT или как-то еще передают базовою инфу про пользователя.

"разбитие по доменам" => тут не так сложно, просто смотрим на проект, и прикидываем а что же можно разделить, после того как накидали примерный список сервисов, смотрим какие сервисы очень часто между собой будут общаться и решаем можем ли мы их логику соединить в едино или нет. Например мы могли бы разделить products и stock (склад) но это не правильно будет ибо товарам нужно быстро знать что там по остаткам.

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

С получением информации о пользователе понятно. А права проверяем на условном rules-ms?

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

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

Но разве вынесение связанности не основная идея?

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

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

А разве в этом случае подменить связь не будет проще?

А вы что собрались на ходу подменять сервисы или что в вашем понимание подмена ?