Whats the more idiomatic way to fetch on search in this case ?
Unanswered
European imported fire ant posted this in #help-forum
European imported fire antOP
Hello, I have a form where a user can search a text, the form is a client component so it calls a server action which then does a lookup on my DB, if it doesnt find anything it calls 3 external APIs, constructs an object and adds it to my DB. Then redirects to the results page. The results page is served at something like "results/id/{id}". The results page then queries my DB based on the id passed and shows the results.
My questions now are:
1) Would it make sense to send the object directly to the results page to save up on the initial query ? So I save up the object to my DB, then send it to the results page to display it so I dont have to query on result page load. If so how can I do that from a server action ?
2) What would be the best fetching strategy in my results page ? Check if the form sent data and display that or if not query my DB or simply always fetch from DB no matter what ?
3) What would then be the best way to handle the results page ? So there is the case that a user gets to it by using the form, but also someone can navigate directly to /resutls/id/{id} and put a random id. How can I make sure people dont really spam these pages and produce a lot of queries to my DB ?
EDIT: I realise rate limiting seems the obvious choice for my last question but I was wondering if theres a more efficient/idiomatic way
My questions now are:
1) Would it make sense to send the object directly to the results page to save up on the initial query ? So I save up the object to my DB, then send it to the results page to display it so I dont have to query on result page load. If so how can I do that from a server action ?
2) What would be the best fetching strategy in my results page ? Check if the form sent data and display that or if not query my DB or simply always fetch from DB no matter what ?
3) What would then be the best way to handle the results page ? So there is the case that a user gets to it by using the form, but also someone can navigate directly to /resutls/id/{id} and put a random id. How can I make sure people dont really spam these pages and produce a lot of queries to my DB ?
EDIT: I realise rate limiting seems the obvious choice for my last question but I was wondering if theres a more efficient/idiomatic way
2 Replies
Milkfish
1. This could work. You could use a context provider or a persistent state store to store the form data and display on the result page. But I feel like this is unnecessary. The result page shouldn't be dependent on the form data. It should be dependent on the id in the url. Plus, the user can just manually type in the url, and visit the page without interacting with the form. So I don't recommend this.
2. Just get the id from the url, fetch data from db, and display. No need to tie it to the form.
3. Exactly. So you spotted the issue with the whole form and result connection. So I recommend just keeping them separate.
When the user searches for something, do ur check and insertion, then redirect them to the result page. Get the id of the item being searched for, fetch and display in the result page.
If you're scared of hitting db too many times, cache.
Rate limiting is also nice too for preventing spammers.
I got a question tho,
You said you insert into your db when the user searches for something that doesn't exist, before redirecting to the result page.
What if the user types in the url manually, and puts an id that doesn't exist ?
Do you also check and insert or do you just show a 'not found' message ?
2. Just get the id from the url, fetch data from db, and display. No need to tie it to the form.
3. Exactly. So you spotted the issue with the whole form and result connection. So I recommend just keeping them separate.
When the user searches for something, do ur check and insertion, then redirect them to the result page. Get the id of the item being searched for, fetch and display in the result page.
If you're scared of hitting db too many times, cache.
Rate limiting is also nice too for preventing spammers.
I got a question tho,
You said you insert into your db when the user searches for something that doesn't exist, before redirecting to the result page.
What if the user types in the url manually, and puts an id that doesn't exist ?
Do you also check and insert or do you just show a 'not found' message ?
@Milkfish 1. This could work. You could use a context provider or a persistent state store to store the form data and display on the result page. But I feel like this is unnecessary. The result page shouldn't be dependent on the form data. It should be dependent on the id in the url. Plus, the user can just manually type in the url, and visit the page without interacting with the form. So I don't recommend this.
2. Just get the id from the url, fetch data from db, and display. No need to tie it to the form.
3. Exactly. So you spotted the issue with the whole form and result connection. So I recommend just keeping them separate.
When the user searches for something, do ur check and insertion, then redirect them to the result page. Get the id of the item being searched for, fetch and display in the result page.
If you're scared of hitting db too many times, cache.
Rate limiting is also nice too for preventing spammers.
I got a question tho,
You said you insert into your db when the user searches for something that doesn't exist, before redirecting to the result page.
What if the user types in the url manually, and puts an id that doesn't exist ?
Do you also check and insert or do you just show a 'not found' message ?
European imported fire antOP
Thank you for your answer. I ended up doing this, always fetch from ID no matter what. For your question if the id doesnt exist its a not found message. The id is gonna be a hash of the id in m DB as I dont want to expose it. So i was in between deciding if i want to keep the pages as "persistent" places of information so if you know the id you can see the results or if they are more temporary to show the current result. I think for now Ill go with the second option.