Hacker News Reader

Comment by dboreham | Hacker News Reader

Wrong the first time. Still wrong.

Why?

The way people abuse HTTP JSON API design these days I figure it would just cut out a lot of the cruft. Maybe it's not the best way to do some things, but it might be a lot simpler...

Well that is until someone writes a recursive function (or just a loop) which calls out to an RPC without consideration. But that's nothing new either....

How is `fetch(base + '/myFn')` all that different than just calling `rpc::myFn`?

Indeed.

So much code is an internal client function "GetUser(5)" configured to hit a specific URL "/users/5" and the server accepts requests on "/users/5" just to end up invoking a handler called "GetUser(5)".

Definitely a fan of completely skipping the URL "REST" ceremony.

Eventually you'll reinvent SOAP and be in for a world of pain and suffering with slightly incompatible or overly complex tooling.

And here I am, enjoying JSON-RPC services since 2005, having none of the SOAP or ReST problems.

I will admit that RPC does feel more natural for many applications. In the old days, I worked on an app that used XML-RPC and it was fine. If you can avoid the complex tooling and it works for you / your team, great!

It's true however, RPC in it's simplicity loses a lot of the niceties of HTTP and REST. You have no conventions to go off of for state control, no standard for error handling, etc.

Maybe you want something more barebones, maybe you want to leverage existing protocols. These days, it's kinda the wild west out there in terms of web standards it seems, so go nuts I guess.

Only if you have a screw in the wrong place.

We program things to make our jobs easier. If it looks like a call, takes args like a call and returns values like a call, it probably is a call. If you have nothing against a call, you have nothing against RPC. Give me TCP, SMTP-over-SOAP-over-HTTP, XML-over-PigeonPost, whatever. I’ll hide this nonsense in an rpc.<langname> file and turn it into a call, because calls are my main programming instrument. Everything else is just an annoying noise that either takes a page to perform or gets wrapped into the exact same parametrized call.

As always, the devil is in the details. SOAP didn't get complicated for absolutely no reason. As your application grows, you'll need to think about error / exception handling, backwards compatibility (new parameters), and versioning, to start.

These nuances are not unique to a protocol. The fact that some prior tech wasn’t smart enough to think about these doesn’t mean that someone will inevitably repeat it. “SOAP” is like an elevator anxiety trigger because one of them failed brutally in the past.

As you application grows

No, you have to design it in from the beginning. How can someone not think of exception borders, API contracts, safety/idempotency and versioning even for a single call?

I see that errors are handled well by telefunc. Other issues are easy to do in the same way you do it in REST/POST, i.e. foo(…, new_arg), foo_v2(…), plus some docs. It is literally just a different form with the same content, which is closer to the language and doesn’t require pages of almost identical parametrized wrappers.

You’d be surprised how often people fail to consider things like versioning when building APIs. Yes, they absolutely should be considered from the beginning.

I’ve been burned in the past by RPC (mainly SOAP), but will take a deeper look and try to keep an open mind. Building “REST” APIs is damn tedious.

The badness tends to not start in your example - which is the most trivial example of an RPC - but when you don't know / care if a function is really a stub for some kind of remote invocation. Before you know it you're knee deep in a sea of distributed systems problems where instead of a clean separation between client and server, half your client is on the local machine, the other half is on a remote machine, and the state is also weirdly split. Of course, you can replicate the same mistakes with a REST API, but at least that's by definition more explicit about state transfer etc.

The thinking around a similar (but more mature) project, tRPC is interesting around this. They're very clear about the fact that it's designed for tightly coupled typescript web app monorepos. I believe the creator even was talking about the name not being ideal, but it might be too late to change.

Aside from maybe being able to generate an OpenAPI spec (something that the tRPC community is working on), it's just going to fall apart outside of web apps.

But for those developers it's great for eliminating this weird step where we need to think about all our data going into a completely unstructured string (json) when going between our server and client. For most full stack JS/TS apps that's all you need.

Any examples of that half state in client and other half in server?

Reeally clueless about this stuff as a newbie dev, first time hearing that

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://news.ycombinator.com/item?id=33054005.

Reply on news.ycombinator.com