Handle microservices messages with several conditions

Hello,

I'm working on a Laravel application which centralizes the use of several microservices.

In terms of the message sent by a microservice, I have to handle it one or another way.

$message_received_by_the_microservice = ...;

switch ($message->type) {
	case 'some_type': {
		(new SomeTypeService)->do($message);
		break;
	}

	case 'another_type': {
		(new AnotherTypeService)->do($message);
		break;
	}

	...
}

For the moment I have this idea to write the code to handle the messages according to their type.

But I could also try to use a unique message service to handle the message and the handle function could dispatch to another service according to the message type.

(new MessageService($message))->handle();

To handle the message, I have to check for several conditions to satisfy the business logic.

if () {
	if () {
	} else {
		if () {
		}
	}
} else {
}

Well ... it could rapidly become unreadable.

So I have the idea to use events instead of several nested conditions.

MessageReceived::dispatch();

In the listener for this event, I check a simple condition and dispatch another event. To summarize the idea, here is what it could look like. And sure I could keep some nested conditions, but leverage the events.

public function handle($message)
{
	if ($condition_1) {
		MessageReceivedCondition1OK::dispatch();
	} else {
		MessageReceivedCondition1KO::dispatch();
	}
}

A last possibility could be the inheritance.

So I have thought about 3 possibilities :

nested conditions
events
inheritance

What do you think about them ? Do you have other suggestions ?

Thanks for your help.

LaryAI

2 years ago

Best Answer

Level 58

Hello V,

It seems like you're looking for a clean and maintainable way to handle messages from microservices in your Laravel application. Each of the approaches you've mentioned has its own merits and potential drawbacks. Let's discuss each briefly:

Nested Conditions: This approach can quickly become hard to manage and read as the number of conditions grows. It's generally best to avoid deep nesting where possible.
Events: Laravel's event system is a powerful feature that can help decouple your application's components. By using events, you can keep your code clean and focused on specific tasks. However, be cautious not to overuse events, as it can make the flow of your application harder to follow.
Inheritance: Inheritance can be useful if there are common behaviors among the different message types that can be shared in a base class. However, if the behaviors are too distinct, this might lead to a confusing hierarchy and can violate the Liskov Substitution Principle if not done carefully.

Here's an alternative approach using the Strategy Pattern, which can be a good fit for your scenario:

interface MessageStrategy
{
    public function handle($message);
}

class SomeTypeStrategy implements MessageStrategy
{
    public function handle($message)
    {
        // Handle some_type messages
    }
}

class AnotherTypeStrategy implements MessageStrategy
{
    public function handle($message)
    {
        // Handle another_type messages
    }
}

class MessageHandler
{
    protected $strategies = [];

    public function __construct()
    {
        $this->strategies['some_type'] = new SomeTypeStrategy();
        $this->strategies['another_type'] = new AnotherTypeStrategy();
        // Add more strategies as needed
    }

    public function handle($message)
    {
        if (isset($this->strategies[$message->type])) {
            return $this->strategies[$message->type]->handle($message);
        }

        throw new Exception("No strategy defined for message type: {$message->type}");
    }
}

// Usage
$messageHandler = new MessageHandler();
$messageHandler->handle($message_received_by_the_microservice);

With this approach, you define a strategy for each message type. The MessageHandler class then delegates the handling of a message to the appropriate strategy based on the message type. This keeps your code organized and makes it easy to add new message types in the future without modifying the existing handler logic.

Remember to consider the complexity of your application and choose the approach that keeps your codebase clean, testable, and easy to understand. The Strategy Pattern is just one of many design patterns that can help achieve these goals.

I hope this helps, and feel free to reach out if you have any more questions.

Best regards, LaracastsGPT

1 like