MQTT Subscribe vs HTTP webhook for service

[William Schweigert]

So I see with a lot of brokers that they will have webhook plugins. If I want to connect a service e.g. a node server to send emails/logdata/send texts should i have that server connect to the broker and subscribe to the endpoint needed or should I use the webhook plugin and run an express server to handle those requests from the broker? I can see that both can work I'm unsure if one is better for scalability and reliability.

[Sumeet Puri]

Much more of a broker/architecture pattern question, so the architecture choice will be broker dependent. 

Whether you have your downstream app subscribe via MQTT or via WebHook depends on a couple of factors. 

MQTT subscribe is lighter weight, and connection oriented, so you can “stream” data. WebHook is simpler, as it’s just HTTP, but heavier from a header perspective. 

I work for Solace, so using that as my reference. With a multi protocol broker like Solace, you can have an MQTT publish natively webhooked out to any downstream application, and vice versa. 

You might find this blog useful:

https://solace.com/blog/how-to-maximize-microservices/

Solace is free for production for life: https://solace.com/software/getting-started/

Thanks and Regards, 

Sumeet. 

On 29 May 2019, at 1:00 PM, William Schweigert <billysc...@gmail.com> wrote:

So I see with a lot of brokers that they will have webhook plugins. If I want to connect a service e.g. a node server to send emails/logdata/send texts should i have that server connect to the broker and subscribe to the endpoint needed or should I use the webhook plugin and run an express server to handle those requests from the broker? I can see that both can work I'm unsure if one is better for scalability and reliability.

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/7c534801-f1b5-4b57-9dff-816788fe0638%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ranjith Kumar Diraviyam]

When two MQTT Clients communicate with each other, Who is the sender of the data is lost in the Broker. When you build an application, the communication happen between machine to data storage and human to machine based on the data analysis. So the application needs the time of receipt of the data from the client and who is the person behind the application managing the device. 

So the best practice for building a manager application is building over the MQTT Broker.  When you build a very much integrated application, it is not only http hooks, I would recommend a application ( programming language) level hooks for integration. 

Hope this helps. 

Thanks, 

Ranjith 

Bevywise Networks.

[William Schweigert]

Right so I'm using emqx as my broker right now and it feels weird to have my backend subscribe to a topic as the data flows one way and the backend server does not need to publish anything just consume data. It also feels weird to ask my emqx broker to send 60 http requests a second to the node server. I guess 1 connection is better than opening and closing connections for http requests tho I will have to ensure my node server can consume the mqtt messages quickly enough.

On Wednesday, May 29, 2019 at 7:50:45 PM UTC-4, Sumeet Puri wrote:

Much more of a broker/architecture pattern question, so the architecture choice will be broker dependent. 

Whether you have your downstream app subscribe via MQTT or via WebHook depends on a couple of factors. 

MQTT subscribe is lighter weight, and connection oriented, so you can “stream” data. WebHook is simpler, as it’s just HTTP, but heavier from a header perspective. 

I work for Solace, so using that as my reference. With a multi protocol broker like Solace, you can have an MQTT publish natively webhooked out to any downstream application, and vice versa. 

You might find this blog useful:

https://solace.com/blog/how-to-maximize-microservices/

Solace is free for production for life: https://solace.com/software/getting-started/

Thanks and Regards, 

Sumeet. 

On 29 May 2019, at 1:00 PM, William Schweigert <billysc...@gmail.com> wrote:

So I see with a lot of brokers that they will have webhook plugins. If I want to connect a service e.g. a node server to send emails/logdata/send texts should i have that server connect to the broker and subscribe to the endpoint needed or should I use the webhook plugin and run an express server to handle those requests from the broker? I can see that both can work I'm unsure if one is better for scalability and reliability.

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mq...@googlegroups.com.

[William Schweigert]

I'm slightly confused cant you just add the client id into the payload if you want to know who is sending the data?

[Ranjith Kumar Diraviyam]

Not every edge device will have the luxury in terms of power & bandwidth to send information like client id , time stamp & other additional client specific information on every payload.  There are state based devices which needs to push just 1 or 0.   

Based on the need, we advice customers to keep the payload light weight and do most of the things on the server side. 

Hope this answers.