0

I'm starting a project to build an instant messaging application for mobile devices. Although not the complete list of components these are the main data flows I'm concerned about:

  1. Mobile app conencted to WebSocket -*for message analysis (abusive language / etc) and persistence.

  2. Mobile app connected to MQTT broker -*for message publishing and message receiving

  3. Mobile app connected to RESTful API -* for businness handling (balance check, token expiring, purchases, friend lists, user profile) **the different APIS can be distributed

Let me explain my concern: I want to save as much bandwidth as possible. Obviously I would prefer to have the least amount of channels but at the same time I can't just have an open connection to the message broker I need business logic in place for each message.

Because I don't want to sacrifice delivery speed I decided to have a separate channel for analysis and for message publishing (WebSocket and MQTT over TCP) instead of sending everything through websocket, and another one for business, like blocking a user, purchases, etc. (RESTful API), so based on the response from the REST API every so often I would apply some logic for sending messages.

What do you think of this approach? Do you have any suggestions?

Improve this question

1 Answer 1

Reset to default
2

I would keep MQTT out of this. You already identified the problem with having too many separate channels, and this is the one to drop IMO. I see two main arguments here:

  1. MQTT ports and protocol may be unsupported by restrictive policies such as implemented in corporate firewalls and public wifi access points. https-based protocols are available in more situations.
  2. MQTT access control is weak as far as I remember. Clients can post and change almost anything once they have access, so you should not use it with potentially untrustworthy clients.

I'd rather do a RESTful interface with an optional websocket connection for push notifications (or maybe all messaging.) Authentication could be done identically since connection establishment is through http(s) so any scheme used with the RESTful service can be used with websocket unchanged.

Improve this answer
2
  • Thank you for your answer, how would you deal with delivery speed? I have learned that success of instant messaging applications is largely due to the feeling of real time interactions of the users.
    – Daniel Arechiga
    Jan 3, 2020 at 20:09
  • Websockets allow near-instantaneous communicatios, just as MQTT would. Both require that the client keeps a connection open over which the server can send messages, so they both consume significant server resources (connection endpoints) which requires careful design for scalability. One advantage of MQTT would be that a message broker is included, for a websocket solution you'll have to implement that in your backend.
    – Hans-Martin Mosner
    Jan 3, 2020 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.