Add option to set API in read-only mode

[wellingguzman]

Adding a option to put the API in read-only mode, we lock all actions except reading data from the API.

We can aggressively cache the result as there's not change to be expected.

[danielfrentz]

How would this option be set? Is it an API call? a configuration option?

[rijkvanzanten]

Good question @danielfrentz.... It can be either a flag in /config/api.php or a flag in the directus_settings table. I'm not sure why yet, but I feel like this is something that I would expect to be in the php config file, but at the same time, it's also that you might want to enable / disable from the user interface, which makes it required to have in directus_settings 🤔

What are your thoughts on this?

[danielfrentz]

I think it can be applied to both. use the configuration to set it initially and then allow the user to set it via the api.

[benhaynes]

I agree that the config makes the most sense, but we should really focus on moving anything that needs to be updated after install to directus_settings so that it can be adjusted through the app/api. Not sure about having it in both – @rijkvanzanten ?

[rijkvanzanten]

Both is going to be confusing.. let’s put it in directus settings.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jaredtbates]

@benhaynes @rijkvanzanten I was about to create a feature request for this, but then I saw there was already an issue for it. I have an odd use case for this feature- we are planning to run Directus 7 with multi-region redundancy on Amazon Aurora MySQL. As of right now, only read-only replicas are supported. Multi-master support is on the way, but it's not something we will want to pursue due to complexity. Since we will be hosting an instance of the API in two different regions for redundancy, we'd like to have the "master" region (with the writeable master database) host a writeable copy of Directus, while have the "slave" region (with the read-only replica) host a read-only copy of Directus. The only way to do this is through a config file setting, and not through the database, since the database contents must match in both the master and the replica.

Do you guys have any thoughts? Does my use case make sense? Thank you!

[rijkvanzanten]

@computerwizjared This makes total sense 🙂 It also means that read-only should be just that: no writing to directus_activity for logins or stuff like that either.

[jaredtbates]

@rijkvanzanten Wonderful!! For now, we'll continue down our path of upgrading to Directus 7 with multi-region support, regardless of this feature, since our application is read-only anyways. However, it would be awesome to be able to enforce this from the Directus API perspective so that we can be sure no writes will ever hit the replica database. If, in the future, we would need to write to the Directus API, we would put a direct endpoint in our app to that instance in the "master" region.

Another possible idea that would work for our use case is to have a database endpoint in the config for a writer database, and another for a reader, so all reads would hit the reader database, and all writes would hit the writer (which would be located in the "master" region). This would probably be an idea for another ticket, though.

Let me know if you have any questions about our use case; I'd be happy to answer any. Thank you!

[rijkvanzanten]

Another possible idea that would work for our use case is to have a database endpoint in the config for a writer database, and another for a reader, so all reads would hit the reader database, and all writes would hit the writer

I really like what you're suggesting here. We've been playing around with hosting Directus multi-tenant on a pretty big scale, and this could help out performance / prevent bottlenecks in a major way as well. @benhaynes 🔔

[jaredtbates]

@rijkvanzanten That's sweet. Yeah, we're not hitting any scaling issues in our use case (a basic website CMS), but the redundancy is something we're aiming for in case of an S3/RDS/EC2 outage in our primary region. The latency reduction using Route 53 geo-routing is a nice side benefit too.

RDS provides a reader endpoint that load balances among all reader database instances, and a writer endpoint that hits the primary writer database instance, so it would be great to be able to utilize that.

[benhaynes]

Ooh, I like that too. In my head I was imagining this setup as two "projects" (different databases), but many people will keep these in sync, so keeping it within the same project also makes sense. 👍

[benhaynes]

To achieve better clarity/visibility, we are now tracking feature requests within the Feature Request project board.

This issue being closed does not mean it's not being considered.