0

I develop a realtime app where every client creates an manages n realtime documents ( its like a bin board app with sticky notes, and every note is a own realtime document ).

In the Realtime Debug Console, I can see that several realtime documents are opened for my single instance of my realtime app.

enter image description here

I looked at this Question to understand what technology Google Drive uses to get real-time updates:

No-polling (what Google Drive does) takes advantage of how the browser can read data from the body of a request before the request is complete. So as collaborators do more typing and edits, the server appends more data to the current request. If certain limits are met (length of the content or duration of the request), the request completes, and the client initiates a new request with the server.

I can see in the Google Chrome Developer Tools -> Network Tab that for every loaded realtime document, I have an open XHR request for every loaded realtime document identified with the GET Parameter fileId and as soon as one times out a new GET request to the server gets created and stays open:

enter image description here

If I now load 100 reatlime documents, I have all the time 100 GET requests ( one for every realtimeFileID ) that stay open and every time when one times out another one gets created as seen here in Google Chrome Developer Tools:

enter image description here

My Question is, I learned that browsers support max. ~simultaneous 10 HTTP GET requests from the same origin but I have here in chrome 100 open requests and every of them is in the Content Download State, whch means for me that I have right now 100 open XHR requests in my ( unmodified ) google chrome browser.

All requests are in the same orignin https://drive.google.com/ only the GET parameters have different realtimeDocIDs

Community
  • 1
  • 1
Viktor Carlson
  • 989
  • 1
  • 13
  • 36
  • You didn't actually ask a question, what are you trying to ask about? Also having each note as a separate document is likely not a good design decision. Consider using multiple CollaborativeStrings inside a single document instead. – Grant Watters Mar 02 '17 at 03:51
  • The problem is that each collaborative string cannot have its own users. Lets say we have one realtime document with n collaborative strings. As I see googles user role management it is not possible to say that: String1 is shared with user1 and user2 ; String2 is shared with user1 and user3 – Viktor Carlson Mar 02 '17 at 09:06
  • Correct. If you need to guarantee permissions for each note/string consider looking at something more similar to Firebase. – Grant Watters Mar 02 '17 at 09:08

0 Answers0