Does it make sense to user a server action to call an API route?
Unanswered
Asiatic Lion posted this in #help-forum
Asiatic LionOP
I'm not sure if I'm overcomplicating this process or not. Here's the pipeline:
(client search bar) ===query==>(server action)==>(/api/query/)==>(util function which connects to redis)==searchresults==>(/api/query)==>(server action)==>(client search bar)
My reasoning for using a server action is so that the client isn't exposed to any redis keys defined in the util function. My hunch is that I'm overcomplicating it, but when I think through it the logic seems sound. Any advice?
(client search bar) ===query==>(server action)==>(/api/query/)==>(util function which connects to redis)==searchresults==>(/api/query)==>(server action)==>(client search bar)
My reasoning for using a server action is so that the client isn't exposed to any redis keys defined in the util function. My hunch is that I'm overcomplicating it, but when I think through it the logic seems sound. Any advice?
5 Replies
American Crow
I don't know sounds a bit crazy to me.
Maybe i didn't understand all the requirements but I'd make use of having the state in the searchParams.
Here is a minimum example:
page.tsx
search.tsx
Maybe i didn't understand all the requirements but I'd make use of having the state in the searchParams.
Here is a minimum example:
page.tsx
import Search from "./search"
export default function Page({searchParams}) {
const userSearchTerm = searchParams.search ?? ""
// Connect to Redis or fetch or whatever here
return (
<div>
<h2>Current Search Term: {userSearchTerm}</h2>
<Search />
</div>
)
}search.tsx
// user search
"use client"
import { useSearchParams, useRouter } from "next/navigation"
export default function Search() {
const searchParams = useSearchParams()
const {replace} = useRouter()
const handleChange = (value: string) => {
const params = new URLSearchParams(searchParams)
params.set("search", value)
replace(`?${params.toString()}`)
}
return (
<div>
<h1>Search</h1>
<input type="text" placeholder="Search..." onChange={(e)=>handleChange(e.target.value)} />
</div>
)
}@American Crow I don't know sounds a bit crazy to me.
Maybe i didn't understand all the requirements but I'd make use of having the state in the searchParams.
Here is a minimum example:
page.tsx
tsx
import Search from "./search"
export default function Page({searchParams}) {
const userSearchTerm = searchParams.search ?? ""
// Connect to Redis or fetch or whatever here
return (
<div>
<h2>Current Search Term: {userSearchTerm}</h2>
<Search />
</div>
)
}
search.tsx
tsx
// user search
"use client"
import { useSearchParams, useRouter } from "next/navigation"
export default function Search() {
const searchParams = useSearchParams()
const {replace} = useRouter()
const handleChange = (value: string) => {
const params = new URLSearchParams(searchParams)
params.set("search", value)
replace(`?${params.toString()}`)
}
return (
<div>
<h1>Search</h1>
<input type="text" placeholder="Search..." onChange={(e)=>handleChange(e.target.value)} />
</div>
)
}
Asiatic LionOP
I see what you're getting at. If I understand you correctly, your example is quite different than my usecase. The search is completely divorced from the URL. To provide more context, it's a search component within a '/dashboard' page. The idea is that each time the search input updates, a request is sent to redis for those results, which are then displayed in real time while the user is typing. Am I making sense?
@Asiatic Lion I see what you're getting at. If I understand you correctly, your example is quite different than my usecase. The search is completely divorced from the URL. To provide more context, it's a search component within a '/dashboard' page. The idea is that each time the search input updates, a request is sent to redis for those results, which are then displayed in real time while the user is typing. Am I making sense?
American Crow
Hm okay. You are right my example is quite different but that is because it leverages searchParams. It's a different pattern. The requirements you just stated are all possible with that setup (doing a fetch with each input update). The search is only completely separated from the URL because you designed it that way. Feel free to test that pattern out the overall setup would be a lot easier. Anyway you do you just tried to give a different perspective
@American Crow Hm okay. You are right my example is quite different but that is because it leverages searchParams. It's a different pattern. The requirements you just stated are all possible with that setup (doing a fetch with each input update). The search is only completely separated from the URL because you designed it that way. Feel free to test that pattern out the overall setup would be a lot easier. Anyway you do you just tried to give a different perspective
Asiatic LionOP
I appreciate the sanity check lol. I think using API + Server action is redundant and the API isn't intended to be public-facing. So I think I'll just go with a server action.
@Asiatic Lion I appreciate the sanity check lol. I think using API + Server action is redundant and the API isn't intended to be public-facing. So I think I'll just go with a server action.
American Crow
you welcome. yes you are right. Whenever you catch yourself fetching your own API in a Server Component or a Server Action it's a good indicator you're doing something wrong. Just a server action will improve your setup for sure