tRPC name change?

[KATT]

Update: The name I'm proposing here is zapi (Zero-API). I have @zapi/*-namespace on npm + zapi-package + @zapijs/* on github and own the name zapijs.com

---

I have been pondering this for a long over the name... I've heard people say or try to spell "trcp"/"tprc"/etc.. also heard people mixing it up with gRPC, which is a quite different project..

Many people don't really know what RPC is.. it's kinda old tech that is getting a revival. I personally like the name tRPC & maybe this is an adoption curve thing, but I think the name of RPC is too technical and I feel how I've worded everything around tRPC I think it's a bit of a walled garden to adopt it, beginners in JS-land might be scared to pick up this tool, even if it's the best tool they could possibly use.

The thing is, tRPC is one of the fastest ways there is to build & use APIs in general. With one tool you can have most of the tools you need to quickly and safely build out a backend and the tools to build the client in a rapid way. Very few other Node-based server tools provide runtime input validation as a first-class citizen (which I've never understood why).

Long-term, I don't care if tRPC stays true to "RPC", although I think doing is the best for the DX. But I will focus on what is best for DX - with DX being is a wider concept than what you see today:

• .. encompass building OpenAPI-compliant APIs with tRPC as a backbone.
• .. automatically generate SDKs for other languages
• .. solutions for how you easily [edge] cache procedure's data
• .. might be able to chain procedures in one request in order to avoid query waterfalls
• [..]

Short-term, when releasing this initial version, I want to have a smooth migration path. With this suggestion, it'll be easy to install the new package(s) in parallel and do a migration incrementally.

I have a name in mind already, with a [name]js.com & @[name]/*-org on npm already. If y'all like that is a separate discussion, but want to bring up the idea of even changing the name first.

[esamattis]

I don't have too strong opinions on this but here's one point to consider: As someone familiar with other RPC tools "tRPC" name makes it crystal clear what this library is about. No need to read anything else about it.

[BrockHerion]

I generally love the focus on DX. tRPC lets me build a completely robust backend very quickly. I love not having to build and manage a completely separate API for a project.

With that said, I'm not as familiar with RPC in general. To me, I think a name change could help more people adopt tRPC in their own projects. It took me a little bit to adopt it into my own workflow simply because I spend most of my time in REST-land and wasn't really sure what kind of tool it was or how far it would take me. Once I started using it, I knew it was the right choice, but getting to that point took me a little bit of time.

[mmkal]

My two cents - I like the name! It's a hint that it's RPC-related, and even for folks not familiar with RPC, being only four letters makes it easy to write and talk about (and remember that trpc.io is the docs website, and that github.com/trpc/trpc is the repo, etc.)

[mgreenw]

I like the name tRPC and think that changing the name at this point could lead to confusion among new adopters. Even if the dx changes / methods evolve, I don't see the rpc nature of the library changing so drastically that it wouldn't make sense to have it in the name.

[KATT]

Votes seem to go against it. Might consider in future