Поделитесь своими мыслями и опытом, как правильно и почему (удобнее поддерживать) обмениваться данными в микросервисах. Тут вопрос не о способе передачи, у меня тут очереди, а вопрос в том, что передавать, набор объектов или массив строк?
Предположим есть сервис А, и он умеет хранить и обрабатывать транзакции (оплата например книжек). В этом сервисе есть модель Transaction и соответственно в базе таблица. И есть другой сервис B. В этом сервисе происходит только отображение транзакций из модуля A. То есть модуль B обращается курл в модуль А, тот ему должен отдать список транзакций.
Вопрос в том, как именно отдать список транзакций -
1) Массив строк (json)
2) Массив объектов
Допустим мы отдаем массив объектов. Какие плюсы?
- Получили массив объектов, записали в провайдер данных и сразу рендерим в грид.
- Мы можем проверять по типу интерфеса объектов достоверность нужных данных.
Из минусов -
- Нужно таскать непонятные объекты.
- Если в объекте, что-то меняется на стороне сервиса А, то в сервисе B может сломаться код.
Второй вариант, мы отдаем массив строк.
Нам нужно как-то это дело карасиво преобразовать в модели.
Мы типа такие смотрим, какие данные приходят, создаем на основе них класс с нужными полями и методами валидации, записываем все туда (делаем базовый метод load, validate), делаем сервис который работает с этими моделями (entity) и дергаем его из нашего контроллера.
Звучит не плохо. Но больше кода и действий.
Плюсы
- Мы создаем свою структуру в сервисе B, которая описывает то с чем этот сервис будет работать (свои модельки для заполнения и валидации пришедших данных). Это позволяет немного абстрагироваться от сервиса А.
Минусы
- Много кода, так как по сути у нас есть в сервисе А модель описывающая Transaction и теперь нам надо создать в сервисе B такую же модель для того чтобы сервис B понимал с чем он вообще работает (ну и чтобы вообще все это дело запихать в датапровайдер с пагинацией, фильтрами и всем прочим нужным).
А как вообще правильно делать пагинацию в таком случае? В сервисе B через параметры GET принимать номер страницы и передавать все это дело в сервис А, где делать нужную выборку и возвращать в B? Или тянуть из A все данные и тут их пихатьв. провайдер с пагинацией? Наверно лучше передавать в сервис А данные для пагинации и брать от туда только нужное сразу.
я ничего не понял
что означает минус "Нужно таскать непонятные объекты"? кому непонятные? почему непонятные?
Если в объекте, что-то меняется на стороне сервиса А, то в сервисе B может сломаться код. офигеть. а если в "строке" что-то поменяется, то код, который парсит эту строку, не поломается? с чего бы это?
А как вообще правильно делать пагинацию в таком случае?
Сервис A и B знают только про контракт. Что там внутри творится их не волнует. Задача любого сервиса правильно создать модель на основе контракта и отдать ее или обработать.
бред какой-то, в любом случае если меняется структура данных придется изменять и адаптер/обработчик.
обращаться к своему же сайту через curl - тупо и не эффективно, проще перенаправлять запросы к локальным сервисам/контроллерам через роутинг.
проще и удобнее передавать объекты, см. реализацию soap в php, можешь ничего не выдумывать и использовать устоявшуюся бизнес практику.
по поводу сервисов, см. шаблон проектирования strategy - меняется не модель данных, а способ их отображения.
те же яйца, но вид сбоку. запросы от этого быстрее не пойдут.
и насколько она востребована в двадцать первом
судя по тому что все крупные бизнес сервисы на soap/wsdl -google play, spotify и т.д. то он живее всех живых. Как по мне так проще автоматом генерить классы для soap запросов, чем создавать те же дата мапперы вручную для json
не торопись с ответом, подумай
почитай про что вопрос (подсказка - про микросервисы)
почитай про то как общаются микросервисы друг с другом (подсказка: по сети)
перечитай свой ответ (подсказка: про бред)
FanatPHP, одно дело когда к этому подталкивает сама структура/расположение данных, а другое когда ты плодишь подобные сервисы в рамках одного сервера. назови хотя бы один довод чем такой подход лучше описанного мной варианта с роутингом.
Антон Шаманов, бизнес очень инертен, потому и использует даже совершенно идиотские технологии типа SOAP/WSDL. По факту же разного рода REST и прочие JSON-RPC дают всё то же самое намного проще и удобнее.
Ну вообще соглашусь.
Джейсону конечно иногда не хватает строгости WSDL.
И на длинной дистанции действительно можно предпочесть более строкий и предсказуемый SOAP, в который уже зашиты правила валидации.
Но уж больно муторно их писать. проще плюнуть и написать на пхп. Да и в большинстве случаев это перебор.
Антон Шаманов, я рекомендую вернуться в 2005 год и пострадать там. Протокол был придуман во времена безумной моды на XML в каждое отверстие, в результате каждый реализовывал как левой пятке приспичило, и потребовались годы на то, чтобы SOAP оброс WS-I/WS-A и стал сколько-нибудь универсальным. И то, по любому чиху разваливается.
По моему опыту бизнес намного более охотно реализует интеграции на кастомных вендор-зависимых протоколах либо на промышленно-стандартных, чем на SOAP. А если говорить не о кроваых ынтерпрайзах, то за пределами заумных бизнесов популярность у SOAP вообще ниже плинтуса - его просто никто не использует. Потому что не нужен. Рыночек порешал.
потребовались годы на то, чтобы SOAP оброс WS-I/WS-A и стал сколько-нибудь универсальным
JSON-RPC появился в те же годы. тебя не смущает что этот сайт на диалекте xml?))
за пределами заумных бизнесов
я как бэ не сайтами визитками занимаюсь))
кроме исторической справки, которую никто не просил, я никаких доводов не вижу. лично мне импонирует четкое описание формата данных, из минусов разве что размер)
Антон Шаманов, я не визитками занимаюсь, у нас основные клиенты - банки. У нас для некоторых сервисов есть WS-интеграции, но исключительно по причине наличия таких клиентов, и эти интеграции по функционалу регулярно отстают других протоколов. А для некоторых сервисов никто WS не делал и никогда не будет делать. Ибо устаревшая бесполезная хрень, можно просто клиенту говорить "мы это не поддерживаем" и клиент прекрасно это пережёвывает.
shurshur, rest и rpc это тоже ws как бэ)) и опять одна вода, ты можешь внятно сказать че те конкретно не нравится? или в чем заключается это отставание?
Антон Шаманов, ну у нас в платформе WS называются исключительно SOAP-сервисы, я по привычке.
Мне не нравится что уже никому не нужные отмирающие понты из начала нулевых выдают за что-то невероятное. Это в целом приемлемый метод взаимодействия, даже не самый плохой, но его время безнадёжно ушло. В конце концов, в наше время можно и на коболе писать программы, никто не мешает, они даже работать будут, но смысл?
Отставание - это когда новый функционал добавляется в собственный протокол, но в версию протокола на базе SOAP не добавляется.
Антон Шаманов, что такого в Landrover, чего нет в УАЗ? Вот только Landrover банально удобнее и комфортнее.
Ещё раз: SOAP - это не самая плохая вещь, просто ничего космического при куче очевидных недостатков, первый из которых - многоэтажный XML с неймспейсами - бездарное решение в эпоху моды на XML в каждом отверстии.
У вас 1 сервис должен быть который работает с сущностями транзакций (получение, отображение итп).
Вы занимаетесь ерундой, наверное книжку умную прочитали или доклад про микросервисы авито на ютуб посмотрели..
ну так он у него и есть, "1 сервис"
но он же не в вакууме работает, не сам себе транзакции показывает? наверное, их иногда надо кому-нибудь еще показать?
