Overview of when an app should read/write to/from the database and State?


I’m not sure how to ask this or where to find relevant information on it… I don’t have a CS background. I am doing a React app, and this is the first time I’ve hooked it up to the backend API i created (it’s the Voting App).

My question is about when to read from and write to the database.

  1. When the app first loads it will display all the polls in the database, so it has to retrieve all the documents at that point, and I guess load them into the main state.
  2. Let’s say a user clicks into a single poll… that data is in the state (we just retrieved it in the previous step) and clicks edit, makes a change and clicks save, does that ‘edit’ component that has the edit function push the update to the parent component that stores the main state, to update that object, by calling that parent’s ‘save’ function to save the whole of the state (all the polls) back to the database? or should the edit component keep track of that single poll in it’s state and push that poll directly to the database? This seems more efficient than saving all the polls back to the parent and then sending the whole massive object back to the database… but then I also see how keeping the one true source of data in sync on the parent is useful.

I’m very confused and have no point of reference for what is standard procedure… is there a basic guide/overview somewhere on this sort of thing, kinda standard procedure for how an app should function?


Think I’ve got it, these are my notes… comments anyone?

Working with a DB and State.

  1. On initial page load, retrieve data from database into State. Either full db, or a subset of data, or just certain fields in order to display a list for example, i.e. the minimal amount of data to display the view you want.
  2. On edit or save, the db returns the json representation of that updated/added object.
  3. You use that returned json to replace the existing object in state (if updating), or append that object to state (if it’s a new object. This way the state stays in sync with the db, and by using the version returned from the db you know you’re updating correctly from the one true source of info.
1 Like


That sounds like a nice DB/State… similar to what i have done myself for that FCC app…

I just want to point out an “alternative”… don’t wait for the DB retrieval to update the DOM/State… this would be a good solution to avoid allowing the user to interact with an “old” version of the state… in my APP’s i will normally update the DOM when i sent the API request (post/put) and if any error occurs i revert it back. I am not saying its the “right” way to do it, but if for example the DB takes to long to respond your users may be doing some other requests based on “old” information.

I think the “balance” between how to uses these DEV decisions is key to a stable WebApp and makes this field a very interesting one to learn :slight_smile: .


Thanks Sergio, that’s a good point, hadn’t thought about that.

These are all design decisions I guess you would know from a computer science background?

Electronics degree myself… not CS but Telecom’s and Robotis (a loooong time ago)… but i have been a developer for +10Y :stuck_out_tongue: (mostly C++,Java and SQL)… backend stuff.

Since i never developed for the Web… I thought i could learn here in FCC… and i have been eheh