Skip to content

Feature: Warlock support for REST triggers

Problem Statement

The current Warlock server in the MVC framework for PHP supports communication exclusively through WebSockets. While this works well for real-time messaging, it can be inefficient for backend PHP microservices that need to trigger events during client requests. To improve efficiency and flexibility, support for REST should be added to the Warlock server, allowing TRIGGER events to be sent directly without requiring a WebSocket connection.

Who will benefit?

Backend developers who build and maintain PHP microservices will benefit from a more efficient way to trigger events during client requests, reducing overhead and simplifying the integration process with the Warlock server.

Benefits and risks

Benefits

  • Allows backend PHP microservices to trigger events more efficiently during client requests without the need for WebSocket connections.
  • Improves flexibility by offering an alternative communication method for triggering events.
  • Simplifies integration with the Warlock server for services that do not require the full WebSocket protocol.

Risks

  • Potential increased complexity in maintaining two communication methods (WebSockets and REST) within the Warlock server.
  • The Control class might require significant changes or the creation of a new class to handle REST messages.

Proposed solution

  1. Add REST Support in the Warlock Server:

    • Implement a REST API endpoint in the Warlock server specifically for TRIGGER events.
    • Ensure the REST API adheres to the Warlock protocol standards for consistency and security.

  2. Decision on Control Class:

    • Option 1: Update the Control Class:

      • Modify the existing Hazaar\Warlock\Control class to support both WebSocket and REST communications.
      • Implement logic to determine whether to use WebSockets or REST based on the context or configuration.

    • Option 2: Create a New REST-Specific Class:

      • Develop a new class, e.g., Hazaar\Warlock\ControlRest, dedicated to handling REST messages.
      • Keep the existing Control class focused on WebSocket communication.
      • This approach reduces complexity within the Control class and separates concerns.

Recommendation

Given the different nature of WebSocket and REST communications, it is advisable to create a new class (Hazaar\Warlock\ControlRest) dedicated to handling REST messages. This approach keeps the existing Control class focused on WebSockets and simplifies maintenance.

Examples

N/A

Priority/Severity

  • High (This will bring a huge increase in performance/productivity/usability/legislative cover)
  • Medium (This will bring a good increase in performance/productivity/usability)
  • Low (anything else e.g., trivial, minor improvements)