Hey guys. How do you handle end to end type support? Meaning the frontend knows which endpoint will return what and intellisense will error when you use incorrect properties.
#End to end type support? (frontend knowing which endpoint will return what)
neon creek
errant patrol
trpc is a popular option https://trpc.io/
neon creek
trpc is a popular option https://trpc.io/
Do you recommend tRPC, GraphQL, OpenAPI, or something else?
And which one is the standard way for full stack development?
lone plover
there's no one "standard way". different solutions are better for different use cases
one advantage GraphQL and OpenAPI have over tRPC is that they have tooling across a variety of languages, so you don't necessarily need your backend/microservices and frontend to all be written in typescript
OTOH tRPC provides a much more seamless out-of-the-box experience because it can expect typescript across the whole stack
neon creek
OTOH tRPC provides a much more seamless out-of-the-box experience because it _ca...
I generated types from a schema via openapi-typescript and can consume it in the frontend via openapi-fetch, but would I be correct to assume I now have no central authority for endpoint return types? Like, I would have my API schema saying one thing, and my endpoints actually returning another thing. With something like tRPC you don't have to do these middlemen actions and the return type is directly taken from the endpoint route handler, I believe.
lone plover
there's also https://ts-rest.com/ (which is similar to tRPC), and most likely other things in that space
lone plover
I generated types from a schema via openapi-typescript and can consume it in the...
i'm not super familiar with the openapi tooling but i would expect that you can generate server types from the schema too and use it to enforce that your server adheres to the contract
i've done that same thing with graphql codegen tooling before
but yeah, tRPC has no codegen step which is pretty nice
neon creek
i'm not super familiar with the openapi tooling but i would expect that you can ...
I could manually enforce endpoint returns to be of generated schema types but that's still 2 points of entry.
I hear a lot about GraphQL as well.
Thanks @lone plover.
lone plover
GraphQL is nice if you actually use the graph nature of it. the fact that clients can dynamically only request the properties they need can help keep things efficient and avoid the need to build out a zillion different endpoints. but unless you're going to leverage that it might be more trouble than it's worth if the only thing you're looking for is a way to define API contracts
neon creek
I guess it's wishful thinking tRPC has a GUI tool for testing endpoints?
There's a Swagger package for Express servers that generates a page using OpenAPI schemas.
neon creek
GraphQL is nice if you actually use the graph nature of it. the fact that client...
Hmm... My data is relational so I don't think I need GraphQL in that regard.
lone plover
you might. say you're building a social network and need to get a user's profile info plus the list of all of their friends in order to show their profile page. graphql lets you do that in one query without planning ahead and building a specific endpoint for that
it really depends though on how much the client needs to evolve independently of the server, etc
neon creek
I actually am building a social media app with users and they have friends and so on.
lone plover
lucky guess 😄
graphl is great in my experience if there are different teams with different management building services vs clients (you don't need to coordinate data contracts as much)
neon creek
It's a solo SaaS project so just me 😄
lone plover
ah, then yeah it might not be worth the overhead