PricingBlog

Why session value takes too long to load?

  • uunicode-1274310112143609866

    unicodes

    1 year ago

    In the login page I save the user ID in the session to easily perform checks on the website. After the value is stored in the session, the new page is loaded where I retrieve the user ID from the session and make the main query to load the main information for that page. It fails because the API loads faster than the information from the session. I tried to display the session value, and initially, it is null, then it loads the value. Why is it null for 0.3/0.5 seconds before loading the real value? Shouldn't it be real-time since it is saved in the session (on the browser)? Delaying the main query for 0.3/0.5 seconds to allow the session to load would increase the page loading time too much. Is there a solution to retrieve that value instantly? I tried in the loading page event save the session in a variable, than calling the API with the value from the variable and it works, but takes much time to load the page.
  • andreasmoller-1274364569854283777

    Andreas Møller

    1 year ago

    Are you using the Set Session Cookies action ?
  • uunicode-1274413520015855636

    unicodes

    1 year ago

    Yes
  • uunicode-1274413785079222368

    unicodes

    1 year ago

    But for id I use "Set to Session Storage".
  • andreasmoller-1274414036225888367

    Andreas Møller

    1 year ago

    Do you wait for the cookie to be set? Set cookie triggers an event when it is done
  • uunicode-1274414459166920706

    unicodes

    1 year ago

    It has a lot of time, because after I'm calling an API and waiting the success o that API to "Go to url".
    1274414458482982964-Screenshot_2024-08-17_at_20.07.13.png
  • uunicode-1274415215374503957

    unicodes

    1 year ago

    But the ideea is that user_id is saved in Session in the login page. I'm using it just in the new page, which means that it is already saved in the session. I tried to add a delay of 1 second, but the issue persist in the new page of loading the information from session.
  • uunicode-1274415500096442459

    unicodes

    1 year ago

    I can not understand why in the new page session is null, than after 0.3, 0.5 loads the real information.
  • In the new page, shouldn't 'Get from session storage' be instant since it was already set on the login page?
  • uunicode-1274416400168915110

    unicodes

    1 year ago

    this is what happen in loadiing
  • andreasmoller-1274416458155425936

    Andreas Møller

    1 year ago

    Ahh sorry I misunderstood, I thought this was an issue with session cookies
  • uunicode-1274416524773556408

    unicodes

    1 year ago

    1274416524534222888-Screenshot_2024-08-17_at_20.16.07.png
  • andreasmoller-1274416559799926866

    Andreas Møller

    1 year ago

    I just realised you were using SessionStorage 🙂
  • uunicode-1274416801866055822

    unicodes

    1 year ago

    Yes, I can not understand, considering it was set in login page and stored in the browser, why it is null for 0.5 seconds and not instantly a value considering is local.
  • andreasmoller-1274416898372800622

    Andreas Møller

    1 year ago

    Two things to be aware of with session storage.
    1. The value will not correctly be shown in the editor, since the editor runs on a different domain than your app and therefore different store
  • 2. It is not available server side
  • uunicode-1274417242796195841

    unicodes

    1 year ago

    Is the same for published.
  • andreasmoller-1274417417426178119

    Andreas Møller

    1 year ago

    What are you using the value for ? Are you rendering it on the page?
  • uunicode-1274417833652256808

    unicodes

    1 year ago

    I'm using this value for making the main query for loading the main information on the page. This is why I need this id to be available "instantly" because any delay of storing the informaiton in a variable, creates a delay in loading the main query. I solved the issue by assigning the user_id in in a variable in the loading step. But this creates a delay.
  • But this creates a delay
    1274417986748289054-Screenshot_2024-08-17_at_20.21.46.png
  • 1274418192433020959-Screenshot_2024-08-17_at_20.22.43.png
  • The ideal would be "Get from Session Storage" but it doesn't work because of the null for 0.5 seconds.
  • And for making it working I have to refresh 2 times after loading the page for the first time.
  • andreasmoller-1274419298198360105

    Andreas Møller

    1 year ago

    It sounds like the issue you are having is that you are trying to load a value from Session storage during the initial render on the server.

    The is also when variables are initialised and when APIs with autofetch are called.
  • Since the session store is in the browser this will return null.
  • uunicode-1274419556189995118

    unicodes

    1 year ago

    Yes, because I'm using SESSION as global variables in order to pass information across all the pages.
  • andreasmoller-1274419783798099978

    Andreas Møller

    1 year ago

    Yes, that only works on the client though.
  • So if you do that you cannot use APIs with autofetch
  • And it also won’t work for initialising variables
  • andreasmoller-1274420474075418758

    Andreas Møller

    1 year ago

    I think Erik just rolled out support for setting cookies. But I am not 100% sure it is live yet
  • uunicode-1274420900598513779

    unicodes

    1 year ago

    Cookies would be available immediately? Because for my needs I know only two solutions "SESSION" and having the value in the URL, but there is no way that I know for getting information from URL.
  • lucasg-1274421053950656522

    Lucas G

    1 year ago

    Not setting, only reading for now
  • andreasmoller-1274421058077851648

    Andreas Møller

    1 year ago

    Session storage is also available immediately, they are just not available on the server
  • lucasg-1274421127749308487

    Lucas G

    1 year ago

    Unless he made another sneaky update
  • uunicode-1274421399620026464

    unicodes

    1 year ago

    Would be great having in future "Global" variables, stored in the server for accessing information across all the pages instantly. Like (user avatar, url, name, etc).
  • lucasg-1274421422059556905

    Lucas G

    1 year ago

    Where is the information you are setting in session storage coming from? Another API?
    If so, why not use that as your data for the initial fetch
  • uunicode-1274421530897420338

    unicodes

    1 year ago

    Come from the main login API. It is set up in login page.
  • lucasg-1274421540896768081

    Lucas G

    1 year ago

    This would require toddle to become a pseudo backend which I don't think they'll do
  • lucasg-1274421862927040556

    Lucas G

    1 year ago

    For getting info from URL, you can use the Parse URL node
  • uunicode-1274421944317382767

    unicodes

    1 year ago

    And for setting up?
  • ahh is just a concatenate
  • uunicode-1274422366369218560

    unicodes

    1 year ago

    💡 I can create my own "SESSION storage" in the data base. A table with three columns (ID, name of the variable like "user_id", and the value).
  • But is risky because are available out of local 😕
  • How you store information very important to access it immediately?
  • lucasg-1274422895497449522

    Lucas G

    1 year ago

    Your tables should all have RLS so they would be safer than browser storage
  • Which can be read by anything really
  • Even the users themselves could read/change the session storage data
  • I personally do not use browser storage for access stuff. I store it all in custom claims which is available in the access_token/JWT for the logged in user
  • So it is always available and is always passed with every request to the database
  • uunicode-1274423692754944024

    unicodes

    1 year ago

    Ahh, great ideaa. Custom Claims are new for me, I'm looking right now for some tutorials.
  • This old thread might help
  • We discussed them a bit there
    🙏1
  • I wouldn't call them necessary
  • I think some people do use the table route
  • Personally I prefer them for access related things
  • Since I need to grant access to an account and its users
  • So claims allow me to store account ids and such assigned to a user
    🥰1
  • But yeah
  • I think others do use the table method instead
  • JWT is faster because it's there for every call but I don't use it to store things like token expiry
  • uunicode-1274425025163952158

    unicodes

    1 year ago

    Thank you Lucas for sharing this. It looks like what I need.
  • lucasg-1274425187672129536

    Lucas G

    1 year ago

    I set a long expiry in my supabase settings so I don't really ahve issues with expiry
  • And I don't mind having to log in lol I might streamline this more in the future and periodically refresh the token etc.
  • This is all jsut me though
  • Haven't prioritized it for now
  • uunicode-1274425725155541024

    unicodes

    1 year ago

    If JWT is faster, why you do not use them? Are not secure?
  • lucasg-1274427396417650721

    Lucas G

    1 year ago

    They're not meant to be used for everything
  • I only use them for access
  • You also should only be able to set them with service level permissions which means they can only be set from a backend
  • uunicode-1274427760244162561

    unicodes

    1 year ago

    I read that JWT contains the auth_id 💡 , do you know how to access it?
  • lucasg-1274428193474084885

    Lucas G

    1 year ago

    You can see what it contains
  • Open up your console and go to the application tab -> cookies
  • Copy the value of your access_token
  • And use something like jwt.io to read it
    🥰1
  • You don't need to directly access it, it is sent with your API request if you're using bearer token
  • So supabase will automatically have access to it
  • Then your RLS can be something like if account = jwt account then they can access
  • uunicode-1274429284940775618

    unicodes

    1 year ago

    wow. I found the auth_id in the JWT, this means that I do not need to store user id in the session.
  • Thank you Lucas!
  • andreasmoller-1274429600151375983

    Andreas Møller

    1 year ago

    👍
  • lucasg-1274429680937598987

    Lucas G

    1 year ago

    This is why you do something simple like have an "owner" column
  • And RLS owner = auth.uid
  • Like Andreas shows in his videos
  • And it just works
  • Because it's passed by default
  • You'd only need to write custom claims with something like my case where I store additional info like a main account id, etc
  • uunicode-1274430184648474665

    unicodes

    1 year ago

    Today I learned a lot from you guys! I apreciate you are sharing this with me!
  • 282143925291057163-@Andreas Møller
    👍
    lucasg-1274430283021549588

    Lucas G

    1 year ago

    I like how you disappeared for a while there 😂
  • JK I just need reasons to mess with Andreas every once in a while
  • andreasmoller-1274430567550681222

    Andreas Møller

    1 year ago

    Came back for the credit
    ❤️2
    😂1
  • lucasg-1274430690909225101

    Lucas G

    1 year ago

    As you should, really
  • andreasmoller-1274430884627480619

    Andreas Møller

    1 year ago

    Nah, In this case the solution actually had nothing to do with toddle 🙂
  • uunicode-1274431953243738153

    unicodes

    1 year ago

    Toddle is not just the tool, which is awesome, toddle is also about the community. I found here people like you are, very open to share information and to help people like me learn (more than using toddle).
  • I really apreciate this and the patience you have with people like me.
  • andreasmoller-1274432208228319242

    Andreas Møller

    1 year ago

    Perfectly put. The community is the most important part
  • lucasg-1274432420539662440

    Lucas G

    1 year ago

    ❤️
  • uunicode-1274432663972745368

    unicodes

    1 year ago

    Thank you @Lucas G!
  • Thank you @Andreas Møller !