Currently, the default behavior of this extension is sending every read query to the replica(s) and every write to the primary. While you can opt-in to using the primary with $primary() , it's default is to always use the replicas for any read. In my opinion, this is a dangerous and unintuitive default, as replication lag could cause unexpected behavior for users if they immediately try to access a newly inserted row after a write.
To mitigate this, a safer default would be to send all reads and writes to primaries by default. This way, there is a guarantee that the reads after writes will always be available. When the user wants to explicitly use replicas, they should call the $replicas() method and chain their queries to it, so this way they are knowingly opting into relaxed consistency and accepting the replication lag that comes with it.
For reference, this is how a lot of other frameworks/ORMs do it. See Django and Rails for example.
Currently, the default behavior of this extension is sending every read query to the replica(s) and every write to the primary. While you can opt-in to using the primary with
$primary(), it's default is to always use the replicas for any read. In my opinion, this is a dangerous and unintuitive default, as replication lag could cause unexpected behavior for users if they immediately try to access a newly inserted row after a write.To mitigate this, a safer default would be to send all reads and writes to primaries by default. This way, there is a guarantee that the reads after writes will always be available. When the user wants to explicitly use replicas, they should call the
$replicas()method and chain their queries to it, so this way they are knowingly opting into relaxed consistency and accepting the replication lag that comes with it.For reference, this is how a lot of other frameworks/ORMs do it. See Django and Rails for example.