Ejabberd vs PubSub - use cases and differences?

I know that Whatsapp uses some custom implementation of ejabberd. - which is used for messaging between two clients.

Since Phoenix PubSub also has that bi-directional communication over websockets,it CAN work be used in realtime (soft realtime, not accurate to the 1/100 of a second) .

I am confused between XMPP vs Phoenix PubSub. My questions are :sweat_smile:

  1. For what use cases XMPP is strictly better than Phoenix PubSub?
  2. What are the differences between ejabberd vs Phoenix PubSub ?
1 Like

These are completely orthogonal things.

  • XMPP is a protocol, just like HTTP or WebSocket
  • ejabberd is an implementation of server for such protocol in Erlang. Just like Cowboy is an implementation of server for HTTP/WebSockets.
  • Phoenix.PubSub is an helper library for exchanging messages between Erlang nodes.

It is not comparable at all.


Thanks for clarification.

I guess my question is :

  1. Phoenix.PubSub uses websockets, right?
  2. What advantages one gets via xmpp protocol over websockets?
  3. Can Phoenix.PubSub be extended to use xmpp ? If yes, one has to spin xmpp server (not default cowboy that Phoenix ships with), right?

Check out the docs for PubSub and Channels. I think you may be conflating the two.

Phoenix PubSub was designed to be flexible and support multiple backends. There are two officially supported backends:

  • Phoenix.PubSub.PG2 - the default adapter that ships as part of Phoenix.PubSub. It uses Distributed Elixir, directly exchanging notifications between servers
  • Phoenix.PubSub.Redis - uses Redis to exchange data between servers. It requires the :phoenix_pubsub_redis dependency
  • See Phoenix.PubSub.Adapter to implement a custom adapter.

No, Phoenix.PubSub do not use WS, it do not use Phoenix at all. It is my biggest gripe with that library, that there is phoenix in its name. It is completely independent from any web or Phoenix technology. It uses defined transport (by default pg which uses Distributed Erlang), but it can use any other messaging technology out there.

These also are orthogonal. WebSocket is more like transport protocol (like TCP, but a little bit higher level as it utilises TCP underneath) and XMPP is data protocol (more like HTTP).

Technically - yes, but it would be IMHO a little bit pointless, as it would introduce a lot of overhead with encoding and decoding all that XMLs. So instead it would be better to use for example Kafka or PostgreSQL LISTEN/NOTIFY.

1 Like

I will read more about protocols.

Thank you so much for clarifications.

1 Like

I sense some X/Y problem here. It would probably be better if you state what objective you want to achieve first, so other people can make recommendations for you to choose from.

1 Like

Thanks @derek-zhou
Indeed an X/Y problem. (thanks for naming it for me)

What I wanted - to make a simple chat application. with tracking.

I already achieved chat and tracking using Phoenix.Presence .

Then I came across ejabberd. And was confused as it also enables chatting and messaging. I did the same thing without it.

Why would I need to use ejabberd at all ?
Why bother with XMPP ? Phoenix uses websockets which are working great for me sofar.

Ejabberd felt like something ‘meant for’ chat application and I am completely unaware about why or why not to use it instead of simple phoenix app.

Ejabberd or XMPP in general is meant for an industrial strength chat application with a rich and extensible set of functionalities, on a federated network governed by multiple entities. You may or may not need that.

Using Phoenix Liveview one put together a simple chat application quickly. I have one too:

I do not even use PubSub/Presence. There is more than one way to do it

1 Like

What is a good indication that one needs to use ejabberd and it gives some clear benefits to other approaches ?

When you need protocol (because you want to exchange messages with systems that are out of your control) go with ejabberd. If you want internal system communication then Phoenix.PubSub is a solution.

1 Like