It depends. I assume that a note-taking app mostly involves reading, viewing, organizing, searching, etc. my notes. Then I’ll create and edit notes too. That’s still not a write-heavy application.
A write-heavy application is more like an ETL system. Something that is constantly streaming data in, transforming it, and updating or inserting records. There is very little reading going on there. So a replica database isn’t of much use anyway. Everything needs to happen directly on the writable DB because it’s a constant stream of inserts.
I updated the fly_postgres README to add two sections. “Backup Regions” and “Ensuring a Deployment in your Primary Region”. These are to try and help others address the issues you encountered. Thanks for helping to make it better!
Another update to fly_postgres brings it to v0.1.12!
This fixes and simplifies work around the local dev and test.
Important README documentation was updated around config.
Updated section on “Production Config”. Mostly just consolidating and cleaning up the instructions.
Added section titled “Releases and Migrations”. This may only be required for umbrella apps… not sure. Would appreciate feedback around this change NOT being used and success deploying non-umbrella applications. It was certainly required for my umbrella app!
@abreu.jamil, this removes the need for setting DATABASE_URL ENV when in dev and test environments.
I also removed the multiple lines of debug logging you asked about. That part of the code was refactored and doesn’t work the same way now.
I’d love to get any feedback on how it’s working for you! Any problems you’re encountering, etc.
I also see duplicated logs when a non-primary instance RPC’s the primary instance.
I think this is OK though
It seems that linked processes on another node simply have their own log “stream” (I don’t know the correct word).
The RPC’d process is simply providing logs to all relevant nodes. Call it a feature
