We considered EMQX because we initially used the MQTT broker Mosquitto, which does not support the higher sampling rates that our product requires. Our product needs to transmit nearly 16 KB of data per second, which is substantial, but Mosquitto broker cannot support that capacity. We switched to EMQX so that it can open multiple channels to send the data simultaneously to achieve the sampling rate as effectively as possible.

For example, I have an ADC connected to a microcontroller with eight sensors. The ADC takes raw data without any overhead of internet connectivity or HTTP calls, and the raw sampling rate of the ADC is nearly 128 samples per second. When transmitting the data, it suddenly drops to nearly ten samples per second, which represents huge data loss when considering medical, transportation, or any devices used by humans. We signed up for EMQX, and EMQX created simultaneous eight channels, increasing the rate from ten samples per second to nearly 80 samples per second. We initially used the free EMQX offering, which supported nearly 250 users, and then we moved to serverless, which is what we are currently using. Serverless supports nearly 16 channels, so 16 multiplied by 10 means we can achieve nearly 160 samples per second. That is the real-time scenario for which we have used EMQX.

You can use EMQX when you want to get a major amount of data to the internet. When transmitting data via HTTP, there is a minimum delay of 200 milliseconds, which is significant for IoT products. For that reason, we are transitioning to MQTT, which stands for Message Queuing Telemetry Transport. When moving to MQTT, there are many constraints that we faced in free MQTT options such as Mosquitto broker. EMQX will boost your product sampling rate and transmission so that you can achieve a large amount of data without any loss while transmitting through the internet. If you are planning to build an AI product using an IoT device, each data point will count. With EMQX, you will get many data points per second and over time spans to boost your AI, and the AI will be trained faster compared to other brokers.

The best feature for EMQX is that it supports many additional features. For example, if you do not want to own a server, you can directly purchase serverless. If you are using another broker and have deployed that broker onto a server, when the user count of your product increases, you would need to own another server, which will cost more. However, with EMQX, you can boost your subscriber count in the EMQX portal to fit more users into your product. That is nearly scalability in AWS in cloud terms, which I appreciate in EMQX.

When I started using the free feature, it supported 250 clients, but they have since reduced it to a significant degree. I do not know the exact number because I have moved to serverless. The free feature is beneficial to startups, so if you are doing a college project or a prototype, the free EMQX is very effective. You can use any server, whether it is Windows, Linux, or anything else, and it will be supported. That is a positive aspect, and it is supported in the free feature as well.

EMQX has improved significantly, and it is one of the greatest solutions. If you want to improve further, the SSL certificate and TLS certificate have overhead in serverless EMQX. If there were an option to utilize serverless without that TLS and SSL overhead, the embedded system would not experience the overhead burden. The embedded system would not need to perform a handshake each time it wants to transmit. That is one area that should be implemented in EMQX serverless.

3.5 years

My main use case for EMQX is for the streaming part, as we are a fintech-based startup using EMQX to get stock price details from DriveWealth. We have an MQTT module where we use EMQX as a streaming module to stream the data.

EMQX fits into my workflow as we designed an MQTT module where it helps us to fetch the data from DriveWealth, which is a US-based entity, by using the endpoint where we can get the stream data, thus allowing multiple users to access the stock information.

In terms of my main use case with EMQX, we were using a Docker pulled image of EMQX for the admin panel to see how many clients are connected, how long they are connected, and we have an auth plugin, so all streamed data was able to be fetched with the dashboard.

The best features EMQX offers in my experience include the EMQX configuration file, auth file, and HTTP file, which help us to get the relevant data, and EMQX is fantastic for dashboard creation, allowing us to fetch data for our mobile or web-based applications using multiple sources.

The dashboard specifically helped my team to understand how many clients got connected via our EMQX module connection, allowing us to track the health of the EMQX container, such as CPU usage and real-time connections, all tracked via the dashboard alongside multiple config files managing WSS connections.

EMQX has positively impacted my organization in many ways, particularly by making our main agenda of getting stock details and connecting users to our real-time protocol much easier.

As for improvements, I do not feel any bug or improvement is needed currently; the features are already sufficient for our efficient use, but if AI enhancements or messaging options could be added, that would help us a lot.

I believe that all suggested improvements are already well-built, and if any AI parts are integrated, it would greatly benefit new users. Overall, I am a happy customer of EMQX.

I have been using EMQX for about four years.

I have noticed measurable outcomes with EMQX, as we are mostly happy about the practicability and features offered, which contribute significantly to scalability and helped our product design in a better way.

EMQX is a pretty good product, and I am satisfied with it.

My advice for others looking into using EMQX is that it provides a better and more efficient way of getting data streams and better visualization for your product, along with easy integration and go-to-market solutions. I would rate this product nine out of ten.

I use EMQX for MQTT pub/sub use cases with devices connected through IoT. When communicating between different devices, EMQX provides the connection between them and delivers real-time updates.

Devices are deployed with MQTT TCP connections. Device credentials are created inside EMQX for each particular device, and those devices have those credentials with a specific client ID to communicate through the web app. The web app listens to a particular set topic which that particular device generates. That particular device sends data to that particular topic, and the application listens to that topic. In that case, they communicate with each other. When the application needs to provide some commands to the device, those commands are sent through command topics, and the devices listen to those. These communications happen in near real-time.

Webhooks provided by EMQX are also leveraged to fetch real-time connection details for the particular devices that are connected. EMQX provides functions to make real-time changes based on the events received from that webhook. The built-in monitoring from EMQX is also used for managing clients inside the EMQX dashboard.

EMQX is a solid open-source project for making IoT devices connect anywhere in the world. The main use case that stands out is the TCP connection, which plays a vital role inside the IoT device ecosystem. The pub/sub functionality and how publishers and subscribers interact with each other without disrupting the connection between devices and applications is outstanding. The best part of EMQX is that it provides unlimited authentications and authorizations. Different providers can be integrated between those authentications and authorizations. Authentication can be provided with the built-in database within an application. Authorization can be provided based on specific users who can perform specific actions on those devices, and those actions can be controlled inside the EMQX instance. EMQX is very versatile in those terms, and people can leverage those features mostly from the EMQX platform.

When going with the open-source EMQX version, there are limitations provided. For example, the webhooks use case cannot be scaled to as large a scale compared to the enterprise edition of EMQX. The open-source version helps a great deal with work in the company. The way this resource helps nurture the IoT device paradigm is greatly helpful for developers working newly on this system because the onboarding part of EMQX is very easy and developer-friendly. Someone who wants to dive into it can easily implement and make the system robust based on the technologies it provides.

EMQX provides API connections for applications. HTTP calls can be made to EMQX to get updates from the client. Those connections should be made asynchronously. The webhook part handles this well, but when it comes to the API part, when the load and payload of the MQTT topics and messages are very heavy, sometimes unknown errors occur, and logs and errors must be found. When a specific log session is created for that client, the readability of those logs is not good. The platform itself does not need improvement, but when it comes to developer-friendly implementations of EMQX, there are some pain points that need attention. The visibility of logs, error logs, and information logs inside the built-in monitoring needs work because developers, when they implement code or any kind of specific tools, need proper control over the system. Without that control, there is no point in implementing anything at all.

The monitoring part needs work. When it comes to the flow chart of how different clients are connected with different devices, there is a feature inside EMQX called Flow. When that Flow is in place, clients (devices) should be controllable from that Flow itself. These are the most important improvements that need to be addressed.

I have been using EMQX for more than three years.

If the machine and the environment in which it is deployed are stable, there should be no downtimes. When EMQX was deployed on production, it did not cause any problems. It is a production-grade tool that has been tested and is used in production by many organizations.

Scalability has not been an issue thus far. EMQX has handled growth from thousands of devices to millions of devices. There are no scalability caps being hit, and it continues to support growing needs.

The open-source version of EMQX is used, so there is no customer support to speak of. The documentation is exceptional and so developer-friendly that customer support is not needed. The documentation has been maintained very much with developers in mind.

The organization previously used other options such as VerneMQ or HiveMQ. When the switch to EMQX was made because it was so developer-friendly, there was no need to go back and re-implement VerneMQ. The organization moved on to EMQX and stayed there because it provides so much value to the product. There was no reason to look back, and that represents the return on investment. As a developer, if time is invested and a POC stays for the longer run, that is what return on investment means.

The previous solution was VerneMQ, and the switch was made because the implementation of authentication and authorization was not developer-friendly, and there was not much control over the schemas from a developer perspective. With EMQX, a schema is defined and everything is controlled by the organization's own IP. Whatever the use case is, it can be played around with, and security gateways can be implemented easily. With VerneMQ in place, that was not nearly as easy.

The relevant metric is the ability to grow from tens of thousands to millions of devices.

The open-source version of EMQX does not have a specific cost. When it comes to the deployment of the whole application as a whole, there is no specific number because AWS costing for the product that is maintained is quite high.

When switching from VerneMQ, EMQX was the first solution looked into while conducting the POC. When it satisfied all use cases easily, there was no reason to look back, and it was implemented right away because there was no desire to waste time. EMQX provided value right away. No other solutions were used or considered.

For a backend written in MySQL or MongoDB, specific users and ACLs inside MongoDB or SQL can be leveraged to integrate with authentication and authorization without relying on any outer-world providers. The company's domain will control the authentication and authorization for these devices. Overall, the devices are maintained inside the system, not anywhere else. This provides leverage between different authentication and authorization providers.

The organization was able to manage 1,000 plus devices and 65 million concurrent device connections with EMQX. Different clients use these EMQX pub/sub relationships, and it helps greatly, providing the versatility and extensibility of this particular platform.

For those wanting to implement a workflow where devices are present or real-time actions are needed from some client residing on the other side of the network, it is important to first know the use case. When the use case is finalized, a POC on EMQX can be conducted, which is easy to do because the documentation provides great support. For developers implementing it, the authentication and authorization part should be prioritized because that is the most important part for making clients secure. If security is compromised there, then the whole point of making connections secure is lost. Keep a close lookout for the authentication and authorization part so that wherever clients or devices are placed, they are secure and securely managing their communication between networks.

Anyone wanting to implement EMQX in their workflow can rely on the tool because it provides features that every organization has, and the use cases it solves are immensely valuable. Going ahead and implementing these tools puts an organization ahead of the game from other players. This review rates EMQX an overall score of 8 out of 10.