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.
