Why cross-platform apps looking to scale should use RPC (over plain old IPC and instead of REST)

IPC (Inter-process communication) and RPC (Remote procedure call) are both methods of communication between processes. However, there are some key differences between the two methods that make RPC a more suitable choice for cross-platform desktop applications.

IPC is a general term for any method of communication between processes. It can be implemented in a variety of ways, including shared memory, pipes, and sockets. IPC is typically used for communication between processes on the same machine.

RPC is a more specific type of IPC that allows processes to communicate with each other over a network. RPC is typically implemented using a client-server model. The client process makes a request to the server process, and the server process returns a response.

There are several reasons why using RPC over IPC is important for cross-platform desktop applications:

• Security: RPC can be used to implement security features, such as authentication and authorization. This is important for cross-platform desktop applications, as they may need to communicate with servers that are not under the control of the application developer.
• Scalability: RPC can be used to scale applications. For example, an application can use RPC to communicate with a server that is running on a different machine. This can help to improve the performance of the application, as it can offload some of the processing to the server.
• Portability: RPC is a more portable method of communication than IPC. This is because RPC is typically implemented using a standard protocol, such as the Remote Procedure Call (RPC) Protocol. This means that RPC can be used to communicate between processes that are running on different platforms.

Overall, RPC is a more secure, scalable, and portable method of communication than IPC. This makes RPC a more suitable choice for cross-platform desktop applications.

RPC (Remote Procedure Call) and REST (Representational State Transfer) are both methods of communication between a client and a server. However, there are some key differences between the two methods that make RPC a more suitable choice for cross-platform desktop applications.

RPC

RPC is a method of communication that allows a client to call a procedure on a server as if it were calling a local procedure. This is done by sending a message to the server that contains the name of the procedure and the arguments to be passed to the procedure. The server then executes the procedure and returns a message to the client containing the results of the procedure.

REST

REST is a method of communication that uses HTTP requests to access resources on a server. This is done by sending an HTTP request to the server that specifies the resource to be accessed and the desired action to be performed on the resource. The server then returns an HTTP response that contains the requested resource or an error message.

Why RPC is important for cross-platform desktop applications that want to scale

There are several reasons why RPC is important for cross-platform desktop applications:

• Performance: RPC can be more efficient than REST for cross-platform desktop applications because it can avoid the overhead of HTTP requests.
• Security: RPC can be more secure than REST for cross-platform desktop applications because it can use authentication and authorization mechanisms to protect data.
• Portability: RPC can be more portable than REST for cross-platform desktop applications because it is not tied to a specific protocol.

Why REST is not as suitable for cross platform apps

REST is not suitable for cross-platform desktop applications because it is not as efficient, secure, or portable as RPC.

• Efficiency: REST is less efficient than RPC because it requires the client to make an HTTP request for every resource that it needs to access. This can add overhead and latency to the application.

• Security: REST is less secure than RPC because it does not support authentication and authorization mechanisms. This can make it easier for unauthorized users to access sensitive data.

• Portability: REST is less portable than RPC because it is tied to the HTTP protocol. This can make it difficult to use REST with applications that are not web-based.

Overall, RPC is a more suitable choice for cross-platform desktop applications than REST. RPC is more efficient, secure, and portable than REST, which makes it a better choice for applications that need to be performant, secure, and portable.

By implementing RPC based on something like JSON RPC 2.0 and using an RPC implementation as a layer on top of your IPC communication you are able to decouple the data layer from the GUI layer of your cross platform application and ultimately expand beyond the constraints put on you, your team, and your project by default when building a cross platform desktop app's like when building out applications when any of the following technologies:

• Tauri (Build Cross Platform Desktop apps with Rust+Wry/front-end agnostic way)

• Electron (Build Cross Platform Desktop apps with Node/Chromium)

• Wails (Build Cross Platform Apps with Go/Chromium[at least I think it's chromium])

Conclusion

While RPC APIs, REST APIs, and IPC communication can all be used together, our industry has a bias towards using REST over RPC and IPC due to a lack of knowledge and a lack of need for tools that allow processes to communicate with each other.

Using REST instead of RPC can make it difficult to build applications that need to have services communicate with each other via server-side streaming, client-side streaming, or bi-directional streaming.

My team needed to create a click and point GUI alternative around an existing command line interface, and command line interface programs come with a lot of streaming of data.

Rest wasn't an option, IPC was our default because for Tauri, Electron, and Wails that's what is in the documentation.

But the best option is to implement IPC via some sort of RPC specification and decouple the data layer from the GUI layer.

Using IPC without a specification, such as the JSON RPC 2.0 spec, can make it difficult to authenticate users and can limit an application's data layer to only communicating between processes on the same machine. This can prevent an application from being able to run as a process on any device or server and as a cross platform application scales and grows, the monolithic nature of distributed artifacts will constrain the ability to build cool things while also greatly slowing down the software development cycle as the User Interface and User Experience becomes inhibited by any cross platform concerns and bugs.

Instead, from the get go, use RPC for IPC communication and decouple your front-end GUI from your back-end data layer while setting your self, your project, and your team up for long term success by eliminating any constraints.