MQTT rest API

[uwejan]

Hi, obviously stackeverflow dose not allow asking for examples, do not know where to ask for help. I already have dart rest api's 'aqueduct',been using flutter flux stores, but it seems to be so much batetry consuming, where i have read somewhere mqtt is lighter and responsive, i wish to have a broker and client, where my client will be able to get data from my rest api and get notified of changes real time. i already have my rest api, and have installed mosquetto, and run the example code from pup https://pub.dartlang.org/packages/mqtt_client#-example-tab- I appreciate any help or guidance here.

[shamblett]

OK, if your example is running then you need to interface your REST API to the client, subscription and publishing should be easy enough, just get the topic(and QoS if needed) from your REST interface and call the relevant client methods. The reception of published data is more problematic, the client will deliver payload data to you on the topics you have subscribed to, you need to get this back over your REST interface somehow, there are several ways of doing this, just google for answers.

If your using the Mosquitto broker I'm not sure why you need a broker, you can just use that on whatever endpoint infrastructure you are talking to, the client assumes the broker is running in say the cloud somewhere. Developing your own broker would be a lengthy task, needing lots of MQTT domain knowledge.

[uwejan]

OK, i understand that, i need to subscriber to a topic, send http request and publish it, then i receive the response on the since i subsecriped, right? forgive if i did not udderstand that. How do i interface my rest api to the client? How do i send the request over mqtt to my rest api?

[shamblett]

OK, assume there is an MQTT broker somewhere(GCE, Azure, AWS etc.) and some user elsewhere in the world has published information to a topic named 'worldcat'. If you want to see whats been published to this topic you would call the subscribe method on the client with the topic 'worldcat'. How you get this topic from your REST API is is up to you. The client will then supply you with a stream of publish messages for the topic 'worldcat' with any other info the user(or users) have added. You then need to push that information out over your REST API but again there are many ways of doing this, this is really up to you.

If you wish to tell all the other users of the MQTT broker, say about your cat then you need to call the publish method of the client with the topic say 'mycat' with your info. Any other users that want to know about your cat will subscribe to that topic and receive your published data.

You would never run a client and broker on the same device in practice.

What is it you are trying to do?

[uwejan]

I have rest api of aqueduct, /api/books -> book name, book author, book year , /api/movies -> movie name, descriptions ..etc i use flutter flux stores, to fetch the data from the api to my flutter, flux stores are basically a rest api get into streams, and calling it on timer each 5 min say to get the latest data, results on too much battery consumtion and i think that is expected since we are talking about http requests for each api ' /books , /movies ....etc maybe 12 apis' will result on battery draining fast, otherwise all good. have read somewhere that mqtt is lightweight pub/sub and very responsive. So, i thought maybe if use mqtt_client, and run my own broker, maybe i can redesign my flutter app to use it and get its advantages, but how do i make it communicate with my dart 'aqueduct' rest api, /api/books /api/movies ...etc if you think mqtt is the way to go, can you give a very short example, please.

[shamblett]

A broker isn't a store, its not a database you can't query it for say a book author, MQTT is not what you want here, if you are subscribed to a topic you get whats published form the time of subscription, not what was published before, its a realtime system in this respect. Suggest you reach out more to other flutter users, use firebase maybe?

[uwejan]

No, i prefer to use my own solution, how can i send a request of get after sub to a topic topic/books ? i am thinking about subscribes to that topic, then sends the message containing the "request". Then the server end will publish the response back to that topic. In that way i do "ordinary" request/response style APIs. I just need to see some code how to send a request 'get' of /api/books after sub to topic/books ?

[shamblett]

....Then the server end will publish the response back to that topic......

How will the server know what response to publish back to the topic? If no one has published anything to the topic it won't have anything to give you which if your running your own broker the only person that can do that is you, so are you saying you want to subscribe to a topic that you yourself are publishing on, why? You already know what the response will be, you don't need MQTT.

[gokr]

I think what uwejan should do (I am going to do the same in a project of mine) is to turn the Aqueduct layer into an MQTT client so that each time say a book is added, the Aqueduct layer can publish an MQTT message on a proper topic about this. Then the mobile app can listen to appropriate topics, and if it gets a message it can still use the REST API to fetch additional info. The idea being that all changes of books are made through Aqueduct. Now... the only bit making this a bit complicated is the fact that Aqueduct runs in multiple isolates, so... you would probably like to have a single isolate responsible for the MQTT bits in Aqueduct. The model uwjan mentions for request/response style is something I have seen (and used) in MQTT myself - you emulate request/response by sending along something unique in the request - that the other end can use in the topic to publish back the "result".

[shamblett]

OK, I think the fog is clearing, I'm still a bit stuck on architecture here, you say 'the mobile app can listen to appropriate topics...', so we have a flutter app, on say a phone using the mqtt_client to subscribe to topics and get publish events, right, so where is the broker? Is this on the same machine you have your ' Aqueduct layer...' on, i.e. a server somewhere?

So you have a server, on it you have a server app with a REST API that uses the mqtt_client to publish messages to topics that the phone app then subscribes to. On reception of a publish message the phone app then uses this info to request more data about the topic using its REST API to the server. Is this correct?

[gokr]

Yes, all correct. I am using the same architecture, the MQTT broker typically running on the same server as Aqueduct. Also, I just integrated an MqttService (wrapping your client) in Aqueduct - it will create one per Isolate but that will still just sum up to say 5-10 of them, which is fine. Subscriptions and actions upon them should typically only be done in one of them though.

[shamblett]

OK, thanks for the clarification, just a question though, can't you use something like Googles PUB/SUB for this? I've used this on other projects admittedly not on mobile platforms, is it not efficient on battery life or something on mobile?