Supabase
Replies: 2 comments 4 replies
-
|
The dashboard has been incredibly slow for me the last couple of days. Is it normal that the Dashboard tries to refresh its access token after every single request? It severely slows down the other important requests.
This is how the request log looks like when using Chrome on Arch Linux. |
Beta Was this translation helpful? Give feedback.
-
|
Just tested it on my Mac and everything works flawlessly. This is somehow a problem on my Arch system, though I have no idea what causes it. |
Beta Was this translation helpful? Give feedback.
-
|
Can you go to time.is on your Arch system and see what it shows? |
Beta Was this translation helpful? Give feedback.
-
|
Ohhh you're right, my system time breaks when I dual boot between Windows and Arch, that makes sense. That will probably fix it, thank you very much 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Yeah half of all auth-related issues are clock-skew. 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
@hf |
Beta Was this translation helpful? Give feedback.
-
You might be wondering what we've been up to the past few weeks when we'd usually have some cadence in our weekly updates with our GitHub discussion updates - the team at Supabase had decided to commit to a month of consolidation by putting our efforts into each of the following pillars: Alerting, Testing, and Scaling. Let's jump right in to see what this means for the Dashboard! 💪🏻
🚨 Alerts: Enabling proactive resolution to issues that users run into
We want to find out about bugs before you do. In an effort to lower the time between deploying a bug and fixing it, we’ve set up some alerts that will enable us to be more proactively catch bugs, in particular for show-stopping problems (e.g that awful “A client side exception has occurred” screen)!
This includes any errors that will completely prevent you from using the Supabase dashboard.
Having a custom error boundary also allows us to potentially provide contextual hints/resolutions to the problem faced, such as what we did in this PR.
🛠️ Testing: Identifying and covering critical points of failure
We believe in ensuring that minimally our critical paths are covered by tests as opposed to ensuring our dashboard has 100% test coverage. Anything that might completely block our users from doing what they need to do should be caught as much as possible before reaching production.
We’ve revamped our current test set up to use Vitest instead of Jest and have integrated Mock Service Workers (MSW) and next-router-mock. These are all to support writing better tests easier, and also to reduce the amount of configuration we need to set up the tests.
We previously had a couple of Playwright tests written over in our tests repository that we’ve decided to shift over to our main repository. We’re also in the midst of writing more tests and making them public
📈 Scaling: Supporting bigger workloads as the project grows
The dashboard should be able to keep up with your projects, no matter how big they grow - and even if unable to, it should never block you, or leave you feeling confused. This effort involved several solutions: gracefully failing if unable to handle large workloads, better observability, or even just better error handling to allow our users to self-service most errors. We were able to get improvements out for several common issues. Check out each individual PR for more information 😄
We’re now limiting rendering each text/JSON based column data in the table editor at a max of 10kB when initially viewing the table, which should alleviate browser performance issues when rendering tables with large row data. You may load the entire column data on demand instead.
A limit parameter will now be added as a suffix to select queries that are run in the SQL editor, which should prevent the browser performance from degrading when trying to query too much data. The limit parameter can be optionally removed if your intention might be to pull data in greater quantity.
This came in response to a user who accidentally ran a large query through the SQL editor which ended up in the API request timing out, giving the impression that the query stopped running when in fact it was still running on the database in the background. This should help surface such problems and give the tooling required to abort erroneous queries.
While the attached PR was more of a POC, this is the direction we want to move towards to by providing contextual information and suggest possible resolutions whenever users run into an error
Of course consolidation is not a one time event, but an ongoing effort that our team is committing to in parallel to shipping new and exciting features. We hope that as our users, you will all be able to benefit from this with less blockers to keep you from building cool stuff 🙂
As always, if you have any feedback for us - we're just a message away through the feedback widget to the top right corner of the dashboard! We're always listening 👂🏻 (as in reading 👀).
Beta Was this translation helpful? Give feedback.
All reactions