PricingDocsAcademy
Bluesky ...
Fri, Dec 13, 9:10 AM

Slower API after migrating to v2

  • /attachments/1304176137907212368/1304176138725097482/api_v1_-_fast.mov

    Janis

    1 month ago

    I just migrated to v2 and noticed that my Supabase APIs now load significantly lower. I did not change any other settings apart from hitting the migrate button. did anyone else notice the same or is there anything else I need to configure?
  • unicodes

    1 month ago

    Janis, I would recommend to try on incognito (for excluding extensions to impact your performance) and to try the tabs from chrome "Performance" and "Lighthouse". In performance you can see exactly the ms of the api response. Please share some screens or records of the results. It could be a good solution to find out what happens.
  • Looking for your inputs. Thank you!
  • Lucas G

    1 month ago

    New API has response times built in. When you check in the editor (the play button), what type of response times are you seeing?
    πŸ‘1
  • Janis

    1 month ago

    Thanks both. So when I'm testing the API response times it seems to be between 132ms - 245ms

    So I looked at the performance and network as you suggest @unicodes and it seems like that for some reason the /app folder increased in loading time. It is the same size at 101kb but the loading time on v2 is almost double or even worse
  • Here is v1 with 237ms
    image.png
  • /attachments/1304176137907212368/1304334815851581521/image.png

    Janis

    1 month ago

    And v2 taking 1.16s
    image.png
  • /attachments/1304176137907212368/1304342388562591785/image.png

    Janis

    1 month ago

    Ok so I did a bit more digging:

    - There is a null row which wasn't there before that takes 180ms
    - Custom Code takes all of a sudden 243ms instead of 2ms before.
    image.png
    πŸ‘1
  • Erik Beuschau

    1 month ago

    Thank you so much for investigating and paying attention to this πŸ™Œ
    A few notes:
    - The custom-code file holds all your custom actions/formulas. The new API format should not have affected the size/performance of that.
    - The null request seems strange, could you perhaps share a url so I can investigate? 🀞
    - If you have enabled SSR for a lot of API requests on your page, surely they would lead to a slower response time since all of them need to run during server side rendering. If some of them are not critical for the initial loading experience, I suggest you disable SSR and have the client load them on load instead
    πŸ™1
  • Janis

    1 month ago

    Thank you Erik, will send you the URL in a DM! πŸ™‚
    πŸ™Œ1
  • Janis

    1 month ago

    Regarding the custom code one: I deleted and created a new branch twice now and both times the custom-code file grew massively
  • Tod

    1 month ago

    Great energy @Janis! Your continuous contribution to the toddle Community just made you advance to Community Level 7!
  • Janis

    1 month ago

    Regarding SSR: I have them all set to auto-fetch. I also tried putting them on the success event of the authentication check endpoint but same result
  • James

    1 month ago

    I can also see that null request in my project. Page seems to load in, then that null request happens and causes a flash on the page as if it re-renders
  • Erik Beuschau

    1 month ago

    Thanks James. We're currently looking into this issue, and will keep you updated πŸ‘
    Reg. the other issues Janis was having, we found an issue when API requests were dependent on other API requests. We've solved it for SSR, and we're looking to solve it client-side as well.

    The custom-code.js performance issue seems to be a difference between main and other branches since we have different cache settings internally (so not really an issue atm)
    πŸ‘2

Stop scrolling. Start building.

toddle is a visual web app builder that rivals custom code β€” but accessible to your entire team!

Try toddle β€” it's free!

Β© Copyright 2024 toddle. All rights reserved.