What is JSON-RPC and what are its top alternatives?
JSON-RPC is a remote procedure call protocol encoded in JSON. It allows for the communication between a client and a server over a network. Key features include a simple and lightweight format, support for multiple transport protocols, and compatibility with various programming languages. However, JSON-RPC has limitations such as lack of standard error handling and security vulnerabilities.
- gRPC: gRPC is a high-performance, open-source RPC framework developed by Google. It uses Protocol Buffers for serialization and supports features like bi-directional streaming and authentication. Pros include efficient network communication and built-in support for load balancing, while cons include a steeper learning curve compared to JSON-RPC.
- REST: Representational State Transfer (REST) is an architectural style for building APIs. It uses standard HTTP methods like GET, POST, PUT, and DELETE for communication. Key features include statelessness and widely adopted standards, but drawbacks include over-fetching and under-fetching of data.
- GraphQL: GraphQL is a query language for APIs developed by Facebook. It allows clients to request only the data they need, reducing over-fetching. Pros include flexibility and efficiency in data fetching, but cons include a more complex setup compared to JSON-RPC.
- Thrift: Apache Thrift is a scalable, efficient RPC framework that supports multiple programming languages and transport protocols. It offers built-in support for service definitions and serialization. Pros include high performance and language interoperability, but cons include a more complex setup compared to JSON-RPC.
- MessagePack-RPC: MessagePack is a binary serialization format that is more compact and faster than JSON. MessagePack-RPC uses MessagePack for encoding RPC messages, providing a lightweight alternative to JSON-RPC. Pros include efficiency and performance gains, but cons include lack of widespread adoption compared to JSON-RPC.
- RSocket: RSocket is a binary protocol for use on byte stream transports like TCP, WebSockets, and Aeron. It offers features like bi-directional communication, multiplexed streams, and backpressure. Pros include high performance and flexibility in communication patterns, but cons include a more specialized use case compared to JSON-RPC.
- Socket.IO: Socket.IO is a JavaScript library for real-time web applications. It enables real-time, bidirectional communication between clients and servers. Key features include support for WebSockets and fallback transports, but cons include a more specialized use case compared to JSON-RPC.
- XML-RPC: XML-RPC is a remote procedure call protocol that uses XML for encoding messages. It is platform-independent and supports various programming languages. Pros include interoperability and simplicity, but cons include verbosity and complexity compared to JSON-RPC.
- Apache Avro: Apache Avro is a data serialization system that provides rich data structures. It supports remote procedure calls and data serialization. Key features include schema evolution and compact binary format, but cons include a more specific use case compared to JSON-RPC.
- Apache Thrift: Apache Thrift is a scalable, efficient RPC framework that supports multiple programming languages and transport protocols. It offers built-in support for service definitions and serialization. Pros include high performance and language interoperability, but cons include a more complex setup compared to JSON-RPC.
Top Alternatives to JSON-RPC
- gRPC
gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking... ...
- GraphQL
GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012. ...
- REST
An architectural style for developing web services. A distributed system framework that uses Web protocols and technologies. ...
- Apache Dubbo
It is a high-performance, light weight, java based RPC framework. Dubbo offers three key functionalities, which include interface based remote call, fault tolerance & load balancing, and automatic service registration & discovery. ...
- Mercury
A modular JSON-RPC library that allows pluggable transport layers, JSON libraries, and effect/async monads. It is used to communicate with embedded devices where the device is acting in the server role. ...
- Tars
It is an open-source microservice platform. It contains a high-performance RPC framework and a service management platform. Based on Tars, you can develop a reliable microservice system efficiently. It is designed for high reliability, high performance, and efficient service management. By significantly reducing system operation work, developers can focus on business logic and meet fast changes of user requirements. ...
- RSocket
It is a binary protocol for use on byte stream transports such as TCP, WebSockets, and Aeron. It provides a protocol for Reactive Streams semantics between client-server, and server-server communication. ...
- Gravity Framework
It is a modern back-end framework with full-stack capacities written in Typescript. Its main feature is to facilitate communication in a safe way between server and client by using a remote procedure call system. It will give you the power to call a function defined in the server directly from the client - like if it's just a normal Javascript function. ...
JSON-RPC alternatives & related posts
- Higth performance24
- The future of API15
- Easy setup13
- Contract-based5
- Polyglot4
- Garbage2
related gRPC posts
I used GraphQL extensively at a previous employer a few years ago and really appreciated the data-driven schema etc alongside the many other benefits it provided. At that time, it seemed like it was set to replace RESTful APIs and many companies were adopting it.
However, as of late, it seems like interest has been waning for GraphQL as opposed to increasing as I had assumed it would. Am I missing something here? What is the current perspective regarding this technology?
Currently, I'm working with gRPC and was curious as to the state of everything now.
We need to interact from several different Web applications (remote) to a client-side application (.exe in .NET Framework, Windows.Console under our controlled environment). From the web applications, we need to send and receive data and invoke methods to client-side .exe on javascript events like users onclick. SignalR is one of the .Net alternatives to do that, but it adds overhead for what we need. Is it better to add SignalR at both client-side application and remote web application, or use gRPC as it sounds lightest and is multilingual?
SignalR or gRPC are always sending and receiving data on the client-side (from browser to .exe and back to browser). And web application is used for graphical visualization of data to the user. There is no need for local .exe to send or interact with remote web API. Which architecture or framework do you suggest to use in this case?
- Schemas defined by the requests made by the user75
- Will replace RESTful interfaces63
- The future of API's62
- The future of databases49
- Self-documenting13
- Get many resources in a single request12
- Query Language6
- Ask for what you need, get exactly that6
- Fetch different resources in one request3
- Type system3
- Evolve your API without versions3
- Ease of client creation2
- GraphiQL2
- Easy setup2
- "Open" document1
- Fast prototyping1
- Supports subscription1
- Standard1
- Good for apps that query at build time. (SSR/Gatsby)1
- 1. Describe your data1
- Better versioning1
- Backed by Facebook1
- Easy to learn1
- Hard to migrate from GraphQL to another technology4
- More code to type.4
- Takes longer to build compared to schemaless.2
- No support for caching1
- All the pros sound like NFT pitches1
- No support for streaming1
- Works just like any other API at runtime1
- N+1 fetch problem1
- No built in security1
related GraphQL posts
I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery
For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:
Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have
GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.
MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.