I want to contribute?

[oscartbeaumont]

Since announcing I was going to step-back from rspc's development (#351) I have had multiple questions from people that wanted to contribute so I want to lay out some of the vision and what needs to be done. I'm putting this is a loose order of it's importance but feel free to not stick to the order if you care for something in particular.

Before contributing it could be worth reading this unreleased blog post which might give you a better idea about the plan for rspc's future (note it's unreleased for a reason so might be a little bit of a hard read).

0.4.x needs to actually work

We recently rushed out of the 0.4.x release wayyy before it was really ready. We need to get it to the stage where people can actually use it in all of the places the previous version worked.

The best way to contribute here is to attempt to upgrade your own applications using rspc and fix all the bugs your going to come across. This migration doesn't really have docs so your just going to have to work it out from the examples.

Known issues:

• Tauri integration is broken - Fix Tauri integration #341

Documentation is a mess

Tracked as #339

We have started the migration from rspc.dev to specta.dev. The documentation on rspc.dev is going to remain on the old version of rspc but new documentation must be written for the new syntax introduced in 0.4.x for specta.dev.

These changes will need to be contributed to specta-rs/website.

If you need somewhere to start pick a dot point in specta-rs/website#9.

Typescript client

The plan is to move from the current syntax to using a proxy syntax similar to tRPC or rspc-proxy.

We would also like the removing the concept of links. The plan is to something way more modular. My current thinking is to have a fetch function which the user can implement themselves however they want. This removes a huge amount of complexity from rspc and gives the end-user more flexibility (which has historically been a rough part of our client). This way they can implement the links themselves or compose functions to gain special behavior. I think we would want to include a fetcher: fetchTransport(...) and fetcher: websocketTransport(...).

We also want to remove all framework specific packages in favor of @rspc/tanstack-query which can work similar to the recent tRPC changes. This will allow us to work with any Transtack Query-equipt framework without any extra effort.

One of the big issues with going framework agnostic is about managing subscriptions because Tanstack Query doesn't support that. I think we could be worth building a core handleSubscription or similar function which can be easily put in a useEffect/Vue effect/Solid effect/etc. This way we can leave it up to the end user (and the examples in the documentation) for the thin layer integrating it into the framework's lifecycle.

I also think we should concider just shipping SolidJS's primitives websocket handler (or something similar) in the handleSubscription function. I get this will make the bundle bigger but i'm not sure I care to maintain proper reliable websocket connection code as we have had sooooo many bugs in the current implementation.

Note: As much as it's rough I don't think we should care much about backwards compatibility at this stage. At this point rspc is dead, bringing it back to life is more important than getting bogged down in the migration path, it's going to suck to migrate unless someone is willing to put in the effort to create a codegen tool.

Tracking issues:

• Client v2 #332
• Cleanup TS #269
• Follow trpc's new React Query integration style #349

I think @Brendonovich started work on this on better-axum.

Future vision

The long term goal of rspc is to make developing backends in Rust easier. This is an essentially unbounded goal but once we get the core into a more stable place we can focus on building out a better ecosystem of middleware to give better of the box functionality.

The big things in this space for me are:

• Single Flight Mutations (in a single HTTP request send a mutation and get back the new data for all the queries that changed)
• Hot reload (hot reload Rust using subsecond, the cool project the Dioxus folks are working on)
• Integrations for more frameworks - Actix-web, etc so anyone can use rspc

You can checkout the GitHub issues if you wanna look for more of my cursed ideas but I truely believe we can push the barrier for the developer experience and user experience that can be shipped from a backend stack that is not written in JavaScript/Typescript.

If your thinking of contributing definitely feel free to chat in the Discord.

(thanks to CrabNebula for supporting my work on this writeup)

[TmLev]

The plan is to move from the current syntax to using a proxy syntax similar to tRPC or rspc-proxy.

tRPC v11 actually moved off of this proxy-based syntax in favor of composition:

const query = useQuery(trpc.someProcedure.queryOptions())

Source: https://trpc.io/blog/introducing-tanstack-react-query-client

I believe this would be beneficial for rpsc as well.

[oscartbeaumont]

For sure! It's a bit hidden but I also linked that one in the post above.

It would be awesome to be able to drop any framework specific packages and just have @rspc/tanstack-query. We just need to figure out how useSubscription ends up fitting into that system (from what I could tell last time I checked tRPC are keeping the React/Solid/etc integrations to solve this but I recon we try something different by asking the end-user to build their own useSubscription hook around a primitive we expose).

[TmLev]

For sure! It's a bit hidden but I also linked that one in the post above.

Right, sorry – I glanced over the link a bit too quickly.

One of the main pain points I’ve had is making @rspc/client more bundler-aware when handling the server/client split on the frontend. Right now, I have a custom authLink that needs to be configured differently depending on the environment:

import "server-only";

export const serverRspc = initRspc<Procedures>({
  links: [
    authLink({
      getToken: async () => {
        const token = await auth().getToken();
        return token;
      },
    }),

    buildHttpLink(),
  ],
});

import "client-only";

export const clientRspc = initRspc<Procedures>({
  links: [
    authLink({
      getToken: async () => {
        return getCookie("__session") ?? getToken();
      },
    }),

    buildHttpLink(),
  ],
});

Here, auth() and getCookie() come from server-only and client-only packages respectively.

By explicitly using serverRspc or clientRspc, I’ve been able to more or less work around the split, but it would be nice to configure this in a single, isomorphic way. Might not be entirely possible, though.