Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

tRPC – Build and consume typesafe APIs without schemas or code generation

trpc.io

Post reply on HN
Print view View original

211–220 of 223 posts

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#211

Post by yencabulator »

c-hendricks wrote: post #210
yencabulator wrote: post #207

Earlier quoted context omitted.

Lovely attitude, you have a nice day too. There's others expressing the same concerns, for example https://news.ycombinator.com/item?id=37101393

What's your solution though? To me, if the server has updated it's schema and the client has old code, the server responds with an error, the user sees "something went wrong". And if the validation fails on the client side, the user sees "something went wrong" And if the client isn't doing validation of what's returned, and an error gets thrown because it tried to access a now missing field, the user sees ... "someth…

With an explicit error you get from validation (like Zod, as used in tRPC), you could notice that your client is out of date and either refresh automatically or prompt the user to refresh[1].

The benefit from validation is that the error is easily recognizable & can be handled nicely, even in just one place. Without validation, you get things that Typescript claims are impossible, for example exceptions on code paths that look like they cannot throw, and you can't easily tell why any of that happened -- that's a recipe for miserable debugging. Of course, with less busy, less critical, sites you might not notice or care.

[1]: Refresh could cause loss of user input (e.g. text just entered), depending on the app that might matter and need browser-side storage or something along the lines of the "local first" manifesto. Easy kludge for simple apps with smart users is to make the user copy the text, click refresh, paste.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#212

Post by c-hendricks »

yencabulator wrote: post #211
c-hendricks wrote: post #210

Earlier quoted context omitted.

What's your solution though? To me, if the server has updated it's schema and the client has old code, the server responds with an error, the user sees "something went wrong". And if the validation fails on the client side, the user sees "something went wrong" And if the client isn't doing validation of what's returned, and an error gets thrown because it tried to access a now missing field, the user sees ... "someth…

With an explicit error you get from validation (like Zod, as used in tRPC), you could notice that your client is out of date and either refresh automatically or prompt the user to refresh[1]. The benefit from validation is that the error is easily recognizable & can be handled nicely, even in just one place. Without validation, you get things that Typescript claims are impossible, for example exceptions on code paths…

Isn't that only for one case of errors though (server not matching expected response)?

One solution I thought was clever, was a friend's single-page app would hard-reload on navigation, if there was an update to the assets. Not sure how feasible that would be for schema errors though.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#213

Post by bborud »

wruza wrote: post #142
bborud wrote: post #51

Earlier quoted context omitted.

I'm not too surprised. Most people for whom TypeScript is an option won't have been exposed to generations of RPCs that fail to deliver simplicity. So it isn't going to be on their radar. I've been using gRPC and REST'ish+JSON APIs for years now and what I find puzzling is that REST+JSON tends to mean a lot more work, less pleasing code than gRPC, and yet people prefer it. Not because it leads to simpler, better, fas…

I agree that sticking to just a library may be not a good choice. Some standard would be better. But few last times I discussed it, some folks just slapped RPC stigma on everything, even if it was just your regular REST-y-ish calls underneath. That’s absurd. POST json receive json back is okay. Wrap it into an `await server. ( )` call and now it’s an RPC mudball. The current top commenter is removing tRPC for tight c…

> Some standard would be better

Careful what you wish for. Standards that aren't quite good enough can be worse than not having standards. Because then at least then people will keep looking for something that might be better.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#214

Post by yencabulator »

c-hendricks wrote: post #212
yencabulator wrote: post #211

Earlier quoted context omitted.

With an explicit error you get from validation (like Zod, as used in tRPC), you could notice that your client is out of date and either refresh automatically or prompt the user to refresh[1]. The benefit from validation is that the error is easily recognizable & can be handled nicely, even in just one place. Without validation, you get things that Typescript claims are impossible, for example exceptions on code paths…

Isn't that only for one case of errors though (server not matching expected response)? One solution I thought was clever, was a friend's single-page app would hard-reload on navigation, if there was an update to the assets. Not sure how feasible that would be for schema errors though.

Between that and catching 400 Bad Requests coming back from the server, you're pretty much catching any communication errors resulting from version skew.

SvelteKit can poll to check server version and refresh, both on timer and if assets are 404. But as you implied, that doesn't help with API evolution and e.g. users interacting with a form (apart from increasing the likelihood the page will refresh soonish due to navigation).

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#215

Post by Cannabat »

pcthrowaway wrote: post #179
Cannabat wrote: post #172

Earlier quoted context omitted.

TS is a pain with JSON Schema or OpenAPI because it doesn't directly support things like integer or precision. TS does not easily support things like `"exclusiveMinimum": 5`, `"type": "integer"` or patterned (regex) fields. So if you want to convert your TS interfaces to JSON Schema, you may need to provide additional constraints via JSDoc and use a generator that understands those annotations. But your TS interfaces…

You can easily express constraints like these with Zod though (created by the same person who created tRPC v1)

Sure, if you have TS in your backend. There are OpenAPI to zod generators that can help get you started, even if they don’t give you perfect zod schemas out the gate.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#216

Post by vosper »

Supermancho wrote: post #194
vosper wrote: post #158

Earlier quoted context omitted.

You can make calls to tRPC endpoints from anything that can send an HTTP request. The RPC format for requests might not be your cup of tea, but it works.

Ostensibly, the product isn't as useful as the existing gotos (json schemas, shared libraries, graphql, etc), if you cannot create a shareable schema for validation. The ability to form arbitrary requests is already assumed. If your messages are very complex, you need some tooling.

If you’re in TS world then you can export the Zod schema that your tRPC queries/mutations are using.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#217

Post by Timon3 »

Timon3 wrote: post #167
Timon3 wrote: post #154

Earlier quoted context omitted.

Update: I was able to get this working by wrapping WebSocket and WebSocketServer! The API surface for the wrapper seems to be pretty minimal. If I do use TRPC in the rewrite of the embedded server, I'll implement a custom message scheme as an alternative and benchmark them. Here's a gist with the wrappers (transporting the data as a JSON array instead of a dict): https://gist.github.com/TimonLukas/7c757a3b234344ad71e…

Update: I've now implemented a small PoC with ID negotation, you can see it here: https://gist.github.com/TimonLukas/c0bb7e8f9bde9d3d74d6b776b... This will reduce message size quite a bit, since the data isn't sent as: { "id": 3, "method": "subscription.stop" } but instead as: [3,1]

Update: I've implemented a simple TS library around this: https://github.com/TimonLukas/ts-websocket-compressor

I will add wrappers for WebSocket/WebSocketServer in the future to allow using this without the library having to support it, like in the PoC with trpc.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#218

Post by 9935c101ab17a66 »

ShadowBanThis01 wrote: post #209
9935c101ab17a66 wrote: post #203

Earlier quoted context omitted.

> Schema validation provides assurance that data is strictly similar to a set of patterns, structures, and data types you have provided. It helps identify quality issues earlier in your codebase and prevents errors that arise from incomplete or incorrect data types. From: https://blog.logrocket.com/schema-validation-typescript-zod/ Most common use case I’ve seen is using schema validation for user input (like forms)…

Thanks for the reply! I know what schema validation is, but didn't see what kind of schemas Zod was intended for. In other words, what is it parsing? That post you linked to looks very informative.

I wrote a reply but then I found this and it’s a perfect explainer: https://www.totaltypescript.com/when-should-you-use-zod

Matt is awesome! If you have any more questions I’ll do my best to answer them.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#219

Post by taswellian »

Cannabat wrote: post #174
purkka wrote: post #21

Earlier quoted context omitted.

In our current project with a TS frontend and Python backend, we use an OpenAPI schema as the source of truth and openapi-typescript-codegen [0] to interface with it on the client side. While not perfect, it provides a very nice interface to our API with request/response typings. I also wrote a 10-line mock API wrapper that you can call as mockApi ((request) => response), and it will type-check that your mock functio…

Another great library to generate TS types from OpenAPI is https://github.com/drwpow/openapi-typescript . It provides the types as single objects you access via indexing, which is pretty nice. There's a partner library to generate a typed fetch client.

Do you know if there's something similar for Python? Or what approach would you use for Python?

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#220

Post by Cannabat »

taswellian wrote: post #219
Cannabat wrote: post #174

Earlier quoted context omitted.

Another great library to generate TS types from OpenAPI is https://github.com/drwpow/openapi-typescript . It provides the types as single objects you access via indexing, which is pretty nice. There's a partner library to generate a typed fetch client.

Do you know if there's something similar for Python? Or what approach would you use for Python?

Like generating pydantic models or dataclasses for an OpenAPI schema? I haven't needed to go in that direction myself, but this[0] looks promising!

Apologies if I've misunderstood your comment

https://koxudaxi.github.io/datamodel-code-generator/

Post reply on HN