Ensuring that your systems work together in harmony— for both your organization and your end users— is important for many in IT. Developers often use “APIs” (application program interfaces) to build the connections needed to integrate these systems together.
When designing the data exchange between two systems, it is important to consider the “push” vs. “poll” question. Developers who want to be notified for a change of state in information, can either “poll” the remote system (which means continually call an API on that remote system looking for changes). This polling requires them to download the data and manually reconcile it looking for said changes. Alternatively, they can “push” the information from the remote system whenever there is a change. This push will only send them the information that changes as it happens. Let’s examine a real world case study: building a solution to display the presence of a user, and how the decision of “push” vs. “poll” impacts your platform.
The presence of a user is defined as “Available”, “Busy”, or “Away”, depending upon what they are doing. So, for instance, if they are on the phone, their presence is set to busy— and once they hang up the phone it is set back to available.
Some developers will initially tackle this problem by repeatedly calling (polling) an API endpoint to get the presence status of the user. By following this approach, the developer could execute the API endpoint once a minute to determine the presence status of the user. This may be sufficient, but depending on the problem being solved, having the presence status accurate up to the second may be required. In this case, we could simply execute the API endpoint once a second, instead of once a minute.
Once deployed, we are requesting the presence value for each of our 10,000 users within our organization every second. Suddenly, we are now executing 36,000,000 every hour, with the vast majority returning no presence change.
An alternate way of polling for the information is to have the presence status change based on information pushed by webhooks to those who are subscribed. In this scenario, the Fuze system will send a message to the remote system to inform them of change as soon as it happens.
Instead of repeatedly polling the API to look for when the presence has changed, the data is pushed to when it has changed by webhook. This will significantly reduce the network traffic because only the user's presence that is changing is sent, unlike the polling that is constantly asking for every user’s presence status —whether it has changed or not.
For a scenario such as this, a push-based approach —where developers subscribe to the events— will significantly improve the performance of the integration while reducing the resources consumed. This is easy to do using Fuze’s APIs within your communications application.
If you’re a developer working to build efficient integrations using Fuze’s APIs, make sure you take advantage of the Developer Center and the webhooks that are available to you. Given our years of experience in the enterprise, we want to pass along the knowledge we have so that others can be successful in their unified communications journey.