brillout

6 ms·

31.
by brillout 4y ago
If Telefunc is bug-free (which I intend to be the case), then you won't need to debug Telefunc itself. For error tracking, Telefunc has hooks for that. For debugging user-land, you can `console.log()` just like you would with normal fu
32.
by brillout 4y ago
I still don't see a concrete use case that would justify using Zod in favor of `shield()`. Both "input cannot exceed 256 chars" and "number must be positive" are one-liners in JavaScript. I'm more than open t
33.
by brillout 4y ago
See my reply here https://news.ycombinator.com/item?id=33054110
34.
by brillout 4y ago
Yes, and that's why in Telefunc's world remote functions are called "telefunctions" to differentiate them from normal functions. Telefunc doesn't try to completely abstract away the network: as you say, it's no
35.
by brillout 4y ago
I think we will eventually see this: if you want to give third parties access to your data then use GraphQL. For any other use case use RPC. I.e. public access => GraphQL, internal access => RPC.
36.
by brillout 4y ago
Yes, depending on your stack, I can only recommend to roll-your-own. But for some stack it ain't that easy though. E.g. if you want TypeScript or SSR.
37.
by brillout 4y ago
Yes, and that's why in Telefunc's world remote functions are called "telefunctions" to differentiate them from normal functions.
38.
by brillout 4y ago
Back in the days it was wrong because we deployed frontend and backend separately and independently of each other. With stacks like Next.js, the frontend and backend are deployed in-sync. This makes RPC a match made in heaven. See https:&#
39.
by brillout 4y ago
This isn't it (I do remember the SOAP days), the reasons I believe RPC is making a comeback: https://news.ycombinator.com/item?id=33054029
40.
by brillout 4y ago
Yes, and that's why in Telefunc's world remote functions are called "telefunctions" to differentiate them from normal functions.
41.
by brillout 4y ago
It's quite a different use case with different constraints. It's out of Telefunc's scope.
42.
by brillout 4y ago
The frontend-side also throws an error. `throw Abort()` is about protecting telefunctions from third parties. It shouldn't be used to implement business logic (simply use `return` instead). Samen => Neat :-).
43.
by brillout 4y ago
This isn't it (I do remember the SOAP days), the reasons I believe RPC is making a comeback: https://news.ycombinator.com/item?id=33054029
44.
by brillout 4y ago
> The marketing rhetoric of telefunc activates my skepticism Why? (Author of Telefunc here.)
45.
by brillout 4y ago
Exactly. Telefunc is about replacing generic endpoints (RESTful/GraphQL APIs) with tailored endpoints (RPC). That's why the trade-off is simpler architecture (generic endpoints are often an unnecessary abstraction) VS decoupling (
46.
by brillout 4y ago
Author of Telefunc here. I'm glad folks are finally taking RPC seriously. RPC is back. Smarter, leaner, and stronger. (Sorry for the marketing jargon, but I really do believe that.) Telefunc is still fairly young, you can expect a lot
47.
by brillout 4y ago
I'm also the author https://vite-plugin-ssr.com/ , which I'd argue is rock-solid as testified by the companies sponsoring it.
48.
by brillout 4y ago
> doesn't make bogus and weird claims on its website Feel free to elaborate. I'm also the author of https://vite-plugin-ssr.com/ which indeed has no known bugs.
49.
by brillout 4y ago
gRPC is nice for backend-side RPC, but the ergonomics of Telefunc are much nicer if all you need is your frontend to access data.
50.
by brillout 4y ago
> Telefunc should support zod, why shouldn't it? What's your use case for wanting zod instead of https://telefunc.com/shield#all-types ?
51.
by brillout 4y ago
> How does this compare to https://trpc.io/ ? Less boierlplate. > so far, I'm preferring trpc, because it has support for zod What's your use case for wanting zod instead of https://telefunc.com&#
52.
by brillout 4y ago
I actually have plans to make Telefunc also have sensible defaults for network failure. So that the user doesn't have to take care of that (while the user can customize failure handling if he needs to).
53.
by brillout 4y ago
Without all that XML crap :grinning:
54.
by brillout 4y ago
Yea, I've seen a lot of folks doing this and it's neat. Most projects don't really need REST/GraphQL. So many waste so much time implementing a perfect GraphQL setup even though they don't need it :sweat_smile:. I d
55.
by brillout 4y ago
The reason RPC is making a comeback is because of 1. SSR (e.g. rendering React components to HTML on the server-side), and 2. the increased practice of continuous deployment. Increasingly, the frontend is deployed hand-in-hand with the ba
56.
by brillout 4y ago
Imagine a To-Do app, and you want to implement a new feature "mark all tasks as completed". With a RESTful API you do these requests: GET https://api.todo.com/task?completed=false POST https://a
57.
by brillout 4y ago
> My experience was that for the simplest use cases, the ergonomics were unbeatable. Exactly. > the “just a function” interface was a distraction and I found myself wishing for a more conventional RPC interface. For real-time use case
58.
by brillout 4y ago
If you use Node.js, check out Telefunc[1] which enables you to seamlessly call Node.js functions from the frontend (in other words RPC). Including first-class TypeScript support. Its guide "RPC vs GraphQL/REST"[2] explains yo
59.
by brillout 4y ago
HatTip [1] just added preliminary Bun support [2]. (HatTip: write universal server code that runs anywhere: Node.js, Edge, Deno, Bun, ... Also for library authors who want to provide a middleware that works anywhere, instead of locking thei
60.
by brillout 5y ago
The Filesystem Routing part is like less than 1% of the code; it wouldn't be worth it to externalize it in a separate library.

More ›