Jarrett G. Jarrett G. - 1 month ago 9
React JSX Question

In an isomorphic Redux app, is it better practice to keep API calls small, or to send over all information in one go?

I am building a sports data visualization application with server-side rendering in React (ES6)/Redux/React-Router-Redux. At the top, there is a class-based

App
component, and there are two different class-based component routes. (everything under those is a stateless functional component), structured as follows:

App
|__ Index (/)
|__ Match (/match/:id)


When a request is made for a given route, one API call is dispatched, containing all information for the given route. This is hosted on a different server, where we're using Restify and Sequelize ORM. The JSON object returned is roughly 12,000 to 30,000 lines long and takes anywhere from 500ms to 8500ms to return.

Our application, therefore, takes a long time to load, and I'm thinking that this is the main bottleneck. I have a couple options in mind.


  1. Separate this huge API call into many smaller API calls. Although, since JS is single-threaded, I'd have to measure the speed of the render to find out if this is viable.

  2. Attempt lazy loading by dispatching a new API call when a new tab is clicked (each
    match
    has several
    game
    s, all in new tabs)



Am I on the right track? Or is there a better option? Thanks in advance, and please let me know if you need any more examples!

Answer

This depends on many things including who your target client is. Would mobile devices ever use this or strictly desktop?

From what you have said so far, I would opt for "lazy loading".

Either way you generally never want any app to force a user to wait at all especially not over 8 seconds.

You want your page send and show up with something that works as quick as possible. This means you don't want to have to wait until all data resolves before your UI can be hydrated. (This is what will have to happen if you are truly server side rendering because in many situations your client application would be built and delivered at least a few seconds before the data is resolved and sent over the line.)

If you have mobile devices with spotty networks connections they will likely never see this page due to timeouts.

It looks like paginating and lazy loading based on accessing other pages might be a good solution here.

In this situation you may also want to look into persisting the data and caching. This is a pretty big undertaking and might be more complicated than you would want. I know some colleagues who might use libraries to handle most of this stuff for them.

Comments