Server Timestamps

[louisameline]

Hello, I see no trace of Firebase.firestore.FieldValue.serverTimestamp() in the code and it seems that the library generates its own updated_at etc. with Date(), am I missing something?

If that is actually the case, it's too easy for the user to change the date on his device and cheat the system. Although of course the real security is using a Firebase function server-side for those who want to go that far.

Also, I could pass a Firebase.firestore.FieldValue.serverTimestamp() myself as a value of a property, but I'd rather expect to pass something like %serverTimestamp%, it would synchronously use the user's device time to fill the state, but asynchronously get the real timestamp back from the server (and update the state with this real value). Besides, I don't feel comfortable using Firestore objects myself, one of the points for me in v-e-f is to have an abstraction of Firestore.

Thank you!

[mesqueeb]

@louisameline Sorry it took a while to get back to this issue....

Originally I was using serverTimestamp for created_at and updated_at, however I changed this behaviour to only new Date() instead.

The reasoning was explained in the release notes of version 1.26.

In a nutshell the reason was because Firebase onSnapshot listener executes a changed event after each write that includes the serverTimestamp.

This means that the front-end app would refresh the entire object with the object from the server again once after each single change (because of updated_at). Not only does the dev get charged double in this case, but it also caused some trouble with rapid changes to the front-end.

One example of such a case was in my own app, where a toggle switch had its state saved as toggle in firestore.
When the user flips the switch once and it does toggle = !toggle, and then one second later he flips it back, in the same time the toggle is flipped locally, the serverTimestamp had resolved and overwrites the local state again with the then already older state. Meaning for the user it looked like he flips a switch, but it automatically goes back to its original state.

This was the main problem of serverTimestamps so I opted for not using them at all.

For version two this is one of the things that will require careful architecture because of optimistic UI, and I haven't figured out the best way yet. However, I do think that in version 2 I will include a default update_at field any way.

[louisameline]

I understand your reasons.
However, I wish in the future that we provide an option to take the freshness of the data into acount, to prevent unnecessary reads and bandwidth.
It's the db.collection("cities").where("updatedAt", ">", lastUpdateWeAreAwareOf).onSnapshot(...) I talked about in issue #270
It will require an accurate updatedAt server-side timestamp, and although it will cost 1 more read at the time of the update, it will save much more than that afterwards.
We can leave this closed, we'll discuss it later somewhere else!