Backend: new fcm contract #268
Conversation
| ) | ||
|
|
||
| if (bookings.isEmpty()) { | ||
| logger.info("[fcmNotificationSender] Bookings on 1 week from now for {} workspace were empty", workspace.name) |
There was a problem hiding this comment.
The name of the class is automatically specified by the log. The name of the method should be specified at the beginning of the message: [sendUpdateContentMessages]
| @@ -29,6 +45,58 @@ class FcmNotificationSender(private val fcm: FirebaseMessaging): INotificationSe | |||
| .build() | |||
| fcm.send(msg) | |||
| } | |||
|
|
|||
| override fun sendUpdateContentMessages(topic: String, resourceId: String) { | |||
| logger.info("[fcmNotificationSender] Received update on {} calendar id", resourceId) | |||
There was a problem hiding this comment.
The name of the class is automatically specified by the log. The name of the method should be specified at the beginning of the message: [sendUpdateContentMessages]
| ) | ||
| } | ||
| } | ||
| logger.info("[fcmNotificationSender] {} messages have been sent, {} of them successful, {} - failures", |
There was a problem hiding this comment.
[handleFcmResponses]*
|
|
||
| val messageId = UUID.randomUUID().toString() | ||
| val messageBatches = bookings.chunked(MAX_BOOKING_EVENTS_IN_MESSAGE) { bookingList -> | ||
| val fcmWorkspace = FcmWorkspaceWithBookingsDTOModelConverter |
There was a problem hiding this comment.
We usually inject converters through DI.
|
It turns out that batch endpoint will be deprecated on 21st of june this year and they are suggesting to implement your own batch strategy using their '/send' endpoint, but it would be much less efficient (using batch endpoint all messages were sent in 1 request). |
Red1tum
force-pushed
the
backendApp/feature/new-fcm-contract
branch
from
7396aa4
to
a11cd3d
Compare
We receive the google's calendar id from header by which we can find our workspace. Then we will fetch all booking for this workspace for one week from now. We will send the workspace with bookings in batches if there are too many of bookings (see companion object to see how we check if there are too many). These messages will have unique id so that the receiver of these messages could detect if it's continuation or new message.
I'm not sure about converter implementation, so open to suggestions.
I'm also thinking on adding new repository for bookings (specifically for this sender), because the current one's getting more information than we really need (integration, etc). So removing these joins could improve performance of this sender a bit.