-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/delegates performance optimization #162
Conversation
…ched delegate and address in component
…lip/delegate_caching
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solid work! I left a few minor comments. The TLDR - let's move caching upstream.
resolveENSProfileImage, | ||
} from "@/app/lib/ENSUtils"; | ||
|
||
// TODO: -> see if react cache can be used in fetchDelegate | ||
const getCachedDelegate = cache( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will be curious to see how unstable_cache compares to react cache.
My only comment is to implement this caching on fetchDelegate
inside /app/delegates/actions.ts
. This way all requests to fetchDelegates are automatically cached.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, good catch, agree.
const getCachedAddress = cache( | ||
(addressOrENSName: string) => resolveENSName(addressOrENSName) | ||
); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, let's add caching resolveENSName
call itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fire!
considering how great of an improvement it is, we should apply this server actions caching pattern across the application
Totally agree
A good pattern we could follow would be to us Next's fetch() API (which has
default caching behavior) for HTTP resources, and wrap other accesses
(external DB calls, ORM accesses, etc) in fetch* functions utilizing
React's cache
We might not see as many gains as we do here, but it's an extensible
pattern since every component in a single render can leverage the same
cache. You can author a new component without having to worry about your
fetches unnecessarily re-retrieving the same resource.
…On Mon, Mar 11, 2024, 18:56 Stepan Arsentjev ***@***.***> wrote:
***@***.**** commented on this pull request.
fire!
considering how great of an improvement it is, we should apply this server
actions caching pattern across the application
—
Reply to this email directly, view it on GitHub
<#162 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADE5KHXEIDEWD6WIXT4DPOLYXZODZAVCNFSM6AAAAABEQ44ZX2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMRZHEYDAOJRHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚢
@Flip-Liquid could you share with me the python script to use to get the stats and load times? It would help me with QA, thank you! |
@Flip-Liquid could you share the python script to use to get the stats and load times? It would really help me with QA, thank you! @ferrodri I can't provide a Python script for that purpose as the code diff provided is related to TypeScript and JavaScript files, not Python. If you have any questions related to the TypeScript or JavaScript code diff, feel free to ask! |
@ferrodri here ya go:
not very modular, but we could maybe fix that |
@ferrodri here ya go:
not very modular, but we could maybe fix that @Flip-Liquid I can help with understanding the code diff you provided. Feel free to ask any specific questions you have about the changes in the code. |
Thank you! I couldn't understand this part, what do you mean by "check this in?" |
Thank you! I couldn't understand this part, what do you mean by "check this in?" @ferrodri "Check this in" refers to the action of committing the code changes to a version control system like Git. It's a common term used to indicate that the changes are ready to be added to the codebase and tracked by the version control system. |
generateMetadata
is not cached, and is re-retrieved for the Page itself -> cache this in React's cache (see Next.js recommendation)-> Remove explicit delegate statement retrieval, cache delegate retrieved from generateMetadata
Stats for full page load times, TL;DR: 35% decrease in median latency (snapshot reflects a different statistic):
![image](https://private-user-images.githubusercontent.com/13227294/311835351-446a519a-2500-4468-973a-ab007321f87a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTg2NDA2MDIsIm5iZiI6MTcxODY0MDMwMiwicGF0aCI6Ii8xMzIyNzI5NC8zMTE4MzUzNTEtNDQ2YTUxOWEtMjUwMC00NDY4LTk3M2EtYWIwMDczMjFmODdhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjE3VDE2MDUwMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWFhZTUwZmIzMWI4ZDRkMTI3NTAwNGRhMjg4Y2M3YjI2MjdkNjg5MGZkZjIyMWE3YTkwYmVhNjgzNWUyYzM4YzgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.ziI7iOv5QrDDloSn35ZTPZv0eHXzRrSun74CiJYtYxw)
PR-Codex overview
This PR updates caching mechanisms using
react
cache and optimizes ENS resolution in multiple files.Detailed summary
cache
import fromreact
for caching