How are they defined separately?

Qqingmu

1/9/2023

I am using monorepo for my project design and I want to separate the definition of trpc completely independently. I have @app/api to take care of implementing the trpc api definitions in @app/api-define. I want to define all trpc api content ( type define ) in @app/api-define as a separate package. Then I just need to use @app/api-define in @api/next-app. As a standalone package, I can even use it in a different project, or convert it to an rpc specification that other languages will recognize.

Nnlucas

1/9/2023

tRPC doesn’t really work that way, the types come from the implementation, as opposed to OO-land where the implementation is often built on predesigned interfaces It’s not an anti-pattern here to just “import type from” the api directly from the client, you won’t bundle the entire API into your frontend if you do it right

Qqingmu

1/9/2023

import type from is also an imported type, why can't it be alone?

Nnlucas

1/9/2023

Not sure I understand what you mean

Qqingmu

1/9/2023

import type from somebody Import types only, and will not contain code

Nnlucas

1/9/2023

Yes, the client only needs the types from the API

Qqingmu

1/9/2023

So, can I declare my own AppRouter for trpc? Do not use export type AppRouter = typeof appRouter;

Nnlucas

1/9/2023

You might want to take a look at the example projects and see how the maintainers structure this stuff, the recommended patterns are quite consistent

Qqingmu

1/9/2023

I have to import type from my backend code, and I can't distribute GraphQL Schema files like GraphQ L does.

Nnlucas

1/9/2023

Yes, that’s correct. You could publish the typescript types as a npm package but the batteries aren’t included there. trpc is designed for co-located client/server code first

Qqingmu

1/9/2023

So I'm looking for a solution, if the client of trpc only needs one type file, can I define it manually?

Jjulius

1/9/2023

hey, don't completely understand the goal of what you're trying to do - have you checked out https://github.com/t3-oss/create-t3-turbo ? there, we have our api package which exports the router and it's type: https://github.com/t3-oss/create-t3-turbo/blob/main/packages/api/index.ts and the nextjs api handler can import the router: https://github.com/t3-oss/create-t3-turbo/blob/main/apps/nextjs/src/pages/api/trpc/%5Btrpc%5D.ts and to create the hooks, we just need the types: https://github.com/t3-oss/create-t3-turbo/blob/29d207dc197454dd0a5b8b18287f9594e2cdfa53/apps/nextjs/src/utils/api.ts#L5 and then for apps which aren't serving the router but just consuming the api, they also just need the types: https://github.com/t3-oss/create-t3-turbo/blob/597ec9861a3da0ac9e631b9a240420b62e89253b/apps/testy/client.ts#L2 but i dont understand why you want the type in a separate package?

Qqingmu

1/9/2023

I checked the code inside, not what I want I need trpc to be split into type definition and implementation, not merged together. It is still together in t3, it is difficult for me to encapsulate the framework belonging to our company based on trpc. In the way of importing types (import type from tsrpc_api), once some other code on the server is imported in my code, it will be packaged into the front-end project. I even need to write some tools for security inspections. I generally use https://nx.dev for project design. I write an API it should be an app rather than library.

Nnlucas

1/9/2023

It won’t be packaged into the project, I also use Nx and importing by type will not cause your whole backend to be bundled This was the second thing I said Types are stripped at compile time and all imports via type imports will get dropped and tree-shaken

Qqingmu

1/9/2023

but in nx, api should be an application, and the application does not import aliases It can be set manually but I prefer to separate them. One of our projects has a lot of developers involved and I need to write some checks to make sure all are obeying using type imports, which can be a disaster if someone forgets. my doubt is that for trpc, only the type definition is required when creating the client. Why is this type definition forced to be written together with the server instead of separate?

Nnlucas

1/9/2023

Nx can ban imports of projects via eslint, in-fact you would have to disable this in order to import the api because it’s an application. So you can just disable for the one line in your client which is allowed to import it, then re-export and force everyone else to import from that file Ultimately if you don’t trust this stuff then you probably chose the wrong solution for your backend.

Jjulius

1/9/2023

If someone imports appRouter instead of type AppRouter your app will blow up and not run - since you’d be importing server code on the client - you would get errors which is quite easy to test against. Alternatively you can restrict imports with lint rules as Nick suggests

CCaptain

1/9/2023

im also using nx as a monorepo workspace. what u need to do i create a node library wheren ur trpc definitions and routes go. in your next app, the trpc utils for batching and stuff like that go in the uitls folder at the same level as your next app it took me a while to figure this out. trpc is not a stand alone app. in NX apps cant share types/code but libs can this my nx graph

CCaptain

1/9/2023

CCaptain

1/9/2023

business-data-access and shared-data-access are both node libraries business-data-access implements a node library which has all the routes for the nextjs business app. shared-data-access exports shared code for all applications. such a context. but also auth. since this workspace will have two applications and both will have the same logic also important to note is, smart components need to live in your next app. and dumb components that do not have access to data can be exported from a library the reason for this is that the trpc utils folders lives inside your nextjs src folder. and sadly apps cant share code