should the app keep a local (I mean on run time) version of the data
to be responsive and it often updates this local version from the
database but asynchronously or always fetch data from the database
directly (even if we have to wait for the database).
tl;dr: As usual: it depends :-). You need to decide which is more important - consistent, up-to-data data or responsiveness and availability.
What you are describing is basically one of the unavoidable compromises you must make in a distributed system (distributed, because you have a local client and a remote server/database):
- keep data local - more responsive, but risk showing old data, and encountering edit conflicts
- always use remote data - less responsive, relies on server being online, but no risk of old data, less risk of editing conflicts
Basically, this is a special case of the CAP theorem: If you want
- Consistency (no stale data)
- Availability (no errors)
- Partition tolerance (can tolerate server being down)
then you can only have two :-).
In practices, there are various possible solutions.
The simplest to implement is to just always use the remote DB directly. That relies on a good internet connection and the server being online, but is simplest, because you offload a lot of work to the server.
Another solution is to have a local copy/cache of the database, which is synchronised with the server. That way people can work locally, and offline. For example, most Email clients work like this (using SMTP and POP3/IMAP for synchronisation). This is more complex, because of the local copy and the synchronisatioin, but allows the user to decide the tradeoff themselves - work offline, and live with old data, or work online, and get current data.
I would recommend starting with 1), then "upgrade" to 2) if it becomes necessary.
Finally, note that in all cases you will have to account for editing conflicts (unless you only support a single user and session). Two users might load the same entry in parallel, then both edit and submit their edit. This is possible even if everyone is online all the time.
To handle this, you either need to lock entries for editing (user-unfriendly, and requires being online), or have some type of conflict resolution (more complex). Again, how to handle this depends on your application. For ideas you could look for example at how merge conflicts are handled in Git, or use a technique like optimistic locking.
