This is really good, I really enjoy the way you expose content. I noticed you stopped posting videos. If possible would be amazing if you could do some more of these, explaining the different points on design system like this one. Thanks for the content, cheers!
It's a good insight and question! In a new project, if you are leveraging Next.js or similar tooling to have server actions, you can easily share types in the same repo without tRPC. However, GraphQL still could have a place, because server actions that return data are tightly coupled to the frontend caller. By defining a GraphQL API, you only have to define it once and then the caller can create dynamic queries. Write once, retrieve many. You might also want REST, tRPC, or GraphQL if you have multiple services or callers even if your frontend can leverage server actions; it may not be your only 'user' of the data For a small self run project, you can use server actions exclusively. As complexity, number of developers, number of services/callers increases, and use cases change, these traditional API methods are still very much necessary today
![[Frontend System Design] Client-Server API. Part 1 | REST](/img/n.gif)
This is really good, I really enjoy the way you expose content.
I noticed you stopped posting videos. If possible would be amazing if you could do some more of these, explaining the different points on design system like this one.
Thanks for the content, cheers!
thanks for all details
Can we say that both GraphQL and tRPC are not necessary anymore because now we have react server actions?
It's a good insight and question!
In a new project, if you are leveraging Next.js or similar tooling to have server actions, you can easily share types in the same repo without tRPC. However, GraphQL still could have a place, because server actions that return data are tightly coupled to the frontend caller. By defining a GraphQL API, you only have to define it once and then the caller can create dynamic queries. Write once, retrieve many. You might also want REST, tRPC, or GraphQL if you have multiple services or callers even if your frontend can leverage server actions; it may not be your only 'user' of the data
For a small self run project, you can use server actions exclusively. As complexity, number of developers, number of services/callers increases, and use cases change, these traditional API methods are still very much necessary today