Комментарии 6
не так уж и много вариантов имеется. Всеми заброшенный jinterface и новая библиотека encon
… или таки поднять уже брокер, хотя бы тот же RabbitMQ, и слать сообщения через него. Надежнее будет.
Так получится ещё одна дополнительная сущность в виде гномика кролика. Её нужно так же саппортить, деплоить, реплецировать, чёт туда править… это ж усложнение системы.
Наверн, если кролик уже в системе, то это имеет смысл, а если нужно просто скрестить Erlang/Elixir с Java (например, ты мигрируешь из одного в другое) — то encon тут супер подходит
Наверн, если кролик уже в системе, то это имеет смысл, а если нужно просто скрестить Erlang/Elixir с Java (например, ты мигрируешь из одного в другое) — то encon тут супер подходит
Кролик просто замечательно работает из коробки, да и в docker-образе есть, так что для предположительной миграции, когда не нужна производительность и все такое, он как раз предпочтительнее — работает, есть не просит, сообщения гоняет, кода для этого требуется… хм… меньше, чем в приведенных примерах. Если со Spring, так и вообще… А если речь идет о продакшене, где данных много, то тем более промежуточное звено в виде кроля прямо показано, ибо изолирует одно от второго.
В общем не зря таких библиотек практически нет, у них область применения почти отсутствует.
В общем не зря таких библиотек практически нет, у них область применения почти отсутствует.
Во-первых, у либы из статьи тоже есть spring-интеграция (вот, например, эхо сервер с клиентом), причем с готовым databinding'ом а-ля Jackson, ток для Erlang'овских термов.
Ну а во-вторых, каким бы кролик замечательным (сам им пользуюсь в одном из проектов, вот прям щаз) ни был, это всё равно дополнительный инфраструктурный элемент, от которого хотелось бы избавиться, если есть возможность, так как он тоже имеет свои накладные расходы и, повторюсь, затраты на поддержку, ибо докерный образ кто-то тоже должен поднять, а где хранить креды к кролику? «А настройте мне вот тут эксчейндж», «У меня была очередь и теперь её нет», «А кто нибудь это уже синькал со стейджем?» — и многие многие другие радости. Иными словами — это не бесплатно.
Тут же — нативное общение для Эрланга + доп обвязочки (databinding, spring интеграция) для того что бы и со стороны Java это выглядело более-менее нативно и твой мейлбокс походил на какой нибудь спринговый контроллер.
Лично для себя, я вижу область применения такой либы, когда для тебя Erlang/Elixir — это шина, клей твоей системы с парой-тройкой инфраструктурных сервисов внутри. BEAM VM держит кучу соединений, на нём приятно писать какую нибудь маршрутизацию, балансировку, сервис дескавери, распределенный ин-мемори кэш.
В общем замена: nginx, redis, RabbitMQ, etcd сервисов и Zuul, Eureka (это из Spring Cloud)… ну Apigee для бедных, кароч)
Ну а во-вторых, каким бы кролик замечательным (сам им пользуюсь в одном из проектов, вот прям щаз) ни был, это всё равно дополнительный инфраструктурный элемент, от которого хотелось бы избавиться, если есть возможность, так как он тоже имеет свои накладные расходы и, повторюсь, затраты на поддержку, ибо докерный образ кто-то тоже должен поднять, а где хранить креды к кролику? «А настройте мне вот тут эксчейндж», «У меня была очередь и теперь её нет», «А кто нибудь это уже синькал со стейджем?» — и многие многие другие радости. Иными словами — это не бесплатно.
Тут же — нативное общение для Эрланга + доп обвязочки (databinding, spring интеграция) для того что бы и со стороны Java это выглядело более-менее нативно и твой мейлбокс походил на какой нибудь спринговый контроллер.
Лично для себя, я вижу область применения такой либы, когда для тебя Erlang/Elixir — это шина, клей твоей системы с парой-тройкой инфраструктурных сервисов внутри. BEAM VM держит кучу соединений, на нём приятно писать какую нибудь маршрутизацию, балансировку, сервис дескавери, распределенный ин-мемори кэш.
В общем замена: nginx, redis, RabbitMQ, etcd сервисов и Zuul, Eureka (это из Spring Cloud)… ну Apigee для бедных, кароч)
Не совсем понятно как быть с типами — maps,proplists. Либо когда сообщение необходимо отправить одним из типов:
Опять же maps:
ну и далее в любом порядке. В README этого не нашел.
{ok, <<"Result">>}{ok, "Result"}Опять же maps:
#{key => value}#{"key" => <<"value">>}ну и далее в любом порядке. В README этого не нашел.
Там на сайте есть новая статья, в которой есть раздел с маппингом Java2Erlang. Но не написано что есть ещё класс со статическими хелп-функциями — Erlang
Конкретно твои примеры выглядят так:
import static io.appulse.encon.terms.Erlang.atom;
import static io.appulse.encon.terms.Erlang.bstring;
import static io.appulse.encon.terms.Erlang.map;
import static io.appulse.encon.terms.Erlang.string;
import static io.appulse.encon.terms.Erlang.tuple;
import io.appulse.encon.terms.ErlangTerm;
// {ok, <<"Result">>}
ErlangTerm message1 = tuple(atom("ok"), bstring("Result"));
// {ok, "Result"}
ErlangTerm message2 = tuple(atom("ok"), string("Result"));
// #{key => value}
ErlangTerm message3 = map(atom("key"), atom("value"));
// #{"key" => <<"value">>}
ErlangTerm message4 = map(string("key"), bstring("value"));С мапами, как в Guava хелпер был — они идут vararg массивом, нечётный элемент — ключ, чётный — значение (что и видно в примере выше).
Никто не мешает через конструктор всё создать, но на мой вкус тут статические функции лаконичнее выглядят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из Erlang/Elixir в Java и обратно. Приключение на 20 минут