Thoughts on enforcing fields and retries via driver abstraction?

Working with Data Drivers
,
1

Hi all,

I am looking to get some feedback on the use of an abstraction library that my project has been deciding to use or not for all our microservices using MongoDB. This abstraction wraps CRUD operations with a retry handler for common network/authentication (e.g. commonly SCRAM AUTH, failed to ping database primary, etc) issues that aren’t covered by the existing drivers write/read retry logic and also applies createdAt and updatedAt fields to the document.

I have some concerns about using this abstraction and would like to get some feedback from the community about this:

  1. There is no way to completely abstract the go driver due without implementing bson objects handler for queries, projections, and all other use cases. Additionally, an abstraction is not necessary as there are no need for “alternative” drivers as we use the official Go drivers.
  2. Should we be enforcing schema fields in the library instead of where the library is imported? We are mutating the document without any control/awareness by the caller.
  3. Should we be handling these authentication/network errors differently, instead of retrying?

Thanks in advance for any replies!