Currently, the example for strict durability buckets is an offline drafts folder for an email client, but this is not a great usage for strict durability. Using strict durability reduces the likelihood of data loss by a very small margin and the most important effect is that it will confirm that the data has been written. Yes, the data may be saved slightly faster with strict durability, but more importantly, the transaction won't be confirmed until after the disk is modified.
The large majority of applications should never need strict durability, which is why buckets default to relaxed. MDN docs say this: "there exists a small chance that the entire transaction will be lost if the OS crashes or there is a loss of system power before the data is flushed to disk. Since such catastrophic events are rare most consumers should not need to concern themselves further." which I believe is more appropriate because it doesn't encourage the usage.
I am currently struggling to think of a compelling, concrete use case for strict durability that can be used as an example. It doesn't guarantee atomicity in the bucket because storage APIs still don't synchronize. Durability could be used to move data from one store to another, for example if migrating from bucket A to bucket B, the deletion from A should not occur unless B has confirmed writing. However this isn't really a case where the bucket should default to strict; only an individual transaction or set of transactions should do so.
Currently, the example for strict durability buckets is an offline drafts folder for an email client, but this is not a great usage for strict durability. Using strict durability reduces the likelihood of data loss by a very small margin and the most important effect is that it will confirm that the data has been written. Yes, the data may be saved slightly faster with strict durability, but more importantly, the transaction won't be confirmed until after the disk is modified.
The large majority of applications should never need strict durability, which is why buckets default to relaxed. MDN docs say this: "there exists a small chance that the entire transaction will be lost if the OS crashes or there is a loss of system power before the data is flushed to disk. Since such catastrophic events are rare most consumers should not need to concern themselves further." which I believe is more appropriate because it doesn't encourage the usage.
I am currently struggling to think of a compelling, concrete use case for strict durability that can be used as an example. It doesn't guarantee atomicity in the bucket because storage APIs still don't synchronize. Durability could be used to move data from one store to another, for example if migrating from bucket A to bucket B, the deletion from A should not occur unless B has confirmed writing. However this isn't really a case where the bucket should default to strict; only an individual transaction or set of transactions should do so.