I’ve been building an app with supabase as backend for past few months and have been observing that in the past week there has been a surge in my bandwith and requests(Screenshot attached). For reference the free hosting plan allows 10,000 requests and 1 GB bandwith & it was good for me(i’m on the partner plan on weweb) but in the last one week i’m seeing 4000 requests and 200 MB of bandwith being used in a couple OF HOURS.
Some Facts with knowing :-
-i’m on the partner plan with front end only hosting since i’m using supabase as backend
-the app is being tested right now across 5 users only.
-The app is primarily data based without much media(there pdf generation happening via supabase edge function but is displayed on the front end once generated, there are a few images in products and user management tabs and we are using charts.js plugin for analytics)
-we are using low fidelity images upload and size optimisation of pdfs(not more than 1 mb)
-we are using auto fetch collections and preserve on navigation on weweb wherever possible
There are several areas that i think might be causing this and i’d want your input if i’m in the right direction. Please also advise if i’m missing any major areas/architecture flaw that could be suddenly causing this :-
Everytime a fresh user signs there will be a spike as the browser downloads the whole app once
Charts.js might be consuming a lot since there is no preserve navigation there
Pdf being displayed on the front end (even though the generation and logic happens in supabase)
Overall, what is a well optimised architecture expected to consume in terms of monthly bandwith per user ? I ask this because with supabase being good for thousands of users and 250 GB egress, weweb’s 10 GB bandwith(front end only plan) seems incompatible
If not, can you give it a try and report back? On my side, I’ll ask the tech team if they have other tips to help you investigate what might be going on.
Yup, that’s exactly what i’m doing currently. Running a few scenarios and observing the bandwith and requests for each via network tab and the monitoring tab on weweb:-
What happens when a new user signs in for the first time
what happens when we publish an update (with 1 and 10 users respectively)
Disable the cache and see the top 5 highest consuming requests
But can you help me with these two questions :-
What exactly counts as a request? Cause the network tab shows a few hundred requests while the monitoring tab shows thousands. Are there any requests that bypass my network tab?
For a well made app what is the bandwith one should expect to be used even on a new sign in (i.e. when the app loads for the first time on the user’s browser)
@Joyce
Also, on a parallel note i noticed a bug which i have reported related to hosting. If i add a front end only plan to the partner plan then some of my partner plan permissions get revoked like :-
I can’t stage anymore because weweb think’s i’m on the front end only plan and somehow forgets that i’m a partner also
No single click rollback to a previous version that was in production.
Funnily, other projects that come with the free hosting plan have the above mentioned features (which is how i know its a bug) - Attached screenshot shows weweb showing 3 projects as ‘partner’ while one being shown as ‘front end only’.
It looks like you’re not seeing user growth, but rather an increase in the number of requests per user.
This is most often caused by auto-fetch in WeWeb: a single screen can fetch the same collection multiple times (transitions, tab returns, component reassemblies).
Also check:
Are there any repeated calls to the Edge Function for PDF each time the page is opened?
realtime/subscriptions (sometimes they are duplicated and maintain connections)
Is the Supabase client being recreated during rendering?
“Preserve on navigation” doesn’t always prevent refetches if a component is remounted.
Supabase logs usually immediately show that if the same endpoints are hitting dozens of times in a row, it’s a front-end issue.
Anything reaching your backend for backend, anything reaching your frontend for frontend. In other words, 1 entry in the network tab = 1 request either front or back.
Yes, bots for example reach any public websites and can cause surge of request & bandwidth usage.
I guess that depends on the number of data sets you are fetching on page load. Where is the user redirected when they sign in to your app at the moment? Is it to a page with loads of different datasets and/or workflows?
@Joyce@Hask1996 You guys won’t believe this but nothing was wrong with my build. The reasons for this was “Disable Cache” option in network tab in dev tools. The whole time we were testing the disable cache was on on the one laptop we were testing.
But this brings out an interesting question - Can a user of a web app just simply disable cache and drive the bandwith to its limits? Are there no checks on the weweb server end?
Like in my case the free bandwith and requests got exhausted in an hour instead of a whole month - Shouldn’t this have triggered some kind of API rate limiting or some check ?
