1

Design 1: For a web application. In the past, if I insert a record/data in UI, I will save this new data to the database, then the UI will be reloaded (like clicking browser refresh icon), but this UI reloaded action will query the database again to fetch all data into UI. I know this will slow the web application performance.

Design 2: Now, I heard this 'caching' idea. When we run the web application at the beginning, I load all data which is fetching from the database into a variable (Let's say 'CacheVariable', so this variable contains all the data I need for the whole UI of the web application). Now, If I insert a new record/data in UI, I will still need to insert this record/data to the database. But now, instead of reloading UI to get updated data from the database. I just insert this new data/record into 'CacheVariable', so my UI can get the updated data without reloading page. The problem is, every time, when I do CRUD actions, I need to remember to update 'CacheVariable', otherwise, I will get the UI bugs. Let's say, I have 100 fields in my UI, then every field has its own CRUD actions. This is I need to do 400 (100 fields * 4) times operations on 'CacheVariable', which I think is not a good way.

Disadvantages of Design 2:

  1. If I refactored my 'CacheVariable', I also need to refactored 400 times for all CRUD on 'CacheVariable'.
  2. Since every field needs CRUD actions on 'CacheVariable', sometimes I will forget to do that, which will cause UI bug. It also will be an error-prone idea since I have to do 400 times.
  • "I know this will slow the web application performance." did you actually measure this or are you just guessing? – Lie Ryan Aug 18 '17 at 4:08
1

There is a tradeoff that you correctly identified between design 1 and design 2, so your decision has a lot to do with that tradeoff. Simplicity vs. usability.

Design 2 has an additional flaw that if somebody else makes a CRUD request, other clients won't be informed. Design 1 will at least get fresh data every time the client tries to make a CRUD request, but design 2 probably needs to be periodically invalidated and refreshed from the backend (or rely on the user hitting refresh to get new data).

However, some of your concerns about design 2 can be mitigated using design patterns. You can use the repository pattern to abstract your CRUD calls an optionally cache data locally. Using the pattern, you don't necessarily need to "load all data which is fetching from the database into a variable". Your cache can be lazy and load data when it's required. Additionally you can configure your cache to have a expiration on data, so it will periodically fetch the latest from the database. See this post for a potential implementation in JS.

  • I know you mentioned simplicity and usability tradeoff. Which one will be chose in industry by most developers? – FullStackDeveloper Jul 4 '17 at 12:38
0

I had a situation like yours. But I'm using React and Redux to control the state of my application. The idea that you described 'CacheVariable', I implemented with state of my component. The state attribute has all my CRUD list info (all lines of my table for example). And when I edit some record, and send the submit to server, and off course, receive the answer. I dispatch the update of this state 'node' with the new information. Then all components that signed this state (like your variable) (ps: when I talk about signed, you can think as a lot of listeners that told me that when this state was updated, I will send the new value like a broadcast). And in my table component, I have one action that is triggered with 'broadcast' info. And this action will update the table record (update, delete or insert).

Actually I posted the doubt here, but I just implemented this idea, and it's working, now I'm waiting for some answers to evaluate if I can improve the implementation.

  • 1
    Yeah, I think this is where the Flux/Redux (I'm currently using Vuex) pattern is going to take care of most of the consistency concerns. I mean if it's good enough for FB, probably should work for most of us. – Evan Zamir Aug 17 '17 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.