10.New programming models and standards - JohnyzHub/jax-rs GitHub Wiki

Introduction

New technologies are allowing for faster sharing of real-time or nearly real-time information on the web. This has created a need for better ways to quickly communicate updates to website users. As a result, new programming approaches and standards are being developed to make working with this real-time data easier for websites and applications.

In this section we will cover the different programming models that emerged to address the near real-time updating of the client view based on the updates that are produced by the server.

Polling

Polling is a messaging pattern used in various contexts, including web services, to retrieve data or status updates at regular intervals instead of maintaining a continuous connection. It plays a significant role in scenarios where a client needs to check for new information, such as updates to data, the completion of processes, or the availability of resources.

Basic Mechanism

  • In a typical polling mechanism, a client sends a request to a server at predetermined intervals to check for new information or to see if a condition has been met.
  • The server then responds with the current status or data, which may involve the latest information or a confirmation of the outcome of a previously initiated operation.

image

Types of Polling:

  • Regular Polling: The client sends requests to the server at fixed time intervals. This can be simple but may lead to inefficiency if the server is rarely updated, causing unnecessary requests.
  • Long Polling: The client sends a request, and the server holds the connection open until new data is available or a timeout occurs. This reduces the number of requests made when data is infrequently updated, as the client will only make a new request when it receives a response from the previous one.
  • Exponential Backoff: In cases where polling is used to check for success/failure (e.g., job status), the client may increase the time interval between requests after each unsuccessful poll. This approach reduces load on the server while still attempting to retrieve updates.

Pros and Cons:

  • Advantages:

    • Simplicity: Polling is straightforward to implement both on the client and server sides.
    • Compatibility: Works effectively in environments where WebSockets or other persistent connections are not feasible.
    • Control: Clients can control the frequency of requests, which can help manage load and performance.

  • Disadvantages:

    • Inefficiency: Regular polling can result in many unnecessary requests to the server, leading to wasted bandwidth and resources.
    • Latency: There may be delays in data retrieval, especially with regular polling if updates occur between polling intervals.
    • Scalability: Increased load on the server if many clients poll simultaneously.

Use Cases:

  • Polling is commonly used in scenarios like:
    • Task Completion Status: A client might poll a web service to check if a long-running task (e.g., file upload, data processing) has completed.
    • Data Updates: Web applications may poll for updates to data sets, such as news feeds, chat messages, or notifications.
    • Game State: Multiplayer games may use polling to check for updates to gameplay state from a server.

Best Practices:

  • Implementing efficient polling strategies, such as long polling or exponential backoff, can improve performance.
  • Setting realistic time intervals based on the expected frequency of updates is essential.
  • Monitoring server load and responsiveness can help fine-tune polling intervals.
  • Consider using WebSockets or Server-Sent Events (SSE) as alternatives for real-time updates to reduce the need for polling when feasible.

Long polling:

Long polling is an enhancement of the traditional polling method used in web applications to achieve real-time data communication between a client and a server. While traditional polling involves the client repeatedly sending requests at regular intervals, long polling is designed to be more efficient by reducing the number of requests made and improving latency in receiving updates.

Basic mechanism:

image

  1. Client Request:

    • The client starts by sending an HTTP request to the server, asking for updates or checking if new data is available.

  2. Server Processing:

    • Instead of immediately responding with the current data (which is what happens in regular polling), the server holds the request open until it has new data to send back or until a certain timeout period expires.
    • If new information arrives during this wait time, the server sends a response back to the client with the data.

  3. Client Response Handling:

    • When the client receives a response from the server—whether it’s new data or a timeout indication—it processes that response accordingly.
    • After processing the response, the client typically sends a new long poll request back to the server, effectively restarting the cycle.

  4. Server Timeout:

    • If no new data becomes available within the defined timeout period, the server sends an empty response or an indication that no new data is available to the client.

Key Characteristics

  • Reduced Request Frequency: Long polling helps lower the number of requests sent to the server compared to traditional polling, as clients only poll when they have received a response, rather than at regular intervals.

  • Improved Responsiveness: Long polling allows clients to receive new data as soon as it’s available, thus minimizing the latency associated with traditional polling intervals.

  • HTTP-Protocol Based: Since long polling utilizes standard HTTP requests and responses, it is compatible with existing web infrastructure, including load balancers and proxies.

Advantages

  1. Efficiency: Long polling reduces the number of requests made to the server by holding connections open, which is beneficial for both server resources and network bandwidth.

  2. Real-time Interactivity: By allowing the server to push updates to the client as soon as they’re available, long polling facilitates a more interactive user experience.

  3. Simplicity: Long polling is straightforward to implement, leveraging existing HTTP technologies without needing specialized protocols or additional infrastructure.

  4. Better Resource Management: By reducing the total number of open connections due to fewer requests, long polling can help manage server load better than traditional polling strategies.

Disadvantages

  1. Complexity in Implementation: While easier than setting up more advanced technologies, long polling introduces some complexity in managing client-server communication and ensuring timely re-establishment of connections.

  2. Holding Connections Open: The server has to hold connections open, which can lead to resource exhaustion if many clients connect and hold their requests open for extended periods. This can be particularly problematic in high-traffic scenarios.

  3. Latency Under High Load: If many clients are long polling simultaneously, it can lead to increased latency if the server cannot efficiently manage resources and connections.

  4. Connection Limits: Many web servers impose limits on the maximum number of concurrent connections, which can become a bottleneck with numerous long-polling clients.

Use Cases

Long polling is commonly used in scenarios that require real-time updates but do not necessarily justify the complexity of technologies like WebSockets or Server-Sent Events. These use cases include:

  • Chat Applications: Instant message notifications can be sent as soon as a message is received without the user having to refresh their chat window.
  • Real-time Notifications: User notifications (such as alerts or updates to feeds) can be sent to clients as soon as they are available.
  • Collaborative Editing: Applications allowing multiple users to edit documents can use long polling to inform clients of changes made by others in real time.
  • Games: Multiplayer games can update player states or game status promptly to enhance user experience.

Conclusion

Long polling strikes a balance between the simplicity of traditional polling and the responsiveness required for real-time applications. While it is not as efficient as newer technologies like WebSockets, it remains a practical choice for offering near-real-time updates in web applications when those technologies are unavailable or difficult to implement. When considering long polling, it is essential to weigh its benefits against potential drawbacks and consider whether it meets the specific needs of the application architecture and workload.

Server sent events

Server-Sent Events (SSE) is a technology that allows a server to push real-time updates to web clients over a single, long-lived HTTP connection. Unlike traditional polling or even long polling, where the client repeatedly requests updates, SSE enables the server to send updates proactively whenever new data is available. This capability makes SSE particularly useful for applications that require continuous updates, such as news feeds, stock price updates, or chat applications.

SSE kernel includes EventSource and Event. EventSource API allows web servers to push real-time updates to web clients

Basic mechanism:

image

  1. Client Initiation:

    • The client (typically a web browser) initiates communication by sending an HTTP GET request to the server, specifying that it expects to receive event updates. This is done by setting the appropriate headers to initiate a stream.

  2. Server Response:

    • The server responds with a stream of data, using the MIME type text/event-stream. This indicates that the response will be a continuous stream of events.
    • The server keeps the connection open, allowing it to send update data as it becomes available, without closing the connection after a single response.

  3. Data Format:

    • The server sends messages in a simple text-based format. Each message consists of one or more lines, typically starting with the keyword data: followed by the actual data content.
    • Messages are separated by a double newline, indicating the end of one event and the start of another. An example message might look like: 
      data: New update available!
data: More details are on your dashboard.

  4. Client Handling:

    • On the client side, JavaScript can be used to handle incoming events using the EventSource API. The EventSource object listens for messages from the server and can execute specified callback functions when new data is received.
    • This client-side implementation allows seamless integration with existing web technologies.

  5. Reconnection:

    • If the connection is lost due to network issues or server-side errors, the EventSource automatically attempts to reconnect after a brief delay typically 3 seconds, helping maintain a continuous connection.

Key Characteristics

  • Simplicity: SSE is relatively simple to implement, thanks to its straightforward API and text-based communication format.

  • Unidirectional: SSE is designed for server-to-client communication. Unlike WebSockets, which allow bidirectional communication, SSE is only meant for the server to push updates to the client.

  • Automatic Reconnection: If the connection is disrupted, the EventSource automatically tries to reconnect, ensuring a more resilient application.

  • Text-Based Format: SSE uses a simple text-based format for messages, making it easy to debug while also keeping the implementation lightweight.

Refer the code to know the server side implementation details: EventsResource.java

Advantages

  1. Real-time Updates: SSE allows the server to push updates to clients in real time, providing a more immediate user experience than polling methods.

  2. Efficient Resource Use: By maintaining a single open connection, SSE reduces the overhead associated with establishing and tearing down HTTP connections, making better use of server and network resources.

  3. Built-in Reconnection Logic: The automatic reconnection mechanism simplifies the client-side implementation, ensuring that clients remain connected even after interruptions.

  4. Native Support in Browsers: Support for the EventSource interface is built into modern web browsers, allowing for easy implementation without requiring additional libraries or plugins.

Disadvantages

Limited Browser Support: While most modern browsers like chrome, edge, firefox etc support SSE, it may not be supported in older browsers or certain environments. Internet Explorer does not support SSE, which may be a consideration for applications needing wide compatibility.

Unidirectional: Since SSE is unidirectional, if the client needs to send information back to the server, it must do so using a separate channel (e.g., traditional AJAX requests), which can complicate the architecture compared to bidirectional protocols like WebSockets.

Text-Only Encoding: SSE only supports text-based data, making it less suited for scenarios that require binary data transfer, which would require encodings like base64 or alternative methods.

Performance with High Load: Although SSE efficiently maintains a connection, high user load may create a heavy burden on server resources as each active connection occupies server resources.

Limited concurrent connections: There is a limit of 6 concurrent SSE connections per browser tab. This can cause issues when trying to open multiple tabs with SSE connections 1.

Use Cases

  • Live News Feeds: Continuously updated news articles or alerts can be pushed directly to users without requiring manual refresh.
  • Stock Market Updates: Financial applications can push real-time stock updates to clients, allowing users to stay informed about market changes.
  • Social Media Notifications: Applications can notify users of new messages, comments, or likes without them needing to refresh their pages.
  • Real-time Analytics Dashboards: Business dashboards can dynamically update their displays based on real-time data, keeping users informed about their metrics.
  • Chat Applications: While more complex real-time messaging may prefer WebSockets, simple notifications or messages could be handled with SSE to reduce overhead.

Conclusion

Server-Sent Events provide a simple and effective mechanism for real-time data transfer from server to client. They reduce reliance on HTTP polling while offering an intuitive and powerful way for developers to implement live updates in web applications. Given their lightweight nature and built-in reconnection capabilities, they are well-suited for applications that can benefit from unidirectional real-time updates. However, for bidirectional communication needs or scenarios requiring binary data support, alternatives like WebSockets may be more appropriate. Overall, SSE offers a practical solution for enhancing user engagement through timely information delivery.

WebSockets

WebSockets are a communication protocol that enables bidirectional, full-duplex communication between a client (usually a web browser) and a server over a single, long-lived connection. They are designed to facilitate real-time data exchange, making them particularly useful for applications that require constant updates or interactions where latency is critical.

Basic mechanism

image

  1. Establishing a Connection: The WebSocket protocol begins with an HTTP request, where the client "requests" to upgrade an existing HTTP connection to a TCP connection. This is initiated using a special HTTP header (Upgrade: websocket). If the server supports the WebSocket protocol, it responds with a 101 Switching Protocols status code, indicating that the protocol change is underway. This initiates the WebSocket connection over single TCP protocol.

  2. Full-Duplex Communication: Once the connection is established, data can be sent and received simultaneously in both directions (client-to-server and server-to-client) without needing to reopen connections for every message. This reduces overhead and improves performance compared to traditional request-response models, like AJAX, where the client must open a new connection for every interaction.

  3. Message Framing: WebSocket messages are sent in frames, which can carry text, binary data, or control frames to manage the connection (e.g., closing connections). This framing mechanism, along with lightweight headers, makes WebSockets highly efficient for transmitting data.

  4. Closing the Connection: Either the client or the server can initiate the closing handshake, which is done via a closing frame. After acknowledging the closure, both the client and server release resources associated with the connection. This is the significant difference compared to http protocol where each connection will be closed by sending the response.

image

refer this weblink for additional details: what-a-websocket

Advantages

  1. Low Latency: WebSockets significantly reduce latency in communications compared to traditional HTTP polling or long polling, making them ideal for applications needing immediate updates.

  2. Reduced Overhead: Once the connection is established, WebSockets maintain a single connection for the duration of the session, minimizing the amount of data sent in headers, which reduces bandwidth consumption.

  3. Real-Time Communication: Since WebSockets support full-duplex communication, they allow real-time interaction, enabling updates to be pushed from the server to the client and vice versa at any given time.

  4. Compatibility with Modern Browsers: Most modern web browsers support WebSocket natively, making it easy to implement without the need for additional libraries or plugins.

  5. Binary and Text Data: WebSocket supports both text (UTF-8) and binary messages, allowing for a wide range of applications, including those requiring images, videos, or complex data formats.

Disadvantages

  1. Complexity: Implementing WebSocket servers can be more complex than traditional REST APIs; developers must handle more edge cases, such as connection management and state recovery.

  2. Resource Consumption: Maintaining many open WebSocket connections can consume more server resources than traditional HTTP connections, particularly in high-traffic environments.

  3. Firewall and Proxy Issues: WebSocket connections often face issues with firewalls, proxies, or strict corporate networks, which may not handle the protocol correctly.

  4. Server Scaling Challenges: Scaling a WebSocket server can be more challenging than scaling traditional HTTP services, as it often requires maintaining connection states.

Real-Life Use Cases

WebSockets have become a popular choice for a variety of applications that require real-time communication. Here are some notable use cases:

  1. Live Chat Applications: WebSockets enable instant messaging in chat applications, allowing users to send and receive messages in real time without refreshing their browsers. An example would be Slack or Discord, where multiple users can interact with each other simultaneously.

  2. Online Gaming: Multiplayer games rely on WebSockets for real-time player interactions, match updates, and game state sharing. Games like Agar.io and Fortnite utilize WebSockets to provide a responsive multiplayer experience.

  3. Collaborative Document Editing: Tools like Google Docs leverage WebSockets to allow multiple users to edit a document simultaneously, with changes reflected in real time across all users' screens.

  4. Live Sports Updates: Sports apps often use WebSockets to deliver live scores and updates to users instantaneously. For instance, ESPN and Yahoo Sports provide real-time scores and commentary for sporting events using WebSockets.

  5. Stock Ticker Applications: Financial applications that require real-time stock price updates and market information use WebSockets to push the latest data to clients without any delay. Applications like Robinhood or eToro showcase such functionalities.

  6. IoT Applications: Internet of Things (IoT) solutions often employ WebSockets to establish real-time communication between devices (like sensors, cameras, and smart appliances) and centralized servers for monitoring and control.

  7. Notifications and Alerts: Applications like social networking sites (e.g., Facebook, Twitter) utilize WebSockets to send immediate notifications and alerts about user interactions, such as likes, comments, or messages.

Conclusion

WebSockets represent a powerful technology for enabling real-time, interactive web applications. Their ability to maintain persistent connections and facilitate low-latency, bidirectional communication opens up many possibilities for modern web development. While they possess some complexities in implementation and management, the advantages they provide make them a preferred choice for applications that require immediate data updates and user interactions. By understanding when and how to use WebSockets, developers can build responsive and engaging experiences on the web.

Webhooks

Webhooks are user-defined HTTP callbacks that are triggered by specific events in a web application. They allow for real-time notifications and integrations by enabling different systems to communicate with each other without requiring constant polling. This makes webhooks a powerful tool in web services, as they can handle event-driven architecture efficiently.

Basic mechanism:

image

  1. Event Occurrence: An event occurs in the source application (e.g., a new user signs up, a comment is posted, etc.).
  2. Send HTTP Request: The source application sends a POST request to a predefined URL (the webhook endpoint) configured by the subscriber (the application that wants to receive notifications).
  3. Receive and Process: The receiving application processes the incoming request, extracting data from the request body. Actions are taken based on the event’s data.
  4. Acknowledge Receipt: The receiving application can send a response back to the source application, typically an HTTP 200 status code to acknowledge the successful receipt of the webhook.

Real-time Use Cases

  1. Payment Processors:

    • Example: Stripe or PayPal.
    • Use Case: When a payment is processed (successful or failed), these payment gateways send webhook notifications to your application. For example, your application could automatically update the order status, send a confirmation email, or adjust inventory levels based on the payment status received through the webhook.

  2. Git Repositories:

    • Example: GitHub.
    • Use Case: A repository can be set up to send a webhook notification to a continuous integration service whenever a push event occurs. This allows CI/CD pipelines to trigger builds and run tests automatically when code is pushed to a repository, enhancing the development lifecycle.

  3. Communication Platforms:

    • Example: Slack or Discord.
    • Use Case: Webhooks can be utilized to create notifications in chat applications. For instance, when a new issue is created in a project management tool like Jira, a webhook could trigger a message in a designated Slack channel to notify team members about the new issue.

  4. CRM Systems:

    • Example: HubSpot or Salesforce.
    • Use Case: When a lead is converted to a customer, a webhook can trigger updates in another application, such as sending a welcome email via an email marketing service or logging the change in an analytics tool.

  5. IoT Devices:

    • Example: Smart home devices.
    • Use Case: When a smart thermostat detects a change in temperature or a motion sensor is triggered, it can send webhook notifications to a cloud service that logs these events, triggers actions (like sending alerts), or adjusts other settings in an interconnected system.

  6. Social Media Platforms:

    • Example: Twitter or Facebook.
    • Use Case: When a new post is created or a comment is added to a post, webhooks can notify third-party applications or services, allowing for real-time engagement strategies or analytics to be updated instantly.

Advantages

  • Efficiency: Webhooks only send data when an event occurs, reducing the need for constant polling and thus saving bandwidth and resources.
  • Real-time communication: Events are processed in real time, allowing for immediate actions and updates.
  • Integration Flexibility: Webhooks make it easy to integrate various services and automate workflows across different platforms.

Considerations

  • Security: Webhooks can expose endpoints that may be vulnerable to malicious attacks. It’s crucial to verify incoming requests using techniques like HMAC signatures or IP whitelisting.
  • Reliability: If the receiving application is temporarily down, the webhook notifications may be missed unless there's a retry or logging mechanism in place.
  • Versioning: As APIs evolve, managing webhook payload structures can be challenging. Proper versioning and documentation are necessary.

Conclusion

Webhooks are a vital component in modern web applications, enabling real-time updates and facilitating communication between disparate systems seamlessly. Understanding how to implement and manage webhooks effectively can significantly improve the responsiveness and functionality of applications and integrations across various domains.

Comparison

image

Refer the below article to see the detailed comparison between these concepts: comparing-api-sse-webhook-websocket