Are there plans yet for RPC-style data fetching from the client?
Answered
Polar bear posted this in #help-forum
Polar bearOP
Server actions and server components let us (mostly) get rid of fetch requests from the client, but they're sometimes still necessary (e.g. polling for new data).
Are there any plans to introduce a similar RPC-style mechanism to server actions, but for data fetching? The current alternatives are:
* Use actions for data fetching. This mostly works, but they don't seem designed for it: they're called "actions", the documentation doesn't mention it, they run serially, and they use the 'POST' verb.
* Use route handlers and fetch request for data fetching. This works, but the developer experience is much worse: you have to deal with HTTP (endpoint paths, path parameters, query parameters, status codes) instead of an ordinary function call.
I'm guessing the next team is aware of this, but would love to hear:
* if there is any community consensus on the best way to handle this in the current state of next
* if and where this is being discussed for upcoming next versions
Are there any plans to introduce a similar RPC-style mechanism to server actions, but for data fetching? The current alternatives are:
* Use actions for data fetching. This mostly works, but they don't seem designed for it: they're called "actions", the documentation doesn't mention it, they run serially, and they use the 'POST' verb.
* Use route handlers and fetch request for data fetching. This works, but the developer experience is much worse: you have to deal with HTTP (endpoint paths, path parameters, query parameters, status codes) instead of an ordinary function call.
I'm guessing the next team is aware of this, but would love to hear:
* if there is any community consensus on the best way to handle this in the current state of next
* if and where this is being discussed for upcoming next versions
Answered by LuisLl
When you can fetch on server components and pass data down as props.
When you need to fetch data from the client the only Next.js way is to hit a API Route handler, for that I like to abstract all the queries in sort of a data layer that calls the endpoint and returns the data instead of hitting the endpoint on every component that need it directly.
Btw I saw TKDodo on Bluesky saying someone from the Next.js team was talking about implementing a “server actions- like” way of retrieving data, that’s the missing piece for RPC-style fetching patterns
https://bsky.app/profile/tkdodo.eu/post/3licej2sc4k22
When you need to fetch data from the client the only Next.js way is to hit a API Route handler, for that I like to abstract all the queries in sort of a data layer that calls the endpoint and returns the data instead of hitting the endpoint on every component that need it directly.
Btw I saw TKDodo on Bluesky saying someone from the Next.js team was talking about implementing a “server actions- like” way of retrieving data, that’s the missing piece for RPC-style fetching patterns
https://bsky.app/profile/tkdodo.eu/post/3licej2sc4k22
10 Replies
if thats the thing u search for
it handles the fetch boilerplate for u
and actions are not for data fetching
Mini Satin
BUMP
i might be missing something here but the [data fetching](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#fetching-data-on-the-client) docs for next.js don't specify how we can use server-side code to fetch data on the client (i.e securely connect to server-only data sources without exposing sensitive logic)
example (modified from next.js docs):
i completely agree with the fetching data using RSC when possible but there are reasonable use cases for data-fetching on the client: infinite scrolls, data polling, etc.
as @Polar bear mentioned, trying to pull this off using server actions run would be a massive performance bottleneck as they run "one at a time".
i would use tRPC for this but i really don't want to refactor my existing data access layer to fit a single niche use case. it feels like we're missing a basic pattern here that should be well-documented.
has anyone been struggling with this as well? i don't mind a hacky solution either, as long as it works :)
i might be missing something here but the [data fetching](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#fetching-data-on-the-client) docs for next.js don't specify how we can use server-side code to fetch data on the client (i.e securely connect to server-only data sources without exposing sensitive logic)
example (modified from next.js docs):
// page.tsx
'use client'
import { useState, useEffect } from 'react'
import { getPosts } from "@/server/queries"
export function Posts() {
const [posts, setPosts] = useState(null)
useEffect(() => {
async function fetchPosts() {
const data = await getPosts();
setPosts(data)
}
fetchPosts()
}, [])
if (!posts) return <div>Loading...</div>
return (
<ul>
{posts.map((post) => (
<li key={post.id}>{post.title}</li>
))}
</ul>
)
// server/queries.tsx
import 'server-only';
export async function getPosts(){
// handle data-fetching logic (ex query from db)
return [{id: 1, title: 'hello'}, {id: 2, title: 'world'}]
}the code above will not work as the client is importing a function meant to be called on the server!
i completely agree with the fetching data using RSC when possible but there are reasonable use cases for data-fetching on the client: infinite scrolls, data polling, etc.
as @Polar bear mentioned, trying to pull this off using server actions run would be a massive performance bottleneck as they run "one at a time".
i would use tRPC for this but i really don't want to refactor my existing data access layer to fit a single niche use case. it feels like we're missing a basic pattern here that should be well-documented.
has anyone been struggling with this as well? i don't mind a hacky solution either, as long as it works :)
When you can fetch on server components and pass data down as props.
When you need to fetch data from the client the only Next.js way is to hit a API Route handler, for that I like to abstract all the queries in sort of a data layer that calls the endpoint and returns the data instead of hitting the endpoint on every component that need it directly.
Btw I saw TKDodo on Bluesky saying someone from the Next.js team was talking about implementing a “server actions- like” way of retrieving data, that’s the missing piece for RPC-style fetching patterns
https://bsky.app/profile/tkdodo.eu/post/3licej2sc4k22
When you need to fetch data from the client the only Next.js way is to hit a API Route handler, for that I like to abstract all the queries in sort of a data layer that calls the endpoint and returns the data instead of hitting the endpoint on every component that need it directly.
Btw I saw TKDodo on Bluesky saying someone from the Next.js team was talking about implementing a “server actions- like” way of retrieving data, that’s the missing piece for RPC-style fetching patterns
https://bsky.app/profile/tkdodo.eu/post/3licej2sc4k22
Answer
sidenote, did you manage to get end-to-end type-safety using route handlers? it kinda sucks that you have to define a return type for everything to work nicely :(
@Mini Satin sidenote, did you manage to get end-to-end type-safety using route handlers? it kinda sucks that you have to define a return type for everything to work nicely :(
Yea that’s the ugly part lol it’s what libraries and implementations hide from us and works out of the box. Honestly we need the RPC-like fetching patterns!