понял спасибо, пойду читать доку 👍

спасибо за ссылку

Но не факт что конкретно копродукты - самое простое решение

ну вот, если не считать, позвученной проблемы с патернматчингом, в остальном мне нравится и сериализация/десериализация нужная мне пишется легко и один и раз и объявление "суммы типов" получается лаконичным. Но если есть решение попроще то я бы посмотрел и в его сторону тоже.

Как вариант решать вашу задачу в каждом обработчике матчить по его типу, и тогда полноту можно сделать подняв неполный матчинг в ошибки при помощи опции компиялтора "-Xfatal-warnings" и , тогда, вероятно у вас не будет необходимости в одном большом матче который все будут дергать каждый раз

circe умеет выводить кодеки для иерархий сразу.

Ну для этого надо классы унаследовать от sealed trait или я не понимаю мысль?

Да, правильно. На сервис можно обьявить  sealed trait BuzzinezServiceResponse и написать туда все ответы.

Да, собственно, что я пытаюсь решить. Этот набор кейс классов используется в разных методах, но ни один из методов не возвращает/принимает полный набор, каждый только часть. Где-то условно только Foo и Bar, где-то Foo и Qoo. Хотелось это ограничение выразить в типах. Первое что пришло в голову это завести трейтов по количеству комбинация и кейс классы унаследовать от них. но мне эта идея не нравится, так как эти трейты они инородны данным получаются. Что нравится чуть больше - это сделать несколько sealed trait и унаследовать от них классы контейнеры - но тогда руками писать много однотипного кода. Вот и пытаюсь придумать что-нибудь получше. А может и зря пытаюсь. :)

есть ещё один паттерн через with, но вам придется переворачивать копродукт в продукт и на оборот. т.е. вам нужно сделать trait CouldBeFoo{ def hasFoo: Option[Foo]}, trait CouldBeBar{ def hasBar: Option[Bar]}, trait CouldBeBaz{ def hasBaz: Option[Baz]}, тогда можно в CouldBeFoo with CouldBeBar with CouldBeBaz, но это уже переделка копродукта. Но вообще, шарить ответы между сервисами это идея которая производит некоторые проблемы, в частности вот эту.

Спасибо за идею, подумаю и в эту сторону тоже. Да, согласен, что ситуация получилась так себе :( но как ее красиво решить без дубликации пока не придумали - у нас фронту удобнее получать в одном случае определенную часть через WebSocket , а в другом дергать синхронный GET. К счастью это все запросы к одному сервису :)

Ну, можно ещё действительно отнаследоватся от нескольких силд трейтов в каком - то виде может оказатся проще всего. Circe не должна упасть на этом.

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

Спасибо за идеи и советы, если пойму, что развожу дичь на ровном месте то остановлюясь на несколкьих sealed trait и успокоюсь на этом :) если повезет, то в ледующий раз подобная пакость появится когда уже выйдет Scala 3 :)

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

@sugakandrey
Андрей Сугак, ну почини инкрементальную сборку на ЕАПе пожалуйста, а то птостоянно крешится в рантайме...
https://youtrack.jetbrains.com/issue/SCL-18301
https://youtrack.jetbrains.com/issue/SCL-18302

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

Привет. Мб кто знает почему от testcontainers KafkaContainer может сыпать ошибкой LEADER_NOT_AVAILABLE на попытки чтения и записи . Там же под капотом все что нужно есть, странно что оно не сетает лидера...

Не знаю, но в дефолтном KafkaDocker из https://izumi.7mind.io/distage/distage-framework-docker все работает