I’m in need of a lightbulb moment, that, once it happens should really free up a lot of brain space.
It’s relates to databases, and server-side rendering versus client-side rendering. Persisting and updating the UI with state and the actual data in the database. How to best leverage tools like local storage, react-context, or another state-management protocol (library). Limiting network requests.
Does server-side rendering really connect to the database and fetch the data every single refresh?
This seems incredibly inefficient.
This is what WordPress and every other server-rendered app does right?
And if you look at the alternative, client-side data fetching, you have to deal with a loading spinner. If you are okay with the spinner you still either need to 1.) make a fresh request on page refresh or 2.) play a complicated game of storing results in state (maybe global), persisting this state in local storage so a page refresh doesn’t re-send a request. You end up with this double source of truth for your data which I think is an anti-pattern. It’s messy.
An example, you pull down a list of 100 items, load into state, and the user needs to edit one in a pop-up modal that pings an API, updates in database and sends back a success response. We don’t need to re-connect to the database to display the updated item we can just update the state. Same thing for add and delete. This seems reasonable. But it would be too much to store this state in local storage just to protect a network request to a database on page refresh.
So yeah, server-side render.
If you are going to go through the work of connecting and fetching data should we just get all of the data or just a little bit and then make another connection for more data?
There must definitely be a point where “pagination” becomes optimal but where this value lies is unclear. For example, by default WordPress gets the 10 most recent posts and not every post in your database.
How does caching effect all of this?
Schema Design of NoSQL versus RDBMS. RDBMS- normalize – don’t duplicate. NoSQL – design scalable schemas by 1.) Embed unless there’s a compelling reason not to and 2.) avoid joins if they can be but don’t be afraid if they can provide a better schema design. community.mongodb.com.