Connect-Query is an wrapper around TanStack Query (react-query), written in TypeScript and thoroughly tested. It enables effortless communication with servers that speak the Connect Protocol.
npm install @connectrpc/connect-query @connectrpc/connect-web
Tip
If you are using something that doesn't automatically install peerDependencies (npm older than v7), you'll want to make sure you also have @bufbuild/protobuf
, @connectrpc/connect
, and @tanstack/react-query
installed. @connectrpc/connect-web
is required for defining
the transport to be used by the client.
Connect-Query will immediately feel familiar to you if you've used TanStack Query. It provides a similar API, but instead takes a definition for your endpoint and returns a typesafe API for that endpoint.
First, make sure you've configured your provider and query client:
import { createConnectTransport } from "@connectrpc/connect-web";
import { TransportProvider } from "@connectrpc/connect-query";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
const finalTransport = createConnectTransport({
baseUrl: "https://demo.connectrpc.com",
});
const queryClient = new QueryClient();
function App() {
return (
<TransportProvider transport={finalTransport}>
<QueryClientProvider client={queryClient}>
<YourApp />
</QueryClientProvider>
</TransportProvider>
);
}
With configuration completed, you can now use the useQuery
hook to make a request:
import { useQuery } from '@connectrpc/connect-query';
import { say } from 'your-generated-code/eliza-ElizaService_connectquery';
export const Example: FC = () => {
const { data } = useQuery(say, { sentence: "Hello" });
return <div>{data}</div>;
};
That's it!
The code generator does all the work of turning your Protobuf file into something you can easily import. TypeScript types all populate out-of-the-box. Your documentation is also converted to TSDoc.
One of the best features of this library is that once you write your schema in Protobuf form, the TypeScript types are generated and then inferred. You never again need to specify the types of your data since the library does it automatically.
To make a query, you need a schema for a remote procedure call (RPC). A typed schema can be generated with protoc-gen-es
. It generates an export for every service:
/**
* @generated from service connectrpc.eliza.v1.ElizaService
*/
export declare const ElizaService: GenService<{
/**
* Say is a unary RPC. Eliza responds to the prompt with a single sentence.
*
* @generated from rpc connectrpc.eliza.v1.ElizaService.Say
*/
say: {
methodKind: "unary";
input: typeof SayRequestSchema;
output: typeof SayResponseSchema;
};
}>;
protoc-gen-connect-query
is an optional additional plugin that exports every RPC individually for convenience:
import { ElizaService } from "./eliza_pb";
/**
* Say is a unary RPC. Eliza responds to the prompt with a single sentence.
*
* @generated from rpc connectrpc.eliza.v1.ElizaService.Say
*/
export const say: (typeof ElizaService)["method"]["say"];
For more information on code generation, see the documentation for protoc-gen-connect-query
and the documentation for protoc-gen-es
.
const TransportProvider: FC<
PropsWithChildren<{
transport: Transport;
}>
>;
TransportProvider
is the main mechanism by which Connect-Query keeps track of the Transport
used by your application.
Broadly speaking, "transport" joins two concepts:
- The protocol of communication. For this there are two options: the Connect Protocol, or the gRPC-Web Protocol.
- The protocol options. The primary important piece of information here is the
baseUrl
, but there are also other potentially critical options like request credentials, wire serialization options, or protocol-specific options like Connect's support for HTTP GET.
With these two pieces of information in hand, the transport provides the critical mechanism by which your app can make network requests.
To learn more about the two modes of transport, take a look at the Connect-Web documentation on choosing a protocol.
To get started with Connect-Query, simply import a transport (either createConnectTransport
or createGrpcWebTransport
from @connectrpc/connect-web
) and pass it to the provider.
A common use case for the transport is to add headers to requests (like auth tokens, etc). You can do this with a custom interceptor.
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { TransportProvider } from "@connectrpc/connect-query";
const queryClient = new QueryClient();
export const App = () => {
const transport = createConnectTransport({
baseUrl: "<your baseUrl here>",
interceptors: [
(next) => (request) => {
request.header.append("some-new-header", "some-value");
// Add your headers here
return next(request);
},
],
});
return (
<TransportProvider transport={transport}>
<QueryClientProvider client={queryClient}>
<YourApp />
</QueryClientProvider>
</TransportProvider>
);
};
For more details about what you can do with the transport, see the Connect-Web documentation.
const useTransport: () => Transport;
Use this helper to get the default transport that's currently attached to the React context for the calling component.
Tip
All hooks accept a transport
in the options. You can use the Transport from the context, or create one dynamically. If you create a Transport dynamically, make sure to memoize it, because it is taken into consideration when building query keys.
function useQuery<
I extends DescMessage,
O extends DescMessage,
SelectOutData = MessageShape<O>,
>(
schema: DescMethodUnary<I, O>,
input?: SkipToken | MessageInitShape<I>,
{ transport, ...queryOptions }: UseQueryOptions<I, O, SelectOutData> = {},
): UseQueryResult<SelectOutData, ConnectError>;
The useQuery
hook is the primary way to make a unary request. It's a wrapper around TanStack Query's useQuery
hook, but it's preconfigured with the correct queryKey
and queryFn
for the given method.
Any additional options
you pass to useQuery
will be merged with the options that Connect-Query provides to @tanstack/react-query. This means that you can pass any additional options that TanStack Query supports.
Identical to useQuery but mapping to the useSuspenseQuery
hook from TanStack Query. This includes the benefits of narrowing the resulting data type (data will never be undefined).
function useInfiniteQuery<
I extends DescMessage,
O extends DescMessage,
ParamKey extends keyof MessageInitShape<I>,
>(
schema: DescMethodUnary<I, O>,
input:
| SkipToken
| (MessageInitShape<I> & Required<Pick<MessageInitShape<I>, ParamKey>>),
{
transport,
pageParamKey,
getNextPageParam,
...queryOptions
}: UseInfiniteQueryOptions<I, O, ParamKey>,
): UseInfiniteQueryResult<InfiniteData<MessageShape<O>>, ConnectError>;
The useInfiniteQuery
is a wrapper around TanStack Query's useInfiniteQuery
hook, but it's preconfigured with the correct queryKey
and queryFn
for the given method.
There are some required options for useInfiniteQuery
, primarily pageParamKey
and getNextPageParam
. These are required because Connect-Query doesn't know how to paginate your data. You must provide a mapping from the output of the previous page and getting the next page. All other options passed to useInfiniteQuery
will be merged with the options that Connect-Query provides to @tanstack/react-query. This means that you can pass any additional options that TanStack Query supports.
Identical to useInfiniteQuery but mapping to the useSuspenseInfiniteQuery
hook from TanStack Query. This includes the benefits of narrowing the resulting data type (data will never be undefined).
function useMutation<I extends DescMessage, O extends DescMessage>(
schema: DescMethodUnary<I, O>,
{ transport, ...queryOptions }: UseMutationOptions<I, O, Ctx> = {},
): UseMutationResult<MessageShape<O>, ConnectError, PartialMessage<I>>;
The useMutation
is a wrapper around TanStack Query's useMutation
hook, but it's preconfigured with the correct mutationFn
for the given method.
Any additional options
you pass to useMutation
will be merged with the options that Connect-Query provides to @tanstack/react-query. This means that you can pass any additional options that TanStack Query supports.
function createConnectQueryKey<Desc extends DescMethod | DescService>(
params: KeyParams<Desc>,
): ConnectQueryKey;
This function is used under the hood of useQuery
and other hooks to compute a queryKey
for TanStack Query. You can use it to create (partial) keys yourself to filter queries.
useQuery
creates a query key with the following parameters:
- The qualified name of the RPC.
- The transport being used.
- The request message.
To create the same key manually, you simply provide the same parameters:
import { createConnectQueryKey, useTransport } from "@connectrpc/connect-query";
import { ElizaService } from "./gen/eliza_pb";
const myTransport = useTransport();
const queryKey = createConnectQueryKey({
schema: ElizaService.method.say,
transport: myTransport,
// You can provide a partial message here.
input: { sentence: "hello" },
// This defines what kind of request it is (either for an infinite or finite query).
cardinality: "finite",
});
// queryKey:
[
"connect-query",
{
transport: "t1",
serviceName: "connectrpc.eliza.v1.ElizaService",
methodName: "Say",
input: { sentence: "hello" },
cardinality: "finite",
},
];
You can create a partial key that matches all RPCs of a service:
import { createConnectQueryKey } from "@connectrpc/connect-query";
import { ElizaService } from "./gen/eliza_pb";
const queryKey = createConnectQueryKey({
schema: ElizaService,
cardinality: "finite",
});
// queryKey:
[
"connect-query",
{
serviceName: "connectrpc.eliza.v1.ElizaService",
cardinality: "finite",
},
];
Infinite queries have distinct keys. To create a key for an infinite query, use the parameter cardinality
:
import { createConnectQueryKey } from "@connectrpc/connect-query";
import { ListService } from "./gen/list_pb";
// The hook useInfiniteQuery() creates a query key with cardinality: "infinite",
// and passes on the pageParamKey.
const queryKey = createConnectQueryKey({
schema: ListService.method.list,
cardinality: "infinite",
pageParamKey: "page",
input: { preview: true },
});
function callUnaryMethod<I extends DescMessage, O extends DescMessage>(
transport: Transport,
schema: DescMethodUnary<I, O>,
input: MessageInitShape<I> | undefined,
options?: {
signal?: AbortSignal;
},
): Promise<O>;
This API allows you to directly call the method using the provided transport. Use this if you need to manually call a method outside of the context of a React component, or need to call it where you can't use hooks.
Creates a typesafe updater that can be used to update data in a query cache. Used in combination with a queryClient.
import { createProtobufSafeUpdater, useTransport } from '@connectrpc/connect-query';
import { useQueryClient } from "@tanstack/react-query";
...
const queryClient = useQueryClient();
const transport = useTransport();
queryClient.setQueryData(
createConnectQueryKey({
schema: example,
transport,
input: {},
cardinality: "finite",
}),
createProtobufSafeUpdater(example, (prev) => {
if (prev === undefined) {
return undefined;
}
return {
...prev,
completed: true,
};
})
);
function createQueryOptions<I extends DescMessage, O extends DescMessage>(
schema: DescMethodUnary<I, O>,
input: SkipToken | PartialMessage<I> | undefined,
{
transport,
}: {
transport: Transport;
},
): {
queryKey: ConnectQueryKey;
queryFn: QueryFunction<MessageShape<O>, ConnectQueryKey> | SkipToken;
structuralSharing: (oldData: unknown, newData: unknown) => unknown;
};
A functional version of the options that can be passed to the useQuery
hook from @tanstack/react-query
. When called, it will return the appropriate queryKey
, queryFn
, and structuralSharing
flag. This is useful when interacting with useQueries
API or queryClient methods (like ensureQueryData, etc).
An example of how to use this function with useQueries
:
import { useQueries } from "@tanstack/react-query";
import { createQueryOptions, useTransport } from "@connectrpc/connect-query";
import { example } from "your-generated-code/example-ExampleService_connectquery";
const MyComponent = () => {
const transport = useTransport();
const [query1, query2] = useQueries([
createQueryOptions(example, { sentence: "First query" }, { transport }),
createQueryOptions(example, { sentence: "Second query" }, { transport }),
]);
...
};
function createInfiniteQueryOptions<
I extends DescMessage,
O extends DescMessage,
ParamKey extends keyof MessageInitShape<I>,
>(
schema: DescMethodUnary<I, O>,
input:
| SkipToken
| (MessageInitShape<I> & Required<Pick<MessageInitShape<I>, ParamKey>>),
{
transport,
getNextPageParam,
pageParamKey,
}: ConnectInfiniteQueryOptions<I, O, ParamKey>,
): {
getNextPageParam: ConnectInfiniteQueryOptions<
I,
O,
ParamKey
>["getNextPageParam"];
queryKey: ConnectInfiniteQueryKey<I>;
queryFn:
| QueryFunction<
MessageShape<O>,
ConnectInfiniteQueryKey<I>,
MessageInitShape<I>[ParamKey]
>
| SkipToken;
structuralSharing: (oldData: unknown, newData: unknown) => unknown;
initialPageParam: PartialMessage<I>[ParamKey];
};
A functional version of the options that can be passed to the useInfiniteQuery
hook from @tanstack/react-query
.When called, it will return the appropriate queryKey
, queryFn
, and structuralSharing
flags, as well as a few other parameters required for useInfiniteQuery
. This is useful when interacting with some queryClient methods (like ensureQueryData, etc).
Transports are taken into consideration when building query keys for associated queries. This can cause issues with SSR since the transport on the server is not the same transport that gets executed on the client (cannot be tracked by reference). To bypass this, you can use this method to add an explicit key to the transport that will be used in the query key. For example:
import { addStaticKeyToTransport } from "@connectrpc/connect-query";
import { createConnectTransport } from "@connectrpc/connect-web";
const transport = addStaticKeyToTransport(
createConnectTransport({
baseUrl: "https://demo.connectrpc.com",
}),
"demo",
);
type ConnectQueryKey = [
/**
* To distinguish Connect query keys from other query keys, they always start with the string "connect-query".
*/
"connect-query",
{
/**
* A key for a Transport reference, created with createTransportKey().
*/
transport?: string;
/**
* The name of the service, e.g. connectrpc.eliza.v1.ElizaService
*/
serviceName: string;
/**
* The name of the method, e.g. Say.
*/
methodName?: string;
/**
* A key for the request message, created with createMessageKey(),
* or "skipped".
*/
input?: Record<string, unknown> | "skipped";
/**
* Whether this is an infinite query, or a regular one.
*/
cardinality?: "infinite" | "finite";
},
];
TanStack Query manages query caching for you based on query keys. QueryKey
s in TanStack Query are arrays with arbitrary JSON-serializable data - typically handwritten for each endpoint. In Connect-Query, query keys are more structured, since queries are always tied to a service, RPC, input message, and transport. For example, a query key might look like this:
[
"connect-query",
{
transport: "t1",
serviceName: "connectrpc.eliza.v1.ElizaService",
methodName: "Say",
input: {
sentence: "hello there",
},
cardinality: "finite",
},
];
The factory createConnectQueryKey
makes it easy to create a ConnectQueryKey
, including partial keys for query filters.
Connect-query (along with all other javascript based connect packages) can be tested with the createRouterTransport
function from @connectrpc/connect
. This function allows you to create a transport that can be used to test your application without needing to make any network requests. We also have a dedicated package, @connectrpc/connect-playwright for testing within playwright.
For playwright, you can see a sample test here.
Each function that interacts with TanStack Query also provides for options that can be passed through.
import { useQuery } from '@connectrpc/connect-query';
import { example } from 'your-generated-code/example-ExampleService_connectquery';
export const Example: FC = () => {
const { data } = useQuery(example, undefined, {
// These are typesafe options that are passed to underlying TanStack Query.
refetchInterval: 1000,
});
return <div>{data}</div>;
};
Here is a high-level overview of how Connect-Query fits in with Connect-Web and Protobuf-ES:
Your Protobuf files serve as the primary input to the code generators protoc-gen-connect-query
and protoc-gen-es
. Both of these code generators also rely on primitives provided by Protobuf-ES. The Buf CLI produces the generated output. The final generated code uses Transport
from Connect-Web and generates a final Connect-Query API.
Transport
is a regular JavaScript object with two methods, unary
and stream
. See the definition in the Connect-Web codebase here. Transport
defines the mechanism by which the browser can call a gRPC-web or Connect backend. Read more about Transport on the connect docs.
You can use Connect-Web and Connect-Query together if you like!
Connect-Query also supports gRPC-web! All you need to do is make sure you call createGrpcWebTransport
instead of createConnectTransport
.
That said, we encourage you to check out the Connect protocol, a simple, POST-only protocol that works over HTTP/1.1 or HTTP/2. It supports server-streaming methods just like gRPC-Web, but is easy to debug in the network inspector.
If the Transport
attached to React Context via the TransportProvider
isn't working for you, then you can override transport at every level. For example, you can pass a custom transport directly to the lowest-level API like useQuery
or callUnaryMethod
.
Connect-Query does require React, but the core (createConnectQueryKey
and callUnaryMethod
) is not React specific so splitting off a connect-solid-query
is possible.
When you might not have access to React context, you can use the create
series of functions and provide a transport directly. For example:
import { say } from "./gen/eliza-ElizaService_connectquery";
function prefetch() {
return queryClient.prefetchQuery({
queryKey: createConnectQueryKey({
schema: say,
transport: myTransport,
input: { sentence: "Hello" },
cardinality: "finite",
}),
queryFn: () => callUnaryMethod(myTransport, say, { sentence: "Hello" }),
});
}
Tip
Transports are taken into consideration when building query keys. If you want to prefetch queries on the server, and hydrate them in the client, make sure to use the same transport key on both sides with addStaticKeyToTransport
.
Connect-Query currently only supports Unary RPC methods, which use a simple request/response style of communication similar to GET or POST requests in REST. This is because it aligns most closely with TanStack Query's paradigms. However, we understand that there may be use cases for Server Streaming, Client Streaming, and Bidirectional Streaming, and we're eager to hear about them.
At Buf, we strive to build software that solves real-world problems, so we'd love to learn more about your specific use case. If you can provide a small, reproducible example, it will help us shape the development of a future API for streaming with Connect-Query.
To get started, we invite you to open a pull request with an example project in the examples directory of the Connect-Query repository. If you're not quite sure how to implement your idea, don't worry - we want to see how you envision it working. If you already have an isolated example, you may also provide a simple CodeSandbox or Git repository.
If you're not yet at the point of creating an example project, feel free to open an issue in the repository and describe your use case. We'll follow up with questions to better understand your needs.
Your input and ideas are crucial in shaping the future development of Connect-Query. We appreciate your input and look forward to hearing from you.
Offered under the Apache 2 license.