Many requests are queued - http2? Something else?

Parse Server 📡
#1

Hi All,

Enjoying parse so far. We’re using it for our mobile apps, but I’m working on a dashboard for the web. I’m using React (barely relevant), so each component fires off a request (using the parse js sdk) for stuff it needs.

I’m noticing queuing of these requests by chrome, where it’ll wait until enough have finished. This means a fairly big delay for the last thing to finish loading and display.

My limited understanding of this stuff would be that what I’m seeing is Chrome’s blocking. Our server is running on Sashio (or locally during dev of course), and I’m wondering how I’d start to use http2, which would greatly improve the blocking situation.

Any help would be appreciated, or any other ideas would be great to hear.

Thanks,
Sam

#2

I am not sure if it is http2 related. Do you mind to share the code that performs the requests. Also, if you need to do a large amount of queries, I’d rather create cloud code functions to aggregate the queries and therefore reduce the amount of requests.

#3

I’m unable to share the code because its not trivial to do so. Let write out the example:

Imagine you had 50 parse Users. And you made a dashboard with them. Each user would be represented in a react component, and that component would fetch more details about the user from another related object.

This would mean I have 50 requests to parse-server, and as they loaded, the newly available data would be added to the view.

It’s a common react pattern to separate concerns like this and therefore separate the requests.

It’s not that I “need” to do a large number of queries, its that my application does one at a time as it needs them, but it happens to send off a lot at the same time in this user overview screen.

If I was to aggregate them in a cloud function, then every user view would need to wait until they were all, and so that’s not as efficient as it could be, because you can run them in parallel, also it would mean a non-trivial restructure for this codebase and breaking separation of concerns, but I could be wrong.

HTTP1.1 in chrome limits to 6 concurrent requests. You can see the problem in the waterfall view of the chrome inspector. HTTP2 is much better at dealing with this (just open facebook for example)

Screen Shot 2020-12-03 at 5.10.06 PM
Screen Shot 2020-12-03 at 5.10.06 PM2864Ă—1398 659 KB

Thoughts?

#4

Separating concerns is a good practice but it is even more important to think about your application performance and your case is a good example. For what I understood about what you described, you can probably retrieve all this data using a single query (or few ones). In my opinion the solution that you are looking for is not only http2. Even if you send all these requests at once to the server, you will probably find other bottlenecks in the server side. I’d try to either separate the data access in a component that brings the data with fewer requests or a more complex solution in which you have some component aggregating all the queries that is needed. For example, Relay and Apollo Client do something like this for GraphQL.

1 Like
#5

Hmm, okay I’ll think of ways to try batch these requests into a single call (I see the SDK doing some batching from the time to time - is there a way to manually do this? Looks not to me)

Our backend is powerful enough (and I can scale this too) that HTTP2 is still something that appeals to me. Out of curiosity - how would one start on that?

#6

As long as I know the SDK only automatically batches requests when saving objects. There is a Parse.Object.saveAll() and also the SDK takes care to save all dirty related objects. I believe that’s probably what you see in the requests.

For start using http2, you actually don’t need to do anything special in your code. If both the browser and the server support http2, it should be automatically used.