[rpc] add Middleware / (public|unpublic)Procedure

[MrOxMasTer]

What is the problem this feature would solve?

no possibility to create middleware / procedure

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

import { RpcMiddleware } from "@effect/rpc";

class AuthMiddleware extends RpcMiddleware () {
...
}

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

export const userRouter = RpcRouter.make(
  Rpc.effect(UserByEmail, ({ email, ctx }) => // <---------------- ctx
    Effect.gen(function* (_) {
     ...
    })
  ),
);

I know there is middleware for http, but it doesn't work for me because I don't plan to use http. I only need to use the server side (server components and server react actions) and I don't need http for that and I don't need to create endpoints either

What alternatives have you considered?

trpc: https://trpc.io/docs/server/procedures#reusable-base-procedures

[patroza]

I think middleware configuration metadata on the request is fine, but since it’s shared with the client I think an implementation instance should not exist on the Request but somewhere on the server side.

Until there is official support, I would suggest to use a HOC at your handler definitions,
possibly you make a clone of RPC.effect with the HOC built in

[MrOxMasTer]

I think middleware configuration metadata on the request is fine, but since it’s shared with the client I think an implementation instance should not exist on the Request but somewhere on the server side.

For many reasons, I'm not comfortable with rpc anyway. No naming (organization by entities), no documentation, no middleware, and difficult to cache and not library ready

[patroza]

For many reasons, I'm not comfortable with rpc anyway. No naming (organization by entities), no documentation, no middleware, and difficult to cache and not library ready

have you considered multiple RPC endpoints for the naming/organization?

[MrOxMasTer]

have you considered multiple RPC endpoints for the naming/organization?

If you mean about RpcRouter.make(RpcRouter.make) - then yes and there is no naming or closing into a single object.
If you mean about creating a set of RpcRouter, then in order to use it, you need to initialize it - and this is a nightmare. There are 3 objects for each router, and there is no common single object, which is inconvenient.