User engagement and experience are always top of mind while building a platform or application. One critical element of great user experience is the ability of the user to see the status of any action they’ve initiated, without needing to refresh the application constantly. For this, the data must flow into the user interface seamlessly and in real-time. This becomes even more important when we consider the number of processes and steps involved in the AI development process, and the need for a simple way to track the real-time status of processes happening under the hood.
This is where the technique of polling in front-end product development comes into play.
We’ll take a deeper look at the need for polling, the concept and process of polling, and how we’ve integrated into the RapidCanvas platform.
Earlier, users of the RapidCanvas platform faced a challenge - when a task (action B) relied on another task (action A) to be completed first, users had to manually refresh the page repeatedly to see if action A was completed. This was resulting in a frustrating experience. Additionally, if there are many such dependencies, refreshing the entire page for each one is inefficient. This leads to longer wait times (latency) and unnecessary data transfer (network traffic), and idle screens, as the system retrieves information for all tasks, even those irrelevant to the specific action B waiting on A.
To improve this process and to provide the user real-time updates, polling is used. Polling is used in front-end product development where the client (browser) repeatedly sends requests to the server at regular intervals to check for updates or new data. This involves continuous calling of the APIs at regular intervals to read data from the server. Polling automates this process by periodically checking the status of action A. This eliminates the need for manual refreshes and improves user experience by automatically triggering action B once A is finished. Furthermore, polling only retrieves the specific data needed for action B, reducing unnecessary data transfer and improving the platform's overall responsiveness.
At RapidCanvas, to offer a seamless customer experience along with complete visibility into the processes happening under the hood, we have implemented the technique of short polling.
Here, we have automated the APIs for functions like start, stop, cancel, when required, usually when some conditions are met. A series of APIs will be called at regular intervals using the Web API setInterval(). As part of this, we store intervalIds, or the IDs that can be used to identify the interval in a state management tool in the front-end, killing the intervalId after each cycle. Each cycle or interval honors a set of API calls each for an item in the list, using the Web API Promises. This short polling technique performs well, as seen by studying the patterns & efficiency in the current implementation.
Though end-users may not see it, polling happens extensively behind the scenes on the RapidCanvas platform.
While running a recipe, i.e. a series of ordered transformations that are applied to data at different stages, polling is taking place in the backend and the output of this is seen as updates on such as “running” and “built” on the canvas.
Manual recipe runs are automated through jobs and these too are supported by the function of polling, and can produce the update about the automated process, without needing to refresh manually.
Environments, or the infrastructure needed to run all of these processes, are activated as needed, to be more cost-efficient, and are not always active. With polling, the user is informed about the current status of the environment on which they are running tasks, so they can be sure they’re working in an active environment.
These are some examples of how polling helps create a better experience for users of RapidCanvas, and ensures updates within seconds.
The common types of polling are short polling, long polling, Server Sent Events (SSE), and WebSockets.
The current implementation on the RapidCanvas platform uses short polling, which we have discussed above. Short polling has better browser compatibility, it is simple & straightforward, and the front-end will have more control over the APIs. It has some downsides - it generates more network traffic, server load, and it is primarily suitable for simple use cases.
As development continues on the RapidCanvas platform, other alternatives like long polling, Server Sent Events (SSE), and WebSockets will be implemented, based on the use cases, their complexity, and the advantages each technique offers.
Long polling: Long polling can provide real-time updates faster, and reduces server load. The downside of long polling are connection overheads, complexity in implementing a server, and it may consume hardware resources such as CPU & memory.
Server Sent Events (SSE): SSE can provide real-time updates faster, offers efficient and simple implementation and it has a fallback mechanism if the browser doesn’t support it. The disadvantages are that it is unidirectional (only server-to-client), it is not suitable for binary & complex data, the connections are long-lived and consumes hardware resources, and it becomes difficult to maintain user-sessions.
WebSockets: WebSockets have low latency, it can maintain persistent connection, reduced network traffic, suitable for distributed systems due to its cross-domain communication capabilities. The downsides are that it is complex to implement these, proxy & firewall issues may arise, and resource consumption security concerns must be addressed.
RapidCanvas is a growing platform building numerous AI models for client use cases from a variety of industries. The polling feature implemented in the platform overcomes many limitations for the user by offering an efficient system for real-time status monitoring of data, and automating API calls. Through this technique, RapidCanvas becomes a much more responsive, engaging, and easy-to-use platform, for business users to implement their AI projects from end-to-end.