firebase / firebase-js-sdk / 10219

0%

master: 0%

Pull #2349

travis-ci

Setup RTDB connection before auth token is fetched

A lot of (web) apps follow the following pattern:
1. App starts / initializes Firebase SDK (app instance)
2. Authenticates user (e.g: persisted in IndexedDB or otherwise)
3. Queries the RTDB to fetch data for the now authenticated user

In the current implementation here's what happens:
1. SDK reads persisted auth from IndexedDB
2. Makes an API request to Google Identity Toolkit (`getAccountInfo`) (technically it's 2 https requests, because of CORS)
3. Once auth token is received the SDK connects to the RTDB (usually via a websocket)
4. Once the connection is established, any pending queries are now made / sent

Step `3.` is actually quite expensive in practice (in my measurements it takes ~500ms, from Europe)
Establishing a `wss` connection takes 4 roundtrips (1 for TCP syn/ack, 2 for TLS handshake, 1 for HTTP upgrade).

So the time required to establish a (websocket) connection with the RTDB is `4 * RTT`, where RTT is the "RoundTrip Time" between the Firebase RTDB node (which seem to be located in us-east/us-central) and the client (in my case `RTT ~= 125ms` which explains the `~500ms`)
(and because each websocket requires it's own TCP socket, it doesn't seem possible to accelerate this by using `<link rel="preconnect" ...` )

This latency negatively affects the user experience for end-users because it delays their meaningful TTI.

Through my debugging and quick analysis of the code there's no obvious reason as to why we wait to finish the auth to start setting up the websocket connection (given that it takes time). I patched our copy of the Firebase SDK to include the above change and there's no immediately obvious downside or issue.

Am I missing something ? Is there a strong reason why we don't establish connections until we obtain auth tokens ?

---

## Note

The time to establish RTDB connections (to `s-usc1c-nss-{x}.firebaseio.com`) could be reduced without modifyin... (continued)

6679 of 8150 branches covered (81.95%)

Branch coverage included in aggregate %.

3 of 3 new or added lines in 1 file covered. (100.0%)

20688 of 22330 relevant lines covered (92.65%)

4254.21 hits per line