RPC in JavaScript!

key. Welcome to Syntax, the podcast with the tastiest web development treats out there. Today, we've got a show for you on RPC. PC.

What does that mean? The word that has been around for probably forever in computing, but it seems to have gained quite a bit of popularity in the JavaScript world, especially as we're starting to get more into server side rendering our JavaScript app. So we thought, Let's try to explain it, for you from the context of a JavaScript developer.

My name is Wes Bos. With me as always is mister Talinsky. How are you doing today, Scott? Oh, hey. Hey. Hey. I'm doing okay.

I, I I'm on antibiotics again for, like, the 2nd time this suit in the last 30 days. I I I just, like, cannot get healthy. I I have no idea what's going on with me right now. So, I got an ear infection. When was the last time you got an ear infection?

Oh, man.

I used to get them all the time as a kid, and I had tubes put in my ears.

Oh, wow. Which,

our kids get them quite a bit. So I'm wondering if if they're gonna go down the same route. But, yeah, they just like little plastic tubes in your ears and they help drain all the disgusting stuff out.

Yeah. I know. I like I never had our kids don't get them. I never really had one. So I don't even know when the last time I had one was. So, like, All of a sudden to be like, oh, you have an ear infection. I was like, what? What's going on? Yeah. So, that that's the status of my life right now. But, Hey, other than that, doing good. Awesome. Well, let's get on into it. RPC

means remote procedural call.

Essentially what it is, is when you are on a let's use client server as an example. RPC can obviously be used with anything.

It can be done from your phone to a robot.

It can be done from a controller to a drone. It can be done from like, literally one thing to another. And generally, there is something that is less powerful, like the browser, and something that is more powerful or something that is actually running, your logic, like the server, and you want to call a function from the client and have it run on the server.

And that's what an RPC actually is, is you are calling a function or you're running some code Remotely, and then as if it were being done on the actual client. Yeah.

And to to be clear here because this is something that I think will confuse some people considering we have a lot of technologies to talk from client server. Right? And, they they all kind of get mushed together in a way conceptually.

But the big thing about our PC is that it's a concept or design pattern. It's not a spec specifically.

There are different specs, for our PC, but our PC itself is not a spec. It's a concept.

And so Unlike GraphQL, GraphQL is a spec. GraphQL is here's how to do it, and then people implement that spec in whatever library. But RPC is more just like, here's a general concept.

Here's how this thing works.

Not a specific technology itself. It's not RPC.

Js that is all RPC or anything like that. It is not a specific technology, not a spec, just a concept, right?

Yes.

It's funny because you wrote it's not a spec, and then I wrote it is a spec. And we're both right here. And Scott said it is that RPC itself is more of an idea. And then there are several, as specifications go, there are several standards out there.

There's gRPC, there's JSON RPC, there's an XML based one out there. Soap? Soap was a RPC. I didn't even know that. Interesting. Yeah, it's XML based RPC.

Oh, man. I had unfortunately used a handful of soap APIs in my day, which is never fun actually use it returns XML to you, which is brutal to work with. But yeah, there's lots of different standards out there. And generally, when you're working with an API, they'll say, alright, this is a gRPC API or this is a JSON RPC API. So a you have a point here. It's just why are we talking about our PC? Like, why now?

Our PC is a concept has been around for a long time. And just like the pendulum of a lot of things that come back around, our PC as a concept is something that people are now talking a lot more about now that we have, like, server components inside of React. And it does feel like React is a bit of a tastemaker here in terms of, introducing some of these concepts to people that they might not have come across before. You know, a lot of developers picked up React is their 1st introduction to, you know, web programming in general.

So now that server components are here, or coming, whatever, you know, the idea of our PC, this, connection essentially between your clients and server as it is, Is becoming a little bit more in vogue or in the the the mind's eye of the entire development community now. Exactly. And it's worth saying that there is nothing in React

for RPC just yet.

However, there's talk of it. There's people building stuff on top of server components for it.

Generally, the idea is that as you write these server components, sometimes you might not even need an API. You might need a REST API or GraphQL API or something like that.

The idea is that you could just pull data inside of your components. However you like, you can write SQL query right inside of your server component.

And then if you wanted, you can expose things like refresh, refresh, mutations, all of that kind of thing, and you could expose those directly to the client. So you could have a button that says on click And it would just say display items and that would remotely procedurally call that function on the server and then bring your data

back to you. Yeah. Which is funny for me coming from a meteor background.

You know, meteor was an RPC.

It it was DDP. It was similar concept, though. So for me, this concept has always felt very fine, like, to to do these types of things. Right? It it all just feels very normal to me. But, again, like I said, with the pendulum coming back around, it's like, Okay.

Now other people are starting to feel the vibe for why these things actually might feel good sometimes to use. Yeah. Another popular one is

in electron where electron works is that you have your your application, right? And then you have your your your like node process that was running and you can send stuff across from the client to the server via RPC. And then even, what's the one that we talked about that's like a Electron killer built in Rust?

Tory.

Tori has an even better implementation of that where you can just surface your functions to the client and it works really, really well in that you just You just call them. You can call file.

Save or any of the APIs that you are thinking of from the client, which at first feels a little bit weird because you're like, I can call all these like restricted API methods from the client Hey, don't have to like send a request to the server and then the server has to accept that request and then translate it to whatever I want. I can literally just call like I know, Meteor allowed you just to straightaway call like database queries from the client, which is wild. But once you sort of understand it. Oh, this is actually kind of nice. I don't have to hopscotch my way from the client to the server and then translate that every single time I want.

I could just call directly the functions that I've written on my server from the client.

Yeah. And it does, again, bring us back 2 almost PHP style things where you're not even though we weren't working on the client, then you're just working on the server. So it's not the same.

But you you get some of the same concepts of being able to access server side functionality directly within whatever is your UI code. But now we're going to do it in a slash client and server basis, which honestly, if we'll talk a little bit about some of these considerations here in just a minute, but, like, I there's many times when I really like that approach.

Me, personally, I I don't necessarily see that blending of client and server as being too much of an issue conceptually, how I think about the way my application works. Because at the end of the day, you're just trying to call some sort of a function. You're just trying to manipulate some data somewhere, the database, whatever. And you're not necessarily thinking, oh, I have a client that needs to send a message to the like, Those are the details that honestly don't matter as much as I have an interface, and I would like this interface to manipulate some data on the back end. And that's That's typically the reason why I tend to like our PC myself. Exactly. Solid JS. We had Ryan on the podcast Monday. They are introducing

a server function, which is basically you just call server dollar and you pass it a function. You pass it all your local arguments and that will all get sent to the server.

We had the folks from Quik on as well. Quik City has a router loader, which is kind of similar to the thing we're talking about with React, where you can run this function and pass it another function, and then it will fetch all the data that you're you're looking for on the server.

So there's a lot of talk about it recently, and I don't know if it's necessarily just like hype, which is it's kind of funny because like, again, this stuff has been around for 20, 30 years, Right? Yeah, but there seems to be a lot of hype around it because of this new everything runs on the server by default

in JavaScript. And I'll tell you why. There's hype around it. There's hype around it because anytime React does anything, even things that have existed for a long time, people act like it's a a big deal. Yeah. Yeah. Well, every act invented this thing or yeah. Who knows?

So other questions. Isn't this just rest? Like, What you're describing is just a REST endpoint.

And yes, most of the functionality does overlap with REST. REST is more of something for like stateful documents where you send a request. It's generally over HTTP or it's always over HAB because REST is a URL endpoint.

And it's generally based on your HTTP get, put, delete methods.

And then RPC can be sent over any protocol. So there are packages out there for working with RPC in WebSockets.

Electron sends it over some, I forgot what it's called, some sort of bus.

You might be sending RPC calls over.

Radio waves. If you're thinking about controlling a drone, right? Like it's a little like a sort of a step lower in that the RPC can be sent via any protocol and any method

that is available to you that goes directly along with the fact that it is just like a concept, right? It's not the implementation of the thing. Right? So I I think yeah. And and rest is is like you mentioned, it is closely connected to those HTTP methods where our PC is more or less not connected at all directly to those as a concept. Yeah. Like, I

Go back to my YouTube. I have a video on controlling a drone with JavaScript.

And There's no there's no URL to ping on the drone, right? There is a socket connection. I think it's a socket connection.

And through that you can just send, RPC commands and it's the format is a little bit funky. It like requires you to put the command right up front. And then I think there's like a space or an equal sign. And then any arguments that you want to come along are sent over that. And then It will send back to you as a response from that. It will send back to you the actual data. So you could say like battery and then any percentages that you want, and then it will return to you the the result of that, just like any normal function would. But in my case, it was being sent over a socket, which was wireless. Right? Mhmm.

Yeah. That's interesting.

Yeah.

I have not dove into any of that world, so it's it's so fascinating for me to hear any of that.

What about considerations here? And, I think one consideration, some things that might freak some people out would be the tight coupling between your server and your client. Right? Because if you if your server is that tightly integrated with your client, you might be wondering, like, well, how do I have multiple clients then. With something like GraphQL or even just a REST API, you have your server, and that server Can accept incoming messages, via that API and handle those accordingly, which is largely why things like GraphQL exist. Right? So that you could have all these different new eyes and all these different clients interfacing with the server.

And because of that, the the coupling of the 2 of those so tightly could make that a a I don't I don't even know. Like, what is the what is the way of doing our PC with multiple different front end. I don't even know. What do you mean multiple front? Like, if you had a client with if you had a mobile app and a web app and you had a, Yeah, third party third party access to your API. There's there's really not a lot of solutions there. No, I would just like Can't a server accept multiple connections

from different clients out there? Like if you it's like it's like a WebSocket. If you had a, Let's say you're sending the RPC calls over a WebSocket.

Can't you can make multiple WebSocket connections to your server and the server can Respond accordingly to each of those. I don't think that's an issue because, like, what about, like,

third party access to your API, like, opening up your server to interrupt from other people. There's always like an authentication

level on it. You just have to figure out how is the authentication being sent over right? Is it is it is it username password? Is it a token based? I don't think any of the authentication stuff Will change, especially because RPC is not just HTTP, right? Like it could be a header if you are doing it over HTTP, but it could also where you need to do like a handshake and get a token first before you send it along. I'm pretty sure with the drone one, I had to send along a Oh, no, no. With the drone one, I had to connect to the Wi Fi network. So that was the security level at that point, right? So as many people that were connected to the Wi Fi network of that drone could send and receive signals to the drone.

Okay. Well, in addition though, the the tight coupling could be seen as a pro in the considerations because You can get access to,

like, better ease of use code gen. Yeah. It feels like TypeScript would be easier that way. Yeah. Like like, t r p c is an example. Right? You wanna talk about that?

Yeah. Yeah. T r p c is well, t r p c is interesting because go back and listen to the the whole show we did on on t r PC itself, for more information. But t r PC really kind of blurs that line between rest and, our PC where Essentially, it feels like you're just calling methods and doing our PC, but it isn't traditional our PC.

It just feels like our PC, right, where, I believe it's it's just over rest APIs. It's just this layer that that sits in between your API that Makes that connection feel like it's tightly coupled, even though it is just a layer in front of it. Yeah, and

what tRPC is sending is just I'm assuming it's a like a JSON string of the function as well as any arguments. That's how most of these t r p c's I'm just looking at I should I listen to it that I'm kind of bummed that that's the only syntax I've ever missed.

I did listen to it, but it should have,

wish I would have been on that that call. Yeah, that that episode was great because I had a lot of assumptions in my brain about what t r p c was. And it was so good to get that pulled out, say, no. It's more of this and it's more of this. And these are the oh, like, it did. It simultaneously did more things and more and less things than I thought at the same time. Oh, yeah.

Yeah. That's awesome.

Other things, security, it can be a little bit of a blur because you are calling it from the client. You might think, like, You sort of have to make sure that your security is buttoned down, because you are calling it from the client and you might not think about the security as well as it would be. So definitely have to step in and make sure all of that stuff is buttoned down.

I think that That's what we got there. I'm very curious to see if this type of thing will sort of take off. I guess we'll keep all eyes on React and Siblings, to see if this type of thing becomes more popular in building APIs.

Yeah. Yeah. Totally. And, again, I I personally don't feel that strongly either way about it. I I I don't mind a lot of the things that people are upset about when they think about our PC.

Mhmm. You know, they're you'll find people argue anything on on Twitter. But me personally, I do like, the developer experience of using RPC style clients, RPC clients in general. But, again, yeah, I I'm like we You said I'm mostly here to just consume the consume the things that are are given to us, and I'll just say, okay. Sure. Okay. I'll take it.

Awesome. Alright. Thanks, everybody, for tuning in. We'll catch you later. Peace.

Peace.

Head on over to syntax.fm

for a full archive of all of our shows.

And don't forget to subscribe in your podcast player Or drop a review if you like this show.