Hi! I’m quite new to Elixir/Phoenix and to BEAM in general, however I hope to be working quite intensely with these tools throughout the year.
I am about to commence work towards developing a (group)chat/voicecall/videocall Web Application, with a secure XMPP compliant and federated back-end written in Elixir on the Phoenix framework
I’m at the point in development where I am transitioning from soft-systems work to the defining of the software scope, so I’m defining the finer details of the main requirements of the system. One of the problems I’ve come across here concerns defining and describing the general interfaces of a federated XMPP server between other XMPP servers and clients that may have differing degrees of compatibility.
I understand that very capable Erlang backed instant messenger applications exist, ostensibly the most capable as well as most accessible being MongooseIM at the moment (please correct me if I’m terribly mistaken).
My understanding is that MongooseIM’s backend is largely, if not entirely written in Erlang. Would it be advisable to study its architecture and try to construct a corresponding server but in Elixir, rather than Erlang? The reason I am using elixir is because I want to leverage the Phoenix framework, and have the option of adding other features to the web application not relating to XMPP (by the way, would I need to use a separate not necessarily XMPP compliant server to support such an extension to the application?).
I would really appreciate any contribution from community with respect to guiding me in this matter.
Thank you for the information and link, so to confirm primarily using/slightly modifying (where necessary) mongooseIM’s won’t impede my ability to fully leverage the Phoenix framework?
I know that doesn’t sound like a logical question because mongooseIM is already a highly concurrent fully functional chat server, but I would like to do more than just append the mongooseIM, because I am constructing a web application and I want to be able to extend it in future with other features.
I would like to leverage the Phoenix framework to carry out any future extensions, and I would like the application (if need be) to run one major category of services from one server, and another major category of services from another rather than dividing the same category of services over two servers, i.e. one Erlang (mongooseIM) and the other Elixir/Phoenix(for future extensions).
On a lower level they would obey the same rules and use the same abstractions, ones that BEAM gives you - processes, supervision trees etc. Depending on how they are structured on higher level, what you want might be easy or tricky or even impossible, but from our current point I can’t see why it would not work.
I have no experience with MongooseIM in particular, I only know it’s Erlang, maybe someone who knows more about it can give you a more specific answer.
I’m not super familiar with MongooseIM. But it provides quite a few client connection options out of the box. REST, WS, Bosh and more. I don’t think you would want to rewrite the xmpp protocol. It does provide the ability for extensions however. https://mongooseim.readthedocs.io/en/latest/advanced-configuration/Modules/
I would dig deep into the docs for MongooseIM. More than likely the modules would need to be pure Erlang however.
Perhaps a bit more definition on what you hope to accomplish by adding Phoenix would help us point you in the right direction.
One of the main additions would potentially be the implementation of a micro-blogging feed on the application. I want the user to be able to place microblogs that they’ve interacted with on or off their roster, in addition to being able to place users on/off their rosters (the latter being a ubiquitous feature of XMPP servers), so that they can regulate whether or not they receive alerts from activities on that microblog. I want such preferences to be enforced server side, so as to reduce unnecessary backend processes.
Although this feels like if its not already on MongooseIM (which seems to be the case) then it could just be an appendage, but I think the additional enforcement of concurrency best practices gained from working with the Phoenix framework would make implementation of such a feature more reliable. I don’t know if mongooseIM supports publishing in that way, since it’s an instant messaging service.
There are some other features, but while those are luxury features, and not heavily prioritised, knowing that I can continue to extend the application in such a direction when feasible would be a desirable outcome.
I very much want to maximise the amenability of the application, from the bottom up.
