Спасибо, более менее понятно. Но есть еще один вопрос, а если запрос к БД сложный где нужны джоины и офсеты с лимитами.
Простой пример у нас есть корзина и есть товары как отдельные микросервисы. У меня в корзине 5000 товаров. Я должен на веб-странице в корзине отобразить 3 страницу и показать только те товары, что есть в наличии.
Каким образом я тут сделаю связь по апи? Ну то есть, если я в запрос отправлю с ИД товаров в корзине на 3 странице (например 20 штук), то я не смогу учесть есть товар в наличии или нет, и соответственно информация будет отображена неверно. А если я запрошу ИД товаров из магазина соответствующие ИД товарам в корзине, то мне придется пересылать по апи 5000 ИД из корзины, чтобы найти соответствующие товары. А если данных еще больше и сложнее? Я вижу тут проблемы с производительностью.
Если взять даже пример на питоне. Есть у меня например интернет магазин, есть микросервис по работе с корзиной. А есть микросервис по отправке уведомлений. Отправляя уведомления мне в любом случае понадобятся данные представленные в корзине. Если это разные БД то каким образом я тогда должен их связывать? Через АПИ?
Про миграции тоже не понял. Когда БД общая - ты из накатил из любой точки и все. Но если человек разрабатывающий микросервис по работе с корзиной внесет изменения в БД то эти изменения в любом случае коснутся и работы микросервиса по работе с уведомлениями и там придется переписывать код. Так какие де тогда преимущества в итоге чтобы использовать раздельные БД?
Есть у меня интернет магазин. Я решил разработать приложение для телефона. Для приложения для телефона мне нужно разработать отдельное апи. Каким образом тут БД может быть не общая? Да можно было бы вынести апи для интернет магазина и приложения в отдельных сервис, но тогда получается тяжелое апи для работы сразу с двумя сущносями, которые слабо зависимы. Даже если разделить это на два апи, то БД у них все равно одна будет. Что тут можно разделить?
Честно говоря так и не понял (возможно статья плохо раскрывает преимущества) какие преимущества у данного подхода. Но вот разработчикам, работающим в команде (а так же новым разрабам, пришедшим на проект), придется изучать дополнительную библиотеку и как по мне это скорее минус.
Конечно уважение что выпустили игру. НО.
Графика — просто стыдоба. Очень печально, что люди до сих пор считают то, что вы нарисовали графикой, еще и «очень красивой и красочной».
Спасибо, более менее понятно. Но есть еще один вопрос, а если запрос к БД сложный где нужны джоины и офсеты с лимитами.
Простой пример у нас есть корзина и есть товары как отдельные микросервисы.
У меня в корзине 5000 товаров. Я должен на веб-странице в корзине отобразить 3 страницу и показать только те товары, что есть в наличии.
Каким образом я тут сделаю связь по апи? Ну то есть, если я в запрос отправлю с ИД товаров в корзине на 3 странице (например 20 штук), то я не смогу учесть есть товар в наличии или нет, и соответственно информация будет отображена неверно. А если я запрошу ИД товаров из магазина соответствующие ИД товарам в корзине, то мне придется пересылать по апи 5000 ИД из корзины, чтобы найти соответствующие товары. А если данных еще больше и сложнее? Я вижу тут проблемы с производительностью.
Кто может пояснить подробнее по 5 антипаттерну?
Если взять даже пример на питоне. Есть у меня например интернет магазин, есть микросервис по работе с корзиной. А есть микросервис по отправке уведомлений. Отправляя уведомления мне в любом случае понадобятся данные представленные в корзине. Если это разные БД то каким образом я тогда должен их связывать? Через АПИ?
Про миграции тоже не понял. Когда БД общая - ты из накатил из любой точки и все. Но если человек разрабатывающий микросервис по работе с корзиной внесет изменения в БД то эти изменения в любом случае коснутся и работы микросервиса по работе с уведомлениями и там придется переписывать код. Так какие де тогда преимущества в итоге чтобы использовать раздельные БД?
Есть у меня интернет магазин. Я решил разработать приложение для телефона. Для приложения для телефона мне нужно разработать отдельное апи. Каким образом тут БД может быть не общая? Да можно было бы вынести апи для интернет магазина и приложения в отдельных сервис, но тогда получается тяжелое апи для работы сразу с двумя сущносями, которые слабо зависимы. Даже если разделить это на два апи, то БД у них все равно одна будет. Что тут можно разделить?
Честно говоря так и не понял (возможно статья плохо раскрывает преимущества) какие преимущества у данного подхода. Но вот разработчикам, работающим в команде (а так же новым разрабам, пришедшим на проект), придется изучать дополнительную библиотеку и как по мне это скорее минус.
Графика — просто стыдоба. Очень печально, что люди до сих пор считают то, что вы нарисовали графикой, еще и «очень красивой и красочной».