# Best Practices

### Secondary database connection for inbox messages

Instead of bulking everything under 1 database, consider using another database for inbox (if your applications are big)

**PROs:**

* The inbox is independent & isolated from the main DB.
* Increase the High Availability for Inbox.
  * Just in case you have an incident from the application, Inbox would still collect webhook requests
    * Recovery is much faster and less "manual" work.

### Dedicated instance for Inbox Process

To achieve "High Availability", consider running the Inbox HTTP in a dedicated server/docker instance.

This would isolate the Inbox from the whole Application. And Inbox just stands there, blindly receiving and appending messages without any dependencies.

### Handler with Single Responsibility

Yup, don't put a lot into 1 Inbox Handler class, you can always do:

```
if ($payload['event'] !== 'event_A') {
   return;
}

// handle Event A here
```

Just like how we are using the Laravel Events/Listeners, feel free to bind many handlers for the topic. 

### (v1.1.1+) Authorize and Validate your Request

Usually, third-party services would provide us a way to sign and validate the payload to ensure we are receiving the legit ones. 

To achieve this, inside your custom FormRequest, you can add:

* `authorize` method: to encrypt and validate the signature
* `rules` method: to ensure the payload contains enough information

As the same as every Laravel request.