Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support specifying which replica set to read from #407

Closed
mrfrase3 opened this issue Jul 28, 2021 · 2 comments · Fixed by #409
Closed

Support specifying which replica set to read from #407

mrfrase3 opened this issue Jul 28, 2021 · 2 comments · Fixed by #409

Comments

@mrfrase3
Copy link
Contributor

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.

@DaddyWarbucks
Copy link

DaddyWarbucks commented Jul 28, 2021

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 q
if (params[this.modifierKey]) {
  params[this.modifierKey](q)
}


// Then the user can do anything with the query
app.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.

@bwgjoseph
Copy link
Contributor

Nice, didn't notice that even though I frequent mongoose docs

I think it would be a nice addition and could relieve some heavy read load that doesn't require always up-to-date dataset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants