Support Rest API?

[matannahmani]

Could be super cool if we can add support for Rest API, this can be game-changing as it eliminates the need for open API docs (internal usage)

[iway1]

that's a great point and something I've thought about before - in cases where a REST api is necessary you need trpc-openapi which has a lot of dev overhead. A solution that autogenerated an Rest API would could eliminate some of those cases, so devs could avoid those very expensive output schemas. (output schemas are crazyyyy expensive to maintain on larger codebases in my experience).

I don't think we could adhere to open api specs or anything (since we'd just be reinventing trpc-openapi at that point), but I think this is probably within the scope of this project (since the goal of this project more or less is to eliminate the need for the need to have to do output schemas and heavy amounts of required meta information).

Some things to consider with this (no need to respond to these unless you have opinions about them):

• Would it be OK with only POST and GET requests? It's possible to allow other methods as well it'd just require passing an additional meta property.
• Would we want to expand our documentation capabilities in some way to generate docs that read more like a rest API?
• Does this mean we'll need framework specific adapters? I'm thinking there's probably a way to avoid them but not 100% sure...
• Do we need to generate some sort of way to output a representation of the generated REST api? Is output documentation important (not sure it's possible btw)?

Any idea about any other specific requirements you'd need?

[matannahmani]

@iway1 First of all thanks for your fast response, overall what you wrote is in line with my thinking. Other than that

• I think working with only POST and GET requests is totally fine, it's similar to GraphQL's way.
• Expanding the docs is cool, but do we really need it at this point? (maybe something to do in the future)
• Hmm about the adapters, I think we can create a pure function that will act as a global connector (similar to TanStack ?)
• I think it's needed and maybe we can create a convention for it? eg:

  v1.queries.user.me --> GET v1/queries/user/me ?
  v1.mutations.user.profile --> POST v1/mutations/user/profile ?

  This seems to be enough for our use case but maybe other people have different needs. This can be a very powerful tool for sharing APIs between companies and teams

[iway1]

@matannahmani 🙏 good to know.

I'd agree with your convention, seems straight forward.

One question is handling inputs, I'd assume we'll need to do everything with query params if we want to keep it simple, would that work fine?

And if so, is a hard requirement to have each input property be its own query parameter (versus accepting a single object parameter with the whole input)?

[matannahmani]

@iway1 Good point, I think we can separate it on POST it will be on the body, and on GET it will be on query params. About whether we should separate it into properties or just shove it into one key, it's a bit of a hard take. I think it will be a bit more performant when you shove everything into one key, it will be a bit more complex for clients to reproduce. (because they have to use encodeURIComponent and JSON.stringify) Technically speaking if you look at URLSearchParams we can iterate and get all the keys, then reconstruct them into one object that will be passed down into the Zod. I'm down to create a middleware for express this weekend, that will process a request and then transform it into a TRPC request following the conventions we mentioned above.

One question I have is how should we handle errors (404 / or TRPC-defined ones)