[rpc] An object for accessing procedures using typescript

[MrOxMasTer]

What is the problem this feature would solve?

This issue will be able to solve the problem

• lack of hints when using @effect/rpc
• implicit requests that you can't even guess about
• To know which queries exist and which do not, so as not to accidentally make unnecessary ones or not to memorize each query which exists and which does not

Maybe a query to create using a class is fine, but how to maintain it remains a mystery to me

What is the feature you are proposing to solve the problem?

An approximate implementation:

class UserByEmail extends S.TaggedRequest<UserByEmail>()('UserByEmail', {
  failure: S.Union(
    S.instanceOf(UnknownDatabaseError),
    S.instanceOf(UserNotFoundError),
  ),
  success: selectUserSchema,
  payload: { email: userEmailSchema },
}) {}

export const userRouter = RpcRouter.annotations({ name: "userRouter", as: "user"  } | "user").make(
  Rpc.effect(UserByEmail, ({ email }) => Effect.<...>,
);

export type UserRouter = typeof userRouter;

const appRouter = RpcRouter.annotations({ name: "appRouter" }).make(userRouter, ...)

const handler = RpcRouter.toHandler(appRouter);
const resolver = RpcResolver.make(handler)<typeof appRouter>();

const client = RpcResolver.toClient(resolver);

// new function:
const caller = createCaller(client);

caller.users.userByEmail({ email })
caller.posts.postById({ id })
caller.fail()

What alternatives have you considered?

trpc:

[patroza]

The current client already gives you the type hints to show what procedures you can call:

I do however agree that named methods are nicer, and a missed opportunity, given that we already have unique tags.
(see below for my approach, which uses named methods)

I think having a single client for all rpc is not good, especially considering tree shaking.
If that's however not important in your use case, I do think It could be a neat opt-in feature.

My approach to this is slightly different:

• resources: https://github.com/effect-app/sample/blob/main/api/src/resources/Blog.ts
• implementation: https://github.com/effect-app/sample/blob/main/api/src/Blog.controllers.ts
• client: https://github.com/effect-app/sample/blob/main/frontend/pages/blog/index.vue#L5

One could easily build a unified client with this. const caller = { blog: clientFor(BlogRsc), account: clientFor(AccountRsc) }
It uses @effect/rpc under the hood, is layer based like HttpApi, and is imo an example of the flexibility of the current RPC implementation. I think you could consider the current RPC implementation low level.
Looking forward to have RPC grow to something higher level and better integrated

[mikearnaldi]

you might want to use the HttpApi module from platform instead, that gives you a client in the style you want

[MrOxMasTer]

you might want to use the HttpApi module from platform instead, that gives you a client in the style you want

Question - is it possible to define HttpApi without url? Because in documentation I see only with url or the question - why I need to run a separate server, when I need only a convenient tool for working with requests, in the form of structure by business entities and middleware

[patroza]

@MrOxMasTer theres an example inside the tests.
But maybe you just want a RequestResolver or more what @FedericoBiccheddu does https://discord.com/channels/795981131316985866/1306739649875808349/1306747962537545759