Long call to Firestore/Listen is blocking prerender

[Leigh Stewart]

Hi,

Wondering if there's any way for us to prevent the long Firestore/Listen call. We dont use realtime features so I cant imagine what the value of it would be. The prerender service we're using waits for all network connections to close before completing which is causing slow responses. 

Thanks.

[Sam Stern]

Hi Leigh,

When using the Firestore SDks on the web almost all API calls go through the "realtime" endpoints even if you're not using snapshot listeners. Can you explain more about what data you're requesting and how long it's taking?

- Sam

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/62789c8d-8f93-4227-85b5-28ef57b24573n%40googlegroups.com.

[Leigh Stewart]

Hey thanks for the quick reply.

The app is a really simple web app that fetches a bunch of data on page load - think like a few posts and some user info.

All the data is fetched within ~100ms or so, but the connection remains open for 60s. 

Is there anyway way to have it close more proactively when we're not expecting more data to arrive? 

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAHafJBqUJzUO0yw4Gyeef%3DP2xOeo3DXE73y1T9fv%2B8YTcKEqgA%40mail.gmail.com.

[Sam Stern]

Hi Leigh,

I ran a simple JSFiddle to do a set() and a get() on a single ref and I see what you're talking about, there's a request to "Listen" that runs for exactly 60s even when I am not doing any more data operations.

That does seem mildly wasteful but it's never caused me a problem in my (simple) adventures in Web development, can you explain more about what your "prerender service" is and how this request blocks it? Then I'll be able to give your feedback to the right team.

- Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAC_V7svQ56UOgRQ6VzAQnnZYJTaTM9%3DNhqM77TXt%2BV1c2zxecw%40mail.gmail.com.

[Leigh Stewart]

You bet - 

So what that service is doing is loading the SPA up to render the page for a given set of params, and then caching the html result to serve up directly to crawlers and etc that generally refuse to load the SPA. 

The way the service works is that it waits for all network connections to close before capturing the rendered content. Thus it waits for this long connection to close which results in slow responses to these crawlers (we're using it for social link previews).

Hope that helps.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAHafJBq1rQgAKjTpZjoumLq2%3DBR-bbFGX1%2BBUoB_swzUx22Kew%40mail.gmail.com.

[mrsc...@google.com]

Hello,

We try our use of the network as efficient as possible, and part of this is our desire to avoid repeatedly tearing down network connections only to re-open them right after. Since we don't know whether you will send us another get(), we will always keep network connections open for a fixed amount of time. Only if the connection has been idle for 60s will we tear down the connection altogether.

You can avoid this behavior today if you use the Transaction API for your reads. Any documents fetched via `runTransaction(transaction => transaction.get(docRef))` is fetched via an out-of-band HTTP network call that doesn't use our Listen API (but is also bypasses our offline cache). In the future, we are planning to release a "Lite" version of Firesore that only uses HTTP calls, in which case any call to retrieve a document will bypass Listen+Cache. If you are keen, you can join our public Alpha and test `@firebase/firestore/lite` today: https://modularfirebase.web.app/

Thanks

Sebastian

[Leigh Stewart]

Ah ok - totally understand the performance motivation, was sorta hoping there might be some workaround.

This will probably do the trick for now. Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/d98d4beb-8d6e-4d42-9362-5ee6ac2ab368n%40googlegroups.com.