Not directly a sst question, but Does anyone have...
# help
m
Not directly a sst question, but Does anyone have a good way of creating type safe Http clients to use with functions? I feel like I spend 50% of my time writing bespoke code for making Http requests and getting the types right 😁 I use React (with react-query) and typescript for my functions.
t
I actually want to build something to solve this problem. I'm currently using GQL which already has tools to solve this but the ones for rest aren't great
m
I'm quite new to both typescript and nodejs, so might be a knowledge issue on my part... I feel like this should be a solved problem. JS typically has a library for everything.
t
There are things for it I've come across but nothing stuck as a good solution. Maybe others in here have more insight
This comes up but I'm against decorators https://github.com/lukeautry/tsoa
m
Interesting. I’ll have a look! I wouldn’t mind a bit of code generation 🙂
t
I want to build something where you can define your backend in TS (without decorators), statically extract an OpenAPI spec, and then use any of the generators with that. There's one for react-query
Also, checkout tRPC if you want end to end typesafety and don't mind moving to an rpc style framework
It comes with a react-query Integration
m
does that work with lambdas?
t
tRPC? I've actually never set it up in a lambda but it would probably require a mono-lambda
It should work though
m
I wouldn’t mind RPC:ing at all. I think all internal APIs can be RPCs
Ill give it a go!
t
I basically want to create a similar interface like this but for rest APIs
Hope it works for you!
m
Works great! 🙂
Thanks a lot
s
@thdxr: have you seen https://github.com/jlalmes/trpc-openapi? seems like it might get close to what you’re talking about.
t
no I hadn't - very cool!
this is basically what I was imagining
m
Looks nice!
I wrote down my steps to get tRPC working with SST: https://wahlstrand.dev/articles/2022-06-19-typesafe-http-client-serverless/
t
Awesome! Btw you can name the route
/{proxy+}
if you want to do a catch all to send to trpc
That way you're not defining stuff in two places
m
Is {proxy+} a magical word? 🙂
t
Yeah it is I think
Although I wonder if it works with any word in that format
m
The generic proxy resource can be denoted by a special templated path variable of
{proxy+}
,
https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
I guess
{path}
(or
{name}
) should work as well, since tPRC only needs 1 segment of our path anyway.