TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Telefunc: Remote Functions instead of API

156 点作者 denysonique超过 2 年前

37 条评论

Cushman超过 2 年前
Cool! Y’all, this is obviously an RPC interface, but the point is that `import { onNewTodo } from &#x27;.&#x2F;CreateTodo.telefunc.js&#x27;` is not, as written, an RPC. That transform, with seamless type support et cetera, is what makes this interesting. (If you think it’s interesting.)<p>I think it’s interesting; I experimented with a higher-magic version of this a couple of years ago. (It had continuations to support returning callbacks, could preserve object identity, and could lift inline anonymous functions to the server with some amount of intelligence.) My goal was to make the RPCs as close as possible to local async functions, which was really fun when it was working.<p>My experience was that for the simplest use cases, the ergonomics were unbeatable. Just drop a `@remote` tag into your TodoMVC frontend, and there’s your TodoMVC backend. But as soon as I had to look under the hood (for something as simple as caching behavior), the “just a function” interface was a distraction and I found myself wishing for a more conventional RPC interface.<p>(I think that might be why you tend to see this sort of magic more in the context of a full framework (such as Meteor), where all the typical use cases can be answered robustly. If you’re building your thing out of modules, cleverer abstractions usually mean more work overall to integrate everything and boring is better.)
评论 #33052587 未加载
评论 #33053784 未加载
评论 #33053568 未加载
评论 #33060389 未加载
评论 #33053677 未加载
chrsstrm超过 2 年前
I guess everything old is new again. Welcome JS devs to RPC.
评论 #33051398 未加载
评论 #33052517 未加载
评论 #33055892 未加载
评论 #33051418 未加载
评论 #33051580 未加载
评论 #33051519 未加载
hexo超过 2 年前
Don&#x27;t wanna break it for you - but calling even a remote function exactly is &quot;using an API&quot; (application programming interface).<p>I like the logo (or icon) they have, that masquerades it as some serious haskell (or some other functional PL) related project.<p>If it was this easy eveyone would be using RPC all over the place for many years already, and we&#x27;d have no HTTP and no train-load of other protocols.
评论 #33052123 未加载
评论 #33054029 未加载
ianbutler超过 2 年前
I think this is neat having looked at the examples but isn&#x27;t the title really just a game of semantics?<p>Non rigorously a web API is just the boundary across some service which you communicate with over (commonly) HTTP at the endpoints specified at that boundary by developers. I could write my own library that wraps those endpoints with functions that make the calls to them, in fact many libraries do just that.<p>What this takes care of, again kind of nicely, is dynamically and automatically generating that boiler plate as you write your API so you don&#x27;t have to put in the work, but I think saying this isn&#x27;t just a style of building an API is a little much.<p>Whether you&#x27;re doing RPC, REST or whatever the boundary between your service and another service is it&#x27;s API.
评论 #33052590 未加载
评论 #33054855 未加载
likeabbas超过 2 年前
Call me a geezer but we had a name for this back in the day<p>RPC - Remote Procedure Calls<p>I’m not even 30 btw
评论 #33054439 未加载
评论 #33051461 未加载
vyrotek超过 2 年前
Our latest projects are built with RPC-style APIs and a BFF approach. We generate the TS client with Swagger and you effectively get strongly typed remote method calls.<p>So basically, we&#x27;re at SOAP again. A few more years and maybe we&#x27;ll come back to Remoting?
评论 #33051724 未加载
hsn915超过 2 年前
That&#x27;s exactly how I program my APIs. The urls even look like &#x27;&#x2F;rpc&#x2F;FuncName&#x27;<p>The backend language I work with is Go, so there are &quot;two&quot; problems that need to be solved for this to work:<p>- Resolving function name and encoding&#x2F;decoding arguments from a url to a real function call<p>- Representing Go structs as Typescript interfaces for the client side code to look like regular function calls with regular types and all that.<p>For the second part, I have a writeup about how I&#x27;m doing it: <a href="https:&#x2F;&#x2F;hasen.surge.sh&#x2F;go-ts-type-bridge.html" rel="nofollow">https:&#x2F;&#x2F;hasen.surge.sh&#x2F;go-ts-type-bridge.html</a><p>It&#x27;s worth noting that the title of the OP website is wrong.<p>&quot;Remote Functions Instad of API&quot;<p>What do you think an API is? API does not stand for &quot;HTTP Requests with JSON&quot;. It stands for &quot;Application Programming Interface&quot;.
评论 #33054110 未加载
评论 #33052702 未加载
recroad超过 2 年前
Having lived through EJB 2.x, this is a hard pass. I don’t want to pretend the sever is local when it’s not.
评论 #33053051 未加载
vinay_ys超过 2 年前
Google has a system called plaque in which you can express DAGs of operators (functions) and it handles all the scheduling and data flow between nodes running on a distributed cluster. This achieves much better performance efficiency at large distributed scale while also providing an easy to reason and debug program logic. I would expect more such distributed computer programming models with dedicated language&#x2F;compiler toolchains in the future.
评论 #33054736 未加载
danbruc超过 2 年前
What exactly is the difference between an API and a remote function?
评论 #33053939 未加载
edfletcher_t137超过 2 年前
&quot;Rock-solid<p>The source code of Telefunc has no known bug&quot;<p>No known bugs does not &quot;rock-solid&quot; make. This claim alone makes this project very hard to take seriously.
评论 #33054189 未加载
spullara超过 2 年前
We should revisit this before RMI<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fallacies_of_distributed_computing" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fallacies_of_distributed_compu...</a>
seibelj超过 2 年前
This is pretty neat. You write a function and then a library automatically creates wrapper libs to be called in a browser as if it’s a function call. A variety of frameworks have done similar - SOAP auto-generated Java libs come to mind - but this looks very clean and minimal.
brillout超过 2 年前
Author of Telefunc here. I&#x27;m glad folks are finally taking RPC seriously.<p>RPC is back. Smarter, leaner, and stronger. (Sorry for the marketing jargon, but I really do believe that.)<p>Telefunc is still fairly young, you can expect a lot of polishing in the coming weeks&#x2F;months. The high-level design is solid and I expect no breaking change on that end.<p>If you encounter any bug (or DX paper cut), please create a GitHub Issue and I&#x27;ll fix it. I&#x27;m also the author of <a href="https:&#x2F;&#x2F;vite-plugin-ssr.com" rel="nofollow">https:&#x2F;&#x2F;vite-plugin-ssr.com</a> which also has no known bug, so I do take that claim seriously.<p>Let me know if you have any questions!
dharmaturtle超过 2 年前
How does this compare to <a href="https:&#x2F;&#x2F;trpc.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trpc.io&#x2F;</a> ?<p>Edit: so far, I&#x27;m preferring trpc, because it has support for zod and a few other libraries <a href="https:&#x2F;&#x2F;trpc.io&#x2F;docs&#x2F;v9&#x2F;router" rel="nofollow">https:&#x2F;&#x2F;trpc.io&#x2F;docs&#x2F;v9&#x2F;router</a><p>It seems like this library has its own bespoke syntax for types <a href="https:&#x2F;&#x2F;telefunc.com&#x2F;typescript" rel="nofollow">https:&#x2F;&#x2F;telefunc.com&#x2F;typescript</a>
评论 #33054160 未加载
评论 #33052631 未加载
quechimba超过 2 年前
Nice, I do something similar in a web framework I&#x27;ve been working on. All rendering happen on the server so the callbacks has to run there too. The onclick-handler in the DOM will trigger a POST to the server with an unique callback id.<p><pre><code> def self.get_initial_state(initial_count: 0, **) { count: initial_count } end def handle_decrement(_) update do |state| { count: [0, state[:count] - 1].max } end end def handle_increment(_) update do |state| { count: state[:count] + 1 } end end def render &lt;div class={styles.counter}&gt; &lt;button on-click={handler(:handle_decrement)} disabled={state[:count].zero?}&gt; - &lt;&#x2F;button&gt; &lt;span&gt;{state[:count]}&lt;&#x2F;span&gt; &lt;button on-click={handler(:handle_increment)}&gt; + &lt;&#x2F;button&gt; &lt;&#x2F;div&gt; end</code></pre>
diceduckmonk超过 2 年前
Really odd how there is a dozen comments on RPC but no one mentioned gRPC for the web browser. Google goes in the reverse, where from both protobuf you autogenerate API boilerplate, client stubs and even REST-over-HTTP apis.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;grpc&#x2F;grpc-web" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;grpc&#x2F;grpc-web</a>
评论 #33054169 未加载
kamilafsar超过 2 年前
Whoa, that’s so similar to our project [1] it’s almost scary :)<p>How are errors handled though? What happens when you “throw Abort()”.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;samen-io&#x2F;samen" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;samen-io&#x2F;samen</a>
评论 #33054597 未加载
tbrownaw超过 2 年前
The first rule of network transparency is : <i>the network is not transparent</i>.
评论 #33054661 未加载
_sohan超过 2 年前
This reminds me of the ScriptMethod thing that asp.net has in the early days of AJAX. Was fun to use it, but didn’t stand the test of time. <a href="https:&#x2F;&#x2F;learn.microsoft.com&#x2F;en-us&#x2F;aspnet&#x2F;web-forms&#x2F;overview&#x2F;older-versions-getting-started&#x2F;aspnet-ajax&#x2F;understanding-asp-net-ajax-web-services?source=recommendations" rel="nofollow">https:&#x2F;&#x2F;learn.microsoft.com&#x2F;en-us&#x2F;aspnet&#x2F;web-forms&#x2F;overview&#x2F;...</a><p>Maybe there has been enough changes in the ecosystem now to be able to abstract network and write code that’s not too brittle.
评论 #33054134 未加载
评论 #33054124 未加载
crummy超过 2 年前
We have a hand-rolled solution that does this and it&#x27;s easily my favourite part of our codebase. Ours is with a Java backend so a bit more complicated but not much.<p>If you have a tightly coupled frontend and backend and no need for third party consumers of your API, I highly recommend it. Makes moving between frontend and backend such a pleasant experience with a well typed and defined interface.
asim超过 2 年前
The thing about people with experience, we love to tell you about the past. The cycles are all the same, technology A is created, it has some level of success, then something else (B) is adopted. A new generation of developers have only experienced B and due to its shortcomings reinvent A as C. And the cycle repeats over and over.
评论 #33054502 未加载
majestic5762超过 2 年前
The DX is really cool, but I remembered protobuf exists <a href="https:&#x2F;&#x2F;buf.build&#x2F;blog&#x2F;connect-web-protobuf-grpc-in-the-browser" rel="nofollow">https:&#x2F;&#x2F;buf.build&#x2F;blog&#x2F;connect-web-protobuf-grpc-in-the-brow...</a><p>The marketing rhetoric of telefunc activates my skepticism, but I hope it&#x27;s just me
评论 #33054491 未加载
0xCAP超过 2 年前
Trying to make me feel old by acting like you&#x27;re too young to remember about RPC?
评论 #33054666 未加载
77pt77超过 2 年前
Great!<p>SOAP, RPC and CORBA.<p>Here we go again.
评论 #33051703 未加载
评论 #33051729 未加载
andkenneth超过 2 年前
I&#x27;d much sooner recommend tRPC, which is much more mature and doesn&#x27;t make bogus and weird claims on its website.
评论 #33054183 未加载
bluelightning2k超过 2 年前
This seems like a very nicely done implementation.<p>One negative: I don&#x27;t think people realize how easy it will be to inadvertently include server side files in client side bundles.<p>The technical approach mitigates this and is well designed. But simply by blurring the lines it might result in sever side config bundled to the client.<p>(Easy to mitigate, just add a line to server side stuff which and destructs if it detects wrong environment)
tanelpoder超过 2 年前
So now we’ll have another layer of an RPC API that under the hood calls the already existing REST API?
maskaler超过 2 年前
SOAP for browser is finally here.
评论 #33054117 未加载
dboreham超过 2 年前
Wrong the first time. Still wrong.
评论 #33051492 未加载
评论 #33054680 未加载
tobr超过 2 年前
Could this be used to communicate between the main thread and a worker too?
评论 #33054644 未加载
rilut超过 2 年前
I love this, so convenient. Any plans for python server?
zemnmez超过 2 年前
if you can query the DB directly from the frontend, what’s the security model? what prevents me from pulling sensitive data, passwords etc?
评论 #33053223 未加载
leetrout超过 2 年前
Are we also back to writing JS without semicolons?
revskill超过 2 年前
It&#x27;s like React 18 server component :D
ochronus超过 2 年前
RPC is cool again! CORBA FTW ;)
Kalanos超过 2 年前
i wish python worked like this w pickle
评论 #33051413 未加载
评论 #33051889 未加载