Replies: 10 comments 1 reply
|
Nice suggestions! This might effectively be implementing #20, I think? |
0 replies
|
Also related: |
0 replies
|
Making experiments here https://github.com/antfu/nuxt-server-fn |
0 replies
0 replies
|
@antfu love the idea. Would like to see an equivalent to nextjs server actions in the vue/nuxt side of the world. Where has the rfc and experiment land? Would love to understand if plans are being made with the nuxt group. |
0 replies
|
Look at https://github.com/hminghe/nuxt-unapi // api/user.ts
import { z } from 'zod'
export const getUser = defineApi({
props: z.number(),
// id type is number
async handler (id) {
return db.user.get(id)
},
})// pages/user.vue
<script setup>
import { getUser } from '~/api/user'
const { data } = await useAsyncData(async () => {
const user = await getUser(1)
return user
})
</script> |
0 replies
|
news? |
0 replies
|
Was the idea of built in RPC abandoned? |
1 reply
|
+1 |
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.
Motivation
I love the convention we had for
server/apito define server routes in a very simple way.While in some cases, we might also have a set of functions that are aimed to run on the server-side only. For example, I might have a set of APIs that I need to ensure it ensures running on server APIs to avoid leaking the API keys.
To have them accessible on the client-side, we need to have multiple
server/api/xxx.tsfiles to expose them one by one. LikeWhile it's great we already provide type safety for API routes, it's still some work and scaffolding code to make it work.
Propsoal
I am thinking to have a
server/rpcfolder that we could proxy all the exported functions to the client-side with the correct type as RPC functions.For example:
Here is a demo implementation with Nuxt 3: https://stackblitz.com/edit/github-wcd1zn?file=app.vue
All reactions