You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Been thinking about optimising how my backend handles its connection with the database.
One of the main things you can do is set the read preference to make use of your mongo clusters secondary replica sets for read operations. The main issue with this approach is that the replica sets may be delayed in getting the latest data, so globally specifying to use a secondary replica set is off the books if your application needs to do exact point-in-time finds on some services.
What would be nice is the ability to specify this on a per-service and per-request level. e.g. have a service option readPreference that sets the default read preference for the service, and allow $readPreference to be set in the params of a find/get request to override the default for the service/mongoose.
I'm not certain about other adaptors and whether their databases support replica sets and querying them, what is implemented should be optional for other adaptors to implement, and certainly not break them if someone mistakenly tries to specify the read preference.
I don't mind making a PR for this if it sounds like a good idea.
The text was updated successfully, but these errors were encountered:
After a quick glance, this seems to make sense to me. The service is already similarly handling discriminators and collation. But, I wonder if this is a slippery slope to keep adding params to modify/use model methods. It may be advantageous to do something like
// Take some param that allows the user to// imperatively use the qif(params[this.modifierKey]){params[this.modifierKey](q)}// Then the user can do anything with the queryapp.service('my-service').find({queryModifier: query=>query.read('secondary')})
Also, I wouldn't worry too much about replicating this in other adapters. This is one of those things that is so different between adapters that it should probably just be different in each IMHO.
Been thinking about optimising how my backend handles its connection with the database.
One of the main things you can do is set the read preference to make use of your mongo clusters secondary replica sets for read operations. The main issue with this approach is that the replica sets may be delayed in getting the latest data, so globally specifying to use a secondary replica set is off the books if your application needs to do exact point-in-time finds on some services.
I was looking into this and spotted this in mongoose, basically, you can set the read preference for a specific query.
https://mongoosejs.com/docs/api.html#query_Query-read
What would be nice is the ability to specify this on a per-service and per-request level. e.g. have a service option
readPreference
that sets the default read preference for the service, and allow$readPreference
to be set in the params of a find/get request to override the default for the service/mongoose.I'm not certain about other adaptors and whether their databases support replica sets and querying them, what is implemented should be optional for other adaptors to implement, and certainly not break them if someone mistakenly tries to specify the read preference.
I don't mind making a PR for this if it sounds like a good idea.
The text was updated successfully, but these errors were encountered: