What to store in a notification? - laravel

Question

I'm currently utilizing Laravels notification package a bit more, but the following bothers me for weeks now: What should I really store in notifications?
Sometimes notifications are related to specific models, but not always.
Examples: Your blog post was published. or An error occurred while doing something. The entry was deleted.
Sometimes these models have relationships like Post → Category and the message should look like: Your blog post in the category "A Category" was published.
Now the questions:
Should I save a related model completely (eg. Category)? This would make accessing it later easier, but it's also a source for inconsistency. Or should I simply save the category ID? Only saving the ID means that I can reference the current data, but what happens if the category gets deleted? Then the notification cannot be rendered. Also I would need to also query the related models for this notification everytime.
Should I save the full message or only the data and compose the message on the client? (App, SPA Web-Frontend...). What about localization then?
What is a best practice for future scaling and also for extending existing notifications in the future?

Answer 1

So you propose to either go for:
1. Save notifications including all data required to display it
OR
2. Save notifications with just references so it can render message later on
So let's consider the advantages and drawbacks of both options.
Option 1: saving including all data
If a related model is deleted, the notification message can still be rendered as before (as you mentioned)
If a related model is changed (e.g. category title is changed), the notification message does not change
If you want to change a notification later on to include additional fields from related models, you won't have those fields available
Option 2: saving including just references
If a related model is deleted, the notification can not be rendered (as you mentioned). I would however argue that the notification wouldn't make much sense in this case.
If a related model is changed (e.g. category title is changed), the notifciation message changes with it
If you want to change a notification later on to include additional fields from related models, you will have those fields available
Additionaly if you were to serialize the notifications in the database you won't be able to deserialize them if you changed the model for it later on (e.g. a field is deleted).
Implementation of option 2
In order to go for option 2 additional database load can't really be avoided.
Easy way
The easiest way would be to resolve the relationships in the notification would be to query the relationships during the rendering of the notifications array, this however will cause the system to an additional query for each relationship.
NotificationController.php
$user = App\User::find(1);
foreach ($user->notifications as $notification) {
echo $notification->type;
}
MyNotification.php
public function toArray($notifiable)
{
$someRelatedModel = Model::find($this->someRelatedModel_id);
return [
'invoice_id' => $this->invoice->id,
'amount' => $this->invoice->amount,
'relatedModelData' => $someRelatedModel->data,
];
}
Nicer way
The better solution would be to adjust the query currently used for retrieving the notifications so it will include the relationships on the initial load.
NotificationController.php
$notification = App\Notification::byUserId(1)->with('someRelatedModel);
See eager loading for more on this.
Tl;dr Considering the points above I'd go with option 2; only keep references to models you'll need when rendering the notification.