AS
А есть где-то дока как это сделать?
Size: a a a
2018 November 03
AS
Вполне хороший вариант
AM
В Phoenix совсем не гибкие сокеты, нужно что-то своё написать в транспорт - пляши с бубном. На последний феникс перейти пока не можем, там все перелопатили в 1.4 :) Типа для упрощения написания своих транспортов как-раз, а на деле даже свой путь в роутинге нельзя прибить, только префикс если (гвоздями прибитый /websocket или /longpoll) или свой хандлер для ковбоя впиливать
DR
В Phoenix совсем не гибкие сокеты, нужно что-то своё написать в транспорт - пляши с бубном. На последний феникс перейти пока не можем, там все перелопатили в 1.4 :) Типа для упрощения написания своих транспортов как-раз, а на деле даже свой путь в роутинге нельзя прибить, только префикс если (гвоздями прибитый /websocket или /longpoll) или свой хандлер для ковбоя впиливать
Ну да, сами сокеты там не гибкие. Я имел ввиду http часть.
DR
Т.е. расчёт на то, чтобы использовать через phoenix.js
AM
Ещё бесят их сабскрипшны - клиент обязан подписываться на топики, чтобы эвенты получать. Подписать со стороны сервера - нельзя из коробки
AM
Как-раз из-за их phoenix.js
AS
Хорошо, а если на клиенте у вас не феникс и нужно ws? Тогда только ручками самому пилить, готового решения нет. Но это все развитие языка и оно вроде происходит
AM
При куче каналов - клиенты тупо захлёбываются на хреновом инете при джойнах. В итоге перепилили все, теперь после коннекта клиенты сразу начинают эвенты получать, подписки на стороне сервера осуществляются.
AM
Хорошо, а если на клиенте у вас не феникс и нужно ws? Тогда только ручками самому пилить, готового решения нет. Но это все развитие языка и оно вроде происходит
У нас 3 клиента - web/android/ios, везде свою реализацию написали и всё гуд
AS
Свою реализацию клиента для Phoenix channel? Ну тоже вариант.
AM
Угу
AM
Абстракция эта не нужна с каналами, как показала практика. Усложняет всё.
AS
У меня на фронте Apollo, на беке absinthe и plug и все было хорошо пока я не захотел делать subscription-ы. Было принято решение использовать нативный apollo-вский ws link и написать реализацию сервера через cowboy
AS
Имхо, это лучше чем добавлять целый феникс для каналов (которые не то чтобы прямо хороши) и добавлять apollo-phoenix-websocket на клиент (который явно менее распространен и могут быть баги)
DR
Имхо, это лучше чем добавлять целый феникс для каналов (которые не то чтобы прямо хороши) и добавлять apollo-phoenix-websocket на клиент (который явно менее распространен и могут быть баги)
В такой комбинации вполне возможно, что лучше.
DR
Вот гибкие сокеты - это действительно слабая часть Phoenix-а.
DR
При куче каналов - клиенты тупо захлёбываются на хреновом инете при джойнах. В итоге перепилили все, теперь после коннекта клиенты сразу начинают эвенты получать, подписки на стороне сервера осуществляются.
Пабсаб у меня во всех проектах всегда свой, потому что при выходе на распределённую систему - он первый должен будет начать работать в кластере, а так как работа в кластере зависит от библиотек/конкретного решения, вот и получается, что ни один дефолтный пабсаб без интерфейса не имеет смысла использовать... Поэтому я тоже Phoenix-нативными каналами не пользуюсь.
DR
Но это я обходил с самого начала
ŹR
По-моему вы на разобрались крче