search

brillout / telefunc

Remote Functions. Instead of API.
https://telefunc.com
MIT License
690 stars 31 forks source link

Comparison with tRPC #9

Closed astahmer closed 2 years ago

astahmer commented 2 years ago

hey, just stumbled on this repo and this looks great, just curious on what differs from trpc ? couldn't find anything in the doc site and this looks close feature-wise

brillout commented 2 years ago

Telefunc advantages:

tRPC advantages:

And, actually, the most important differences are going to be the different decisions both projects will take in the future.

RPC will play a crucial role in web development and the more RPC implementations there are the better; the ecosystem at large will come to realize how RPC is a big part of the future.

brillout commented 2 years ago

Closing, hope this shed some light.

KATT commented 2 years ago

Heya! Creator of tRPC here. Excited that there are more projects popping up in this space! I will have a proper play with telefunc someday soon and get back properly - only skimmed the docs so far and got this issue linked to me.

Got some questions on your points here below.

  • Drastically simpler design (no routing, no middlewares, no query/mutation distinction, no batching, no error formating, no data transformers, etc.).

Could you expand on why these are good things?

[..] The idea is here is that you think in terms of functions instead of thinking in terms of RPC endpoints.

If you don't have data transformers, you can't really properly think about things as functions as you won't be able to return things like Date/Map/Sets and just use them.

  • Inversion of Control. This is an important shift in thinking leading to a fundamentally improved separation of concerns.

I don't think I follow this - what is the difference in inversion of control here? In tRPC we also have a context object which is passed into all resolvers.

  • TypeScript just works. No need to do anything for full TypeScript support.

What do you mean you need to do with tRPC that you don't need to in telefunc?

  • Custom arguments type saftey (shield()) instead of using zod (zod is nice but 90% of it unnecessary in the context of RPC).

In tRPC you can do this as well.

  • Simpler React integration. (No React Query nor any Telefunc React component. It uses Async Hooks under the hood which makes using Telefunc super easy in the context of SSR.)

Do you provide any hooks to easily fetch the data? In the next example, I see the following which seems quite verbose? Easy-to-use hooks are essential for a good DX.

https://github.com/vikejs/telefunc/blob/25e01c7942d50efa002cc1a498b501c64217e7c0/examples/next/pages/index.tsx#L7-L20

  • Support for other UI frameworks: Vue, Angular, etc.

@trpc/server + @trpc/client are completely framework agnostic as well. In what way is telefunc different in this regard?

  • Support for other ecosystems such as Vite

What do you mean here? tRPC should work fine with Vite afaik as it doesn't require any compilation.

  • Support for edge computing such as Cloudfare Workers (which will play a crucial role in the upcoming RPC "revolution").

Possible with tRPC as well, I saw someone doing a repo of this the other day.

Also Telefunc's vision is fundamentally different than tRPC's one. Telefunc is ambitious.

My goals with tRPC are quite ambitious as well and it already does a looot whilst being quite composable, so why you're insinuating that tRPC is unambitious 😅

That said, tRPC has support for bi-directional communication which is not a priority for Telefunc for now. With Telefunc you have to use a separate tool for bi-directional communication. Other than that I'm not aware of any tRPC advantage over Telefunc but I'm happy to be shown wrong.

You already mentioned a few advantages with tRPC: "no routing, no middlewares, no query/mutation distinction, no batching, no error formating, no data transformers". I could add to that list, but I'm not here for that.

I'm excited to try Telefunc out!

brillout commented 2 years ago

Updated the list, I hope it's more accurate now.

Possible with tRPC as well, I saw someone doing a repo of this the other day.

Mind sharing? The main problem here is that Next.js doesn't support Cloudflare Workers.

Do you provide any hooks to easily fetch the data

Yes it's work in progress. It's actually the only piece missing for Telefunc's release.

You already mentioned a few advantages with tRPC: "no routing, no middlewares, no query/mutation distinction, no batching, no error formating, no data transformers". I could add to that list, but I'm not here for that.

No please do. I'm not adding these to tRPC advantages because I think these are design flaws and not features. Happy to be shown wrong though.

KATT commented 2 years ago

Updated the list, I hope it's more accurate now.

You didn't address most of my points & your list is still lacking a bit of nuance. Would you mind going through my points again and respond with your thoughts on each?

On my phone now, will respond with why all of those things you consider flaws are actually benefits.

redbar0n commented 2 years ago

@brillout would be interesting with an update here adressing @KATT’s points.

brillout commented 2 years ago

What points specifically? IIRC https://telefunc.com/tour#inversion-of-control and my replies here covers everything.

ivan-kleshnin commented 1 year ago

https://telefunc.com/tour#inversion-of-control

👆404 on that URL.

As my 5¢ input. I'm personally using Zodios. Would be nice to see a comparison table with Telefunc, Zodios and TRPC. I'm not convinced why I should choose Telefunc over Zodios becase the latter operates with Zod schemas that are reusable and give me TS types for free! Super convenient. With Telefunc it's another DSL only to validate APIs: less benefits for the same code "price".

brillout commented 1 year ago

👆404 on that URL.

Yea, I removed that. I may re-add this section somewhere in the docs (some users like these kind of theoretical explanation).

why I should choose Telefunc

Because it's fundamentally simpler.

With Telefunc it's another DSL

It isn't because the goal of shield() is to be internal (it's automatically generated). I may remove the docs for shield() to make it clear that it's something you'll ideally/almost never use.

ivan-kleshnin commented 1 year ago

Thank you, I'll have to give it another look then 👍

kirankunigiri commented 4 months ago

This is quite an old post, but thought I'd leave my thoughts here for anyone else who's comparing trpc with telefunc. I use trpc for most of my projects, and just saw telefunc and thought it was really interesting. Reminded me of next.js server actions, being able to write server code directly in the frontend code. This was what made telefunc most interesting to me.

However, my biggest use case for trpc so far has been the integration with react query. Having all my server functions automatically wrapped with react-query hooks for queries & mutations is extremely useful (I usually work on more dynamic fully client-side rendered projects, so react-query is especially useful for me). This also means I can invalidate queries after mutations happen to update the UI, and I don't even need to worry about managing query keys since I can directly call the invalidation function using their react query utils.

Overall, I'd say it boils down to your use case. I initially was excited about the possibility of using telefunc until I realized that it doesn't work well with client-side projects that heavily utilize react-query to manage data loading. trpc is perfect for this use case, and with specific frameworks like Next.js (which already have server actions) you may not even need something like this. But overall, these libraries cover different use cases and you need to see what will work best for your project.

brillout commented 4 months ago

@kirankunigiri Neat comparison, thank you! FYI Vike users can use Telefunc with vike-react-query, although it would be better to have a TanStack Query integration that works across frameworks.