The current implementation of subscriptions makes it hard to use in serverless environments as you need a dedicated websocket server to run for extended periods of time. I believe it would be nice to have an alternative means for subscriptions which can be routed via services like Pusher, which would support NextJS or other serverless environments better.
A couple of flaws with the current implementation (wrt serverless):
Note that these are only flaws because serverless + WSaaS operates with different assumptions than normal subscriptions would.
A possible API for implementing the above ideas:
onAdd: t.procedure.subscription(({ ctx }) => {
return channel<Post>(ctx.session.user.id);
}),
add: t.procedure
.input(
z.object({
id: z.string().uuid().optional(),
text: z.string().min(1),
}),
)
.mutation(async (opts) => {
const post = { ...opts.input }; /* [..] add to db */
await emitToChannel(opts.ctx.session.user.id, post);
return post;
}),
This API would be able to wrap services like Pusher as well as barebones websockets.
What this might look like under the hood is:
onAdd
exposes 2 API endpoints, one for subscribing and one for unsubscribing. Each one handles their respective operations on the underlying channel implementation. For example, a subscribe call might create a Pusher channel called trpc:onAdd:1234
(where 1234 is the user ID passed into the function), and unsubscribe would delete said channel.
emitToChannel
would route the data to the channel with the respective user id, serializing the message with the existing protocols.This code is obviously quite rough and would need tweaking, but the resulting API might make subscriptions nicer to work with in a way thats a bit more agnostic to the backing implementation than the current design.
An alternative might be a new procedure type that mimics subscriptions but is designed around the new APIs, which would effectively be the above implementation again (or something similar) but maybe as t.procedure.channel
instead. The obvious upside is backwards compatibility is much easier, but the downside is that it is conceptually quite similar to subscriptions.
I wouldn't mind trying to write a PR for this, but it would take me quite some time to do because I am not familiar with the codebase or best practices of this repo, and I am also not sure what the best approaches for this particular problem would be.
Pay now to fund the work behind this issue.
Get updates on progress being made.
Maintainer is rewarded once the issue is completed.
You're funding impactful open source efforts
You want to contribute to this effort
You want to get funding like this too