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

221–223 of 223 posts

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

#221

Post by taswellian »

Cannabat wrote: post #220
taswellian wrote: post #219

Earlier quoted context omitted.

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/

This looks interesting, thank you!

I'm basically wondering what would help us produce (automatically?) a Python HTTP client based an OpenAPI spec, and achieve a development experience similar to using drwpow/openapi-typescript.

drwpow/openapi-typescript will generate the whole schema, along with paths, request and response models, as well as path and query parameters. In the IDE, all client methods will be type-safe and autocompleted.

Example:

  client = createClient();
  
  client.get("/my/autocompleted/endpoint/{some_param}", { params: { path: { some_param: "foobar" } } })
koxudaxi/datamodel-code-generator seems to generate the response models, but not much else. It seems we would have to manually write wrapper methods for each endpoint, manually specify the parameters and request models, and use a type hint for the return value of each method with the generated response model.

Example:

  def my_wrapped_endpoint(...) -> ResponseModel:
    pass

  client.my_wrapped_endpoint(some_param="foobar")
I'd like to avoid any manual wrapping or at least minimize the amount of it. Basically: to achieve a similar experience to what we have in TypeScript.

I hope my question is a bit clearer now. I'm not that familiar with Python, so I will appreciate any guidance regarding this problem. :)

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

#222

Post by Cannabat »

taswellian wrote: post #221
Cannabat wrote: post #220

Earlier quoted context omitted.

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/

This looks interesting, thank you! I'm basically wondering what would help us produce (automatically?) a Python HTTP client based an OpenAPI spec, and achieve a development experience similar to using drwpow/openapi-typescript. drwpow/openapi-typescript will generate the whole schema, along with paths, request and response models, as well as path and query parameters. In the IDE, all client methods will be type-safe…

Gotcha. I’m not sure what options are out there. Haven’t needed to do any codegen to python - only from python.

For all its issues, the JS world typically provides an excellent developer experience and takes types far more seriously than python.

Hope you find something that helps, and if you do I’d love to hear about it.

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

#223

Post by taswellian »

Cannabat wrote: post #222
taswellian wrote: post #221

Earlier quoted context omitted.

This looks interesting, thank you! I'm basically wondering what would help us produce (automatically?) a Python HTTP client based an OpenAPI spec, and achieve a development experience similar to using drwpow/openapi-typescript. drwpow/openapi-typescript will generate the whole schema, along with paths, request and response models, as well as path and query parameters. In the IDE, all client methods will be type-safe…

Gotcha. I’m not sure what options are out there. Haven’t needed to do any codegen to python - only from python. For all its issues, the JS world typically provides an excellent developer experience and takes types far more seriously than python. Hope you find something that helps, and if you do I’d love to hear about it.

Thanks! I'll keep looking for a solution and keep you in the loop once we figure something out.
Post reply on HN