In general you will be fine with reading from secondaries, but here are a few things to consider :

• All members of a replica set will service the read requests at roughly same speed. This is because when you write to primary server, the data is also written to the secondaries. So, you need to check the actual performance benefits you get here.

• Are you fine with stale data (as replication occurs asynchronously)? As this is a dashboard, it's probably fine to have slightly out-of-date data.

• Are these replica sets geographically distributed? If yes, it may be a good idea to set read preference to nearest so that you will read from low latency servers.

MongoDB documentation says that in general you shouldn't use secondary read preferences to add extra read capacity. On the other hand, sharding is often treated as the preferred way to add extra Read/Write capacity as it distributes your reads/writes across different groups of machines.

However, if you choose to read from a secondary machine, it may be a good idea to have the Dashboard as a separate app with read preference set to secondary. This way you won't mix up the dashboard code with the other parts of the main app.

Hope this helps. Please let me know if you have any questions. :)

It is not recommended to limit reads on secondaries.

You always connect to all servers. If you have one on port 27017 and one on 27018 the connection string looks like:

const url = 'mongodb://localhost:27017,localhost:27018/myproject?replicaSet=foo'
MongoClient.connect(url, function(err, db) {
  //...
})

(But a replica set should have an odd number of members)

You can use the connection options to define your read preferences:

const {MongoClient, ReadPreference} = require('mongodb')
const url = 'mongodb://localhost:27017,localhost:27018,localhost:27019/myproject'
MongoClient.connect(url, {
  replicaSet: 'foo',
  readPreference: ReadPreference.SECONDARY_PREFERRED
}, function(err, db) {
  //...
})