david
How to treat mongoose/mongodb ObjectIDs as their serialized string values on the frontend?
Hey @BenZ just saw you upvoted. Incase it's of use to you, apologies realised I hadn't updated my thread. A sort of non-perfect solution i created was a utility function that wraps the return statement in any query, it is based off of the supported superjson types, i havent had any issues with it so far, your mileage may vary though!
e.g
3 replies
Need help with performance
@spaghet we had a discussion about this not so long ago here https://discord.com/channels/867764511159091230/1260588869967937556
i was initially concerned about the performance and diving head first before using it. as i mentioned in the discussion, the solution that worked for me (not saying it will necessarily work for everyone, or if it’ll be supported forever) was xTRPC which just outputs a generated type file that i use. the downside is you can no longer jump to file/type however personally ill take the extra minute or so it’ll take me to find whatever reference i’m looking for when i need to vs waiting for the language server every time
other solutions were mentioned too
https://github.com/algora-io/xtrpc
5 replies
Forward NextJs Request to TRPC Server
Hey, i’ll give my two cents but others might have better ideas.
Any chance you could give some context to why you want to split the servers up firstly?
Katt spoke about it somewhere a while ago, but if these are completely separate servers and not running off of the same service you’ll need to go over network for communication and look at the vanilla client https://trpc.io/docs/client/vanilla/setup. So you’d use that for your Next -> tRPC integration where Next calls your tRPC service.
The tricky problem to solve would be type definitions, to be honest Im not quite sure how best you’d achieve this. My only recommendation is that you pass the tRPC type definitions to your NextJS client additionally and then use things like RouterOutput/RouterInput
https://trpc.io/docs/client/vanilla/infer-types
which would allow you to still keep your data typed whilst still communicating first via the Next Server (you’d have to setup endpoint management etc yourself). But I don’t think it’ll be possible to get the full type definitions if you aren’t communicating directly between tRPC.
Unless you are basically mirroring endpoints between the next server and tRPC server it might be a bit tough to get the full feature set
10 replies
I commented my query out, but i still notice request are still been made. this is what my code look
My only other idea is that it's something to do with your TRPCProvider, if getHeaders is being called multiple times that would suggest either a higher level context is recalculating it I think, or that something is happening in your useSupabaseClient.
I can't be too sure, so someone else would have to chime in if they have other advice. But my recommendation in situations like this would be to try and strip back your code as much as possible. So you have the most basic implementation created where you successfully have it so that only one request occurs.
https://trpc.io/docs/client/react/setup
Basically following the above here ^ (But hard coding the api.challenges.list.useQuery input etc..)
Then, begin slowly adding things back until you can see where multiple requests occur.
14 replies
I commented my query out, but i still notice request are still been made. this is what my code look
@Sigo what happens if you hard code the values in? Something like the following:
Just to try and eliminate any external state variables first.
14 replies
how do I fix this
@toadmilk is your app wrapped in the react query context provider? https://trpc.io/docs/client/react/setup shown here
6 replies
Is it possible to have more than one TRPC client (React Query)?
@ryders_dad might be a bit cumbersome to deal with, there was some similar convo about it on GH though. perhaps this can give you some direction?
https://github.com/trpc/trpc/discussions/1990
3 replies
How do I return a plain text in trpc?
@Bytes have you seen this by any chance? https://github.com/codingwithmanny/trpc-siwe-monorepo
just had a quick search and came across it, i don’t know the exact auth flow but I imagine this is somewhat similar to what you’re trying to achieve no?
8 replies
How do I return a plain text in trpc?
@Bytes just out of complete curiosity, what are you looking to achieve? Why specifically do you need to return 'ok' versus say {success: true}
Is it like a specific api/endpoint that you need to return 'OK' to? Or that a service is checking for?
8 replies
is there a definitive solution to the slow language server/compilation issue?
@tltl not using .output on our end either. As Gabriel said some good comments from Alex about what you could try alternatively there. But someone mentioned on the GH about a similar had issue https://github.com/algora-io/xtrpc/issues/3 so perhaps you might need to change some things in your tsconfig?
Maybe also try and narrow down your AppRouter to begin with if you want to go down this direction further
8 replies
How to improve typescript performance?
Have either of you guys had a look into xtrpc? Mentioned it on a similar issue a few hours ago, but I've found it quite beneficial at the moment. I'm not sure how well it'll translate to larger scale. But on a pretty non-scientific test. It worked much better especially with the language server. It's not live, but have it running on a separate process via nodemon to regen the types
https://github.com/algora-io/xtrpc
57 replies
Express.JS and tRPC
@MaLeK In terms of communicating between a client and a server yes of course. But they definitely lean to different needs/use cases.
The biggest thing being that if you have a tightly coupled frontend/backend both built in typescript in my opinion tRPC is a no brainer. Alternatively, say you needed to build an backend which links to other projects where the ownership isn't exactly under the same repo or your control then tRPC is going to be more difficult to implement and the disadvantages begin to increase versus the advantages, you'd arguably find a more customizable experience with something like to express.
Express:
- Web framework for building/managing HTTP-based applications.
- A pretty robust/matured routing, middleware and way of structuring a server.
- Most ideal for building traditional RESTful APIs and web servers, especially where you might be connecting to other applications in the future out of your direct ownership in the same project 🙂 .
TRPC
- A focus on typesafe API applications
- Fantastic way to build shared API types between frontend and backends if you're already in the typescript especially in the same repo
- Integrated utilities/nice-to-haves like formatted error handling, input validation and data fetching on the frontend
It's not to say you cannot connect both express + trpc together, that's what Im doing at the moment with the express adapter, some endpoints are exposed not via tRPC for webhooks or to other applications that are out of our control. But for the ones that are, and which are in our monorepo it's a no brainer to use tRPC i've found. https://trpc.io/docs/server/adapters/express Could possibly help with various other things like exposing cookies/managing express middlewares
4 replies