Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate sendAll and sendMulticast #2094

Merged
merged 1 commit into from
Mar 3, 2023

Conversation

Doris-Ge
Copy link
Contributor

@Doris-Ge Doris-Ge commented Mar 3, 2023

  1. Deprecate sendAll and sendMulticast
  2. Add dummy implementation for sendEach and sendEachForMulticast to avoid errors reported by api-extractor

1. Deprecate sendAll and sendMulticast
2. Add dummy implementation for sendEach and sendEachForMulticast to avoid errors reported by api-extractor
@lahirumaramba
Copy link
Member

Thanks, @Doris-Ge !
nit: It's better to avoid placeholder methods whenever we can and only add new methods when they are implemented. Since these changes are going to a feature branch, we should be okay. Let's try to avoid empty methods in future PRs if we can.

@Doris-Ge
Copy link
Contributor Author

Doris-Ge commented Mar 3, 2023

Got it! I was trying to keep a PR smaller. Sorry about that!

@Doris-Ge Doris-Ge merged commit 2725f8c into fcm-batch-send Mar 3, 2023
Doris-Ge added a commit that referenced this pull request Apr 12, 2023
…nd (#2138)

* Deprecate sendAll and sendMulticast (#2094)

1. Deprecate sendAll and sendMulticast
2. Add dummy implementation for sendEach and sendEachForMulticast to avoid errors reported by api-extractor

* Implement `sendEach` and `sendEachForMulticast` (#2097)

`sendEach` vs `sendAll`
1. `sendEach` sends one HTTP request to V1 Send endpoint for each
    message in the array.
   `sendAll` sends only one HTTP request to V1 Batch Send endpoint
    to send all messages in the array.
2. `sendEach` calls `Promise.allSettled` to wait for all
   `httpClient.send` calls to complete and construct a `BatchResponse`.
    An `httpClient.send` call to V1 Send endpoint either completes
    with a success or throws an error. So if an error is thrown out,
    the error will be caught in `sendEach` and turned into a
    `SendResponse` with an error.
    Therefore, unlike `sendAll`, `sendEach` does not always throw
    an error for a total failure. It can also return a `BatchResponse`
    with only errors in it.

`sendEachForMulticast` calls `sendEach` under the hood.

* Add integration tests for `sendEach` and `sendMulticast` (#2130)

* Avoid using "-- i.e." in the function comment
@patdx
Copy link

patdx commented Jun 1, 2023

Why were sendAll and sendMulticast deprecated (#2094) and sendEach and sendEachForMulticast introduced (#2097)?

Is there a deprecation schedule for sendAll and sendMulticast? Will they be removed from a future version of the SDK or disabled on the server side?

I tried searching online, including the Firebase docs and SDKs for other languages but having trouble to find any more information about this change. Would appreciate any guidance about this change. Thank you.

@brettwillis
Copy link

Same here. From #2097:

Therefore, unlike sendAll, sendEach does not always throw an error for a total failure. It can also return a BatchResponse with only errors in it.

Is this the only reason for the deprecation? As I catch and handle any errors anyway, regardless of using sendAll() or sendEach().

Especially as per the sendAll() documentation:

Employs batching to send the entire list as a single RPC call. Compared to the send() method, this method is a significantly more efficient way to send multiple messages.

Is there some other context for this decision? Why should we use sendEach() instead of sendAll() if it is by implication significantly less efficient? It seems like a step backwards.

@brettwillis
Copy link

Ah I see there's just been an announcement that the https://fcm.googleapis.com/batch batch send REST API is deprecated and will be removed on this day next year (21-June-2024).

See here:

The batch send methods described in this section were deprecated on June 21, 2023, and will be removed in June 2024. For protocol, instead use the standard HTTP v1 API send method, implementing your own batch send by iterating through the list of recipients and sending to each recipient's token. For Admin SDK methods, make sure to update to the next major version.

And technical info here:

For use cases where end-to-end latency is critical, or where total fanout size is small (fewer than 1 million), Google recommends the HTTP V1 API. The HTTP V1 API over HTTP/2 can achieve up to ~1/3 of total message throughput rate compared to legacy multicast when sending on a single connection.
For use cases where throughput and egress bandwidth are prioritized or where total fanout size is large (greater than 1 million), Google recommends topic messaging. While topic messaging requires a one-time action to subscribe recipients to a topic, it offers up to a 10,000 QPS per project fanout rate without a maximum limit on topic size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants