[FR][FCM] HTTP2 support for sendEach

[Klemenceo]

Hello,

With the new FCM v1 http endpoints, support for batching was removed. The solution for large volume is now topics (but that leave you with generic messages) and using HTTP2 (just like APNs does) to benefit from multiplexing.

The current implementation uses requests, which doesn't support HTTP2, and uses a ThreadPool as a means of doing concurrent sends, but you still pay for the HTTP layer on each send.

Are there plan to use something like hyperx in the future to switch sendEach to, in order to benefit from http2 multiplexing.

Thanks in advance.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[davidemerritt]

+1 - this has a pretty urgent timeline with the june 20th deprecation of the existing batch send.

[jonathanedey]

Hi Folks,
We are aware of these issues and working to address them.

Currently, support for HTTP/2 in Node.js is underway and our next focus is exploring similar options for Java, Python and the remaining SDKs. We will use this issue to track any progress here.

We can't provide a timeline for the completion of these projects but we are working to have these resolved as soon as we can and appreciate your continued patience as we do so.

[davidemerritt]

Will this be resolved prior to the june 20th cutoff for existing legacy endpoints? This swapover doesn't provide a reasonable migration strategy without this being implemented.

[Tom3652]

I was going to make the same feature request, glad this is a known issue 🙏🏼

[jagerman]

+1 - this has a pretty urgent timeline with the june 20th deprecation of the existing batch send.

Thankfully Google heard the cries of developers of every single firebase-admin-xyz repository pointing out the problems with the migration and came up with a working solution before the deadline. (Edit: this is sarcasm).

[jhkim-grip]

+1 - this has a pretty urgent timeline with the june 20th deprecation of the existing batch send.

Thankfully Google heard the cries of developers of every single firebase-admin-xyz repository pointing out the problems with the migration and came up with a working solution before the deadline.

@jagerman may i ask what solution is that? i can't find it

[jagerman]

@jagerman may i ask what solution is that? i can't find it

That was sarcasm. As for an actual solution, https://github.com/olucurious/pyfcm is probably the option as Google apparently isn't interested it maintaining their tools.

[vivekshah1801]

I was going to create the same FR.

[dpereiraegoi]

Any updates?

[Jay2109]

@jagerman may i ask what solution is that? i can't find it

That was sarcasm. As for an actual solution, https://github.com/olucurious/pyfcm is probably the option as Google apparently isn't interested it maintaining their tools.

So this works ? Has anyone tried this ?

[dpereiraegoi]

This was the worse decision who Google/Firebase made.
The service has become much worse, and confidence in the product has worsened.
when a decision is made so that the service performs again ?

[lahirumaramba]

Hey folks, thanks for your patience on this.

We are looking into optimizing the current API and it looks like adding HTTP/2 support using a library like httpx would be an option.

However, the link to a potential workaround you have shared in this thread provides an async interface with aiohttp (it doesn't seem to support HTTP/2), which got me wondering, would an async API with HTTP/1 in the Admin SDK (for meesaging.send()) address your needs for now?

[Jay2109]

Anything that works , also comment here if we have a possible solution in another language SDKs

[lahirumaramba]

Anything that works , also comment here if we have a possible solution in another language SDKs

@Jay2109 the existing messaging.send() and messaging.send_each() functions work. This issue is for optimizing the existing functions and supporting HTTP/2 multiplexing.

[Jay2109]

@lahirumaramba yeah I am using those methods but I am currently sending more than 20 M notifications, the issue is the cpu usage becomes higher .
So my question was have we implemented an optimised version in any other language SDKs ?

[lahirumaramba]

@Jay2109 oh okay I understand now. We have already added HTTP/2 support to Firebase Admin Node.js and Firebase Admin Java SDKs.

I am using those methods but I am currently sending more than 20 M notifications, the issue is the cpu usage becomes higher

From what I have gathered from profiling, the thread pool in the current implementation is a point of constrain. We could provide an async implementation (in HTTP/1) as an optimization and later look into supporting HTTP/2 multiplexing. I am trying to understand if an async HTTP/1 implementation would support your needs for now.

[jagerman]

From what I have gathered from profiling, the thread pool in the current implementation is a point of constrain. We could provide an async implementation (in HTTP/1) as an optimization and later look into supporting HTTP/2 multiplexing. I am trying to understand if an async HTTP/1 implementation would support your needs for now.

No. The high CPU usage and high number of requests (even with an async HTTP/1.1 implementation) are caused by your decision (not you personally, but your organization's) to remove an API even though your own organization's first party libraries still relied on that API for anything but the smallest scale notification system.

Surely a better solution here would be for you to talk to the other team in Google that caused all this mess in the first place?

I could understand if this were some third party, open source library that didn't keep up with Google's changes, but it isn't: this is a first party, officially supported library that is now nearly two years after the announcement of the removal of the bulk API without a working solution.

And now rather than "here's a working solution to the need to send many notifications, sorry it's late!" we're getting "well, we're nearly two years late, but hey we're starting to brainstorm about implementation of a stop gap that will still be much worse than what you had before."

[lahirumaramba]

@jagerman I understand your frustration.

We have been working on adding HTTP/2 support across Firebase Admin SDKs. So far we have implemented HTTP/2 support in Node.js and Java SDKs (I understand this doesn't address your use case). We have now prioritized the Python SDK.

The alternative library you shared in #788 (comment) uses aiohttp and doesn't support HTTP/2. That is what made me wonder if HTTP/1 async solution is what you are after for now.

Instead of jumping into implementing a solution for Python I am just simply here trying to understand the best approach moving forward to support you. Again, I understand your frustration and I appreciate the feedback.

[jagerman]

The alternative library you shared in #788 (comment) uses aiohttp and doesn't support HTTP/2. That is what made me wonder if HTTP/1 async solution is what you are after for now.

We are using that now for the past few months successfully after the firebase-python-admin library became prohibitive in terms of CPU. It is a more manageable solution in terms of CPU usage, but it isn't perfect and I'd like to switch back to the official library. But I'd really rather that be to a working, more efficient HTTP/2 solution rather than a stop-gap (i.e. I'd rather the effort go into getting working HTTP/2 sooner).

[davidemerritt]

@lahirumaramba - Can you please provide an update here? On February 19th (~2 months ago) you said that this SDK has been prioritized for http2 support and optimizations. We are trying to understand our options of forking this and implementing it ourselves vs waiting on the official support.

[lahirumaramba]

Hey @davidemerritt we are actively working on adding HTTP/2 support using the httpx library. We will provide an optimized async solution that uses HTTP/2 that should address the high CPU usage issues in the current implementation. You should start to see the PRs coming into this repo in the next few weeks. We are unable to promise a timeline for the release but rest assured that this feature is now the highest priority item for this SDK. Thanks for your patience!

FYI: @jonathanedey

[davidemerritt]

Hey @davidemerritt we are actively working on adding HTTP/2 support using the httpx library. We will provide an optimized async solution that uses HTTP/2 that should address the high CPU usage issues in the current implementation. You should start to see the PRs coming into this repo in the next few weeks. We are unable to promise a timeline for the release but rest assured that this feature is now the highest priority item for this SDK. Thanks for your patience!

FYI: @jonathanedey

Great thank you for the update, understanding the rough timeline helps us out.