Server connect loading order/design advice needed

Quick question, I’ve got a content page with a bunch of server connects. For example:

  1. Get lecture downloads (1 table, pdf files with their names, so I can get them from DO Space)
  2. Get lecture information (1 table, title, description)
  3. Get lecture quiz (2 tables: questions/answers + the answer the person already gave beffore)
  4. Get lecture assignments (2 tables: assignment info + answers the person already entered before
  5. Get lecture rating (1 table, rating value the person gave)

Now which of these 2 ways is a better design practice?

  1. Loading them all separately like: image

  2. Use one ‘init’ server action, which in turn loads library actions like so:

I thought #2 would be better, one action for the same goal: loading all the things I gotta load when opening this new lecture/content page.
But after reading on the forum some things from @George and @JonL : “make everything have a single purpose” I’m starting to doubt. sorry, might be putting words in your mouths that you’ve never said, that was what I seem to remember

Usually the way I choose, is how often the individual datasets will need to be refreshed. If very rarely, that suggests single call as the overhead is reduced. But if the pieces might need refreshing, then individual calls so as not to constantly refresh data that hasn’t changed.


This :point_up:

1 Like

@mebeingken Okay, so in this case the data doesn’t need to be refreshed.
A user loads the lecture + all the data that belongs to it, and it’s not going to change based on user input. Some things are, but I can update them in the db, and show on the page immediately. Don’t need to query it from db again. So then the answer is a single call as in my ‘init’ call, correct :smiley: ?

Is there a big ‘overhead’ saving (actually, I’d rather have you teach me ‘how to fish’ and figure out how I can measure the difference in overhead?)?

I actually take a different approach on this. If I update data that is displayed to the user, I typically will refresh the server connect for that data rather than relying on the data that was in the presented form. Reason being that I want the user to see if there is a problem. Nothing worse than thinking you saved something only to find out it didn’t really take. Obviously, this is not a hard and fast rule, but it is definitely something I consider when laying things out.

For a few server connect calls, the difference will not be huge, but as pages get more complex it all adds up. Have a look at the dev console waterfall on the network calls it will tell you what you need to know. You can see when server connects are delayed until others finish, etc. The time the request is Waiting or in Download is the meat of the call–the queries performed on the server, processing and downloading the response. The Scheduling and Connection could be considered overhead. I’m sure there are some much better explanations out there though!

All that being said, I also advise to not let things like this get in the way in the early stages. I see people all the time worrying about optimization during the development of an MVP and I feel it is just unnecessary. Optimization happens when the application has proven its value and you are ready to scale. Until then, it is all about proving value through user adoption and shaving a few hundred ms off a page load is usually not the biggest issue. So of course, spend a little time to try and get things right out of the gate, but don’t get bogged down by this stuff.