mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 17:35:10 +03:00
Joshen Lim
dfd5461ef9
## Context Part of dashboard scalability project Opting to use the connection string of the project's read replica (if available) for read queries on the database. Trialing with the Table Editor as a first pass - changes involved will opt to use replica connection string for `useTableRowsQuery`, `useTableRowsCountQuery`, and `useForeignKeyConstraintsQuery` There's definitely optimizations to be done for deciding which replica to use - but am starting off with a rather naive logic to prioritize replicas in the same region as the project. ## Changes involved - We're no longer passing `connectionString` as a param into the affected hooks, the `connectionString` is derived from within those hooks instead - Change is feature flagged, so things should be status quo if flag is off (use primary database's connection string) - Added `useConnectionStringForReadOps` hook which returns the replica's connection string if (Otherwise defaults to primary database connection string) - Feature flag is on - Project has a replica available ## To test - [ ] Verify that the table editor works as expected for a project that has read replicas (There shouldn't be any change really) - [ ] Also just double check that updating cells in the table editor works as well (There's no change there, we're using the primary DB's connection string for mutation ops) - [ ] ^ Same thing for a project that doesn't have read replicas - [ ] ^ Same thing for local / self-host
Styles
When to write custom styles
Tailwind should be sufficient to cover the majority of styling needs. We typically only write custom styles here in the event where we're working with an external library and we need to override some styles (e.g Monaco, or even our own UI library).
Ideally, keep custom styling here to a minimum, use tailwind directly in the pages and components where possible, so that we have less code to maintain.
If you're writing custom styles
Group custom styles into separate stylesheets based on their context. For styles which are generic and global, we can write them in main.scss.