lukas
Explore posts from serversIntegrating hono.js with tRPC in Next.js: Routing and Context Considerations
Trpc client is a different thign from the servcer, is how you consume data. In order to use it in both client and server you need to do tricks and configurations, personally I just use trpc at the client and don't mess with server side, etc. But it should work. 🙂
21 replies
Integrating hono.js with tRPC in Next.js: Routing and Context Considerations
1. Trpc context is something that is available through all the procedures, usually helpful to add auth information.
2. On every request you can build a trpc context object, e.g extracting a token from the request header and decoding into an user id, or looking up an user in the db, etc.
3. Hono context is something that is available only inside hono
get
and post
and can be passed to TRPC context as well.
HONO - get
post
- hono context can be acessed during this
TPRC procedures
that receive the TRPC context.
I suggest you reading the full docs and understanding the core difference between those.21 replies
Integrating hono.js with tRPC in Next.js: Routing and Context Considerations
Option 1. N -> H -> T (this is to use
src/app/api/[[...route]
) as the example below
Option 2. N -> T - You use the tprc adapter for nextjs directly and src/app/api/trpc/[trpc]/route
I think you might missunderstanding what's the purpose goal of HonoJS, vs nextjs api/server and how they interact with TRPC21 replies
Integrating hono.js with tRPC in Next.js: Routing and Context Considerations
So it all depends, you are using HONO on top of nextjs - and trpc on top of hono. So
USER -> Next api -> HONO -> trpc.
Why you are using HONO with next? IMHO you should do it only if considering moving to something else or having consistency.
If you decide to keep using HONO it should be on app[[..route]] otherwise if using next directly on api trpc and so on.
21 replies
Transform server response on the client before caching
Yes, makes sense - "sometimes is not possible" - yeah, those cases where we don't have control of the backend definitely we need something in the f.e to shape the data haha. But I guess if trpc allow to override the query fn would be a anti-pattern and better to use the raw
trpc client
and just call the async function together with react query - can't think a lot of useful scenarios for that, since when someone is using trpc the whole idea is to have control of the full stack code. Anyway, thanks for sharing your findings 🙂12 replies
Transform server response on the client before caching
Hey @João Bezerra nice that you got that solved at the end, but I definitely think that transforming and parsing data in the client side/frontend is definitely a bad choice - except for scenarios that we have no control of our backend or is impossible to change it - it's a personal opinion but throughout the years I have seem too many issues/frontend problems because the shape of the data doesn't match on how the frontend needs it, definitely it adds more complexity, like in your cause, you are calling procedures inside the query FN, which is breaking the integration to use just trpc out of the box.
But at the end glad you got it solved 🙂
But at the end glad you got it solved 🙂
12 replies
Transform server response on the client before caching
I think the way to go is use selector, in react query you could customize the queryFn but not sure on trpc. Anyway this is an anti patern if the server is returning the data not in the shape that the frontend needs, that's why I'd definitely create a new method or talk to your backend devs to modify the existent.
12 replies
Transform server response on the client before caching
Why transform the response on the client? I believe this is not optimal and can't you just send the data from the server exactlly on the way the client will use it to avoid unecessary bandwidght, etc?
Alternatively you can use
selectors
of react-query to filter/select only specfic fields of your data before reading that in the component.12 replies
It is possible to define a middleware for all routes?
Yeah, that makes sense. I am replicating it again but in my case is because I am developing a multi tenancy app where I have multiple roles and I am developing a sub route for each Roles as trpc/next doesn't support multi trpc clients atm yet
11 replies