Replies: 0 comments 1 reply
|
Thanks for raising this issue! It is an important discussion, and will convert this to discussions! |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
The feature
Currently the frontend is not using any form of caching when retrieving information from the API - potentially causing more API calls than strictly necessary. Ideally any data that has already been fetched no longer requires a call to the API.
This feature came about after discussing the possibility of storing event registrations in user context. The mechanism for caching reservations however, needs to be a little bit smarter than simply caching the first results from the api. Consider this scenario:
The following solutions describe the implementation from that reservations point-of-view, but would of course be reused in reducing other/future api calls.
Ideal Solution
The ideal flow(the one that would introduce the minimum amount of api calls) would do the following:
Downside - a complexer implementation which could potentially require fine-tuning per type of resource.
Less ideal solution
Downside - more API calls than strictly necessary compared to the ideal solution. Upside is that this solution is less complex.
Other solutions
One thing that could be implemented, but would only cater to resources which are more static is caching headers. Vercel has some custom headers which can be set and could reduce round-trips to the eventuras server. This could be implemented in the api forwarder.
https://vercel.com/docs/edge-network/caching
All reactions