Any way to access service context for non-nest.js and non-nice-grpc users in server impls?

[vimmerru]

Hi,

Seems the only way to generate service server interface that is aware about authentication or custom middleware context is generate the code for nest.js or nice-grpc.

I can't imagine the service without some context awareness.

Is it possible to generate any useful context-aware server stubs not being the user of nest.js or nice-grpc?

Thank you

[vimmerru]

Making service interface generic will most probably help here.

[stephenh]

@vimmerru if you're using the default output, you can use the context option that will add a go-style ctx param to the service methods (I think only the outputServices=default output supports the context option).

It's been awhile, but that is historically how I've liked to handle contexts in node.

If you have other suggestions, open to ideas / pull requests.

[turulix]

Is it possible to use context without it automatically generating methods using DataLoaders when using the default client implementation? I'm trying to use ts-proto within a Nuxt3 project, but I'm having trouble getting DataLoaders to work when building the project. (Vite seems to be interfering with things, and I've spent the last two days trying to figure out how to fix it).

[stephenh]

@turulix honestly I'm somewhat surprised you're seeing DataLoaders in your schema output; that was a cute/novel feature I'd added to ts-proto a long time ago, and it requires schemas following a certain convention that our internal systems happened to follow at the time.

So, I guess your schema must be unwittingly following the same convention we were, and so yeah the "this is a batch method" detection is kicking in.

Fwiw if your other PR fixes the dataloader imports and gets this working, personally I think its a cute feature so I'd be curious if you end up liking it/using it.

But, if you just want to skip it all together, then yeah a new dataloader=false config flag that turns off the batch method detection + extra singular method generation would be cool.

[turulix]

I don't mind the feature, but I was completely losing my mind over Vite's inability to handle the way it was imported during building, and how it would randomly throw runtime errors while building the project. Even though it worked perfectly fine in development, I didn't know the reason for its failure was due to the way it was imported. And at that time I just prefeared it working over having fancy batching and everything Dataloader offers haha. But this is fixed once my other pr is merged.