[FEAT] TS-Rest Data Provider

[mjbergman92]

Is your feature request related to a problem? Please describe.

Type-safety between API and refinedev application must be meticulously managed.

Complex and opinionated options do exist (e.g. GraphQL), and any solution will have some amount of overhead, but the overhead just seems like too much for small teams. I believe refinedev has and will continue to focus on the DX while quickly building functional and user-friendly applications. The DX when it comes to managing a contract for queries and mutations between the refinedev application and the API has been one of the most challenging parts of building my current application. I spend an estimated 20% of my time just in reconciling inconsistencies between what the API offers and what the refinedev application should offer to end users.

Describe alternatives you've considered

GraphQL - While there are differing opinions amount how it compares with other options, there are tools to generate types for the quereies and mutations. The draw backs here lies in the complexity of developing a GraphQL API, which varies from developer to developer.

tRPC - Closest to what I am hoping to get. It is another viable option

I know REST, and it provides what I need, and I don't intend on moving away from it until the DX for another option becomes simpler with the same capabilities.

Additional context

No response

Describe the thing to improve

Disclaimer: I have not used ts-rest yet. While ts-rest claims to be production ready, it has only been around for about 2 years from my research.

ts-rest offers type safety without the need for code generation.

I am looking at developing my own data provider for ts-rest.

Here is my biggest reason. The "contract" is defined where the data is coming from, i.e. the API.
The contract is written in typescript, which allows for the use of zod schemas to define the contract.

As long as a standard structure for a ts-rest API can be defined such that the endpoints can be accessed by resource and the specific query or mutation (e.g. list, one, create, etc.), the DX looks promising.

What are the thoughts from other refinedev community members on this subject? I am not aware if this has or has not been brought up yet.

Key Benefits

• Form validation schema consistent between frontend and backend

[BatuhanW]

Hey @mjbergman92 thanks for the detailed issue. We are currently focusing on August release. We'll check it and get back to you.

[mjbergman92]

In the meantime, I will probably be developing something myself.

This could be a really fantastic way to streamline the stack.Id even go as far as saying a half-baked but fully customizable express backend to go along with the type-safe front end fetch or query client provider would be nice for me at least.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[moltar]

@mjbergman92 Have you made any progress? I am interested in this too.

[mjbergman92]

@moltar I made a slight attempt, but I decided to move away from refine because I didn't need refine after using ts rest for my current use case.