DB
Konstantin Belkin
У меня микросервисы на этом подходе написаны)
А зачем вам grpc в таком случае?
Size: a a a
2021 February 03
KB
Изучите подход monorepo
как транспорт между сервисами, когда требуется взаимодействие между ними
KB
А зачем вам grpc в таком случае?
многая логика вынесена в libs
DB
Konstantin Belkin
как транспорт между сервисами, когда требуется взаимодействие между ними
Так вроде бы вся суть монореп в том, что вы просто импортируете функцию и вызываете её
DB
Konstantin Belkin
многая логика вынесена в libs
И у вас вопрос изначально был - как делить? А что именно вы делить хотите?
KB
Так вроде бы вся суть монореп в том, что вы просто импортируете функцию и вызываете её
У меня скрипт выполняет ts-proto (это сокращает много работы так как один раз описав прото файл я получаю все что мне надо) далее я имплеменчу эти интерфейсы в микросервисах, и у меня получается что по сути каждый микросервис это 5-10 круд операций, но с другой стороны если 2-3 сервиса обьеденить, это будет ~20-30
KB
И эти сервисы слабо связаны между собой
DB
Konstantin Belkin
У меня скрипт выполняет ts-proto (это сокращает много работы так как один раз описав прото файл я получаю все что мне надо) далее я имплеменчу эти интерфейсы в микросервисах, и у меня получается что по сути каждый микросервис это 5-10 круд операций, но с другой стороны если 2-3 сервиса обьеденить, это будет ~20-30
В чём ваш вопрос заключается?
T
Так вроде бы вся суть монореп в том, что вы просто импортируете функцию и вызываете её
это не совсем так. это скорее суть монолита конкретно, а не монорепа
DB
это не совсем так. это скорее суть монолита конкретно, а не монорепа
Да, тут я действительно поплыл, вы правы
D
Бонджорно гаайаз, у меня возникли пару таких вопросов:
1) Где вы чаще всего обрабатываете выбрасываемые исключения, только в сервисах или в контроллерах?
2) Наа ошибки типо неверный логин, выброшенное исключение от бд и тд, какой код запроса вы возвраащаете 200 с ошибкой или же коды исключений с ошибкой?
1) Где вы чаще всего обрабатываете выбрасываемые исключения, только в сервисах или в контроллерах?
2) Наа ошибки типо неверный логин, выброшенное исключение от бд и тд, какой код запроса вы возвраащаете 200 с ошибкой или же коды исключений с ошибкой?
NM
Бонджорно гаайаз, у меня возникли пару таких вопросов:
1) Где вы чаще всего обрабатываете выбрасываемые исключения, только в сервисах или в контроллерах?
2) Наа ошибки типо неверный логин, выброшенное исключение от бд и тд, какой код запроса вы возвраащаете 200 с ошибкой или же коды исключений с ошибкой?
1) Где вы чаще всего обрабатываете выбрасываемые исключения, только в сервисах или в контроллерах?
2) Наа ошибки типо неверный логин, выброшенное исключение от бд и тд, какой код запроса вы возвраащаете 200 с ошибкой или же коды исключений с ошибкой?
1) в еррор фильтре, который вызывается в конце
2) любая ошибка в том числе пользователя это уже 4..
2) любая ошибка в том числе пользователя это уже 4..
NM
1) в еррор фильтре, который вызывается в конце
2) любая ошибка в том числе пользователя это уже 4..
2) любая ошибка в том числе пользователя это уже 4..
Касательно первого можно почитать тут: https://docs.nestjs.com/exception-filters
D
Касательно первого можно почитать тут: https://docs.nestjs.com/exception-filters
спасибо!
D
Да, уже использем такой подход, раньше я в контроллере обрабатывал исключения)
D
Но судя по Spting подходу обычно исключения из сервисов улетают и дальше либо в фильтре ловишь либо отдаешь клиенту)
D
Осталось только понять насколько верный подход с тем что у нас в целом пропали все коды ошибок, и каждое исключение приходит на клиент как 200 с ошибкой)))
Я конечно где - то читаал, что 200 это ок, ибо же до бека дошел заапрос, он его принял, знаачит все ок
Но это выглядит так тупо на фронте, когда ты ожидаешь явное исключение ибозапрос свалился, а приходит обычный ответ с ошибкой и ты обрабатываешь его уже не в catch а в try
Я конечно где - то читаал, что 200 это ок, ибо же до бека дошел заапрос, он его принял, знаачит все ок
Но это выглядит так тупо на фронте, когда ты ожидаешь явное исключение ибозапрос свалился, а приходит обычный ответ с ошибкой и ты обрабатываешь его уже не в catch а в try
NM
Осталось только понять насколько верный подход с тем что у нас в целом пропали все коды ошибок, и каждое исключение приходит на клиент как 200 с ошибкой)))
Я конечно где - то читаал, что 200 это ок, ибо же до бека дошел заапрос, он его принял, знаачит все ок
Но это выглядит так тупо на фронте, когда ты ожидаешь явное исключение ибозапрос свалился, а приходит обычный ответ с ошибкой и ты обрабатываешь его уже не в catch а в try
Я конечно где - то читаал, что 200 это ок, ибо же до бека дошел заапрос, он его принял, знаачит все ок
Но это выглядит так тупо на фронте, когда ты ожидаешь явное исключение ибозапрос свалился, а приходит обычный ответ с ошибкой и ты обрабатываешь его уже не в catch а в try
400 ошибки подразумевают что запрос пришел, бек всё обработал нормально, но клиент где-то накосячил
D
400 ошибки подразумевают что запрос пришел, бек всё обработал нормально, но клиент где-то накосячил
а если не клиент накосячил, а условно на беке не верный запрос к бд
D
или бизнес логика выкинула исключение?