We should use a RPC server instead of a REST server for our internal CRUD operations.
This issue may close the following issues:
25 - grpc-kotlin has a Protocol Buffers compiler
21 - This will deprecate the REST server for internal operations
Motivations and the proposed solution
We recently proposed the usage of a REST server for both internal and public operations, but in fact, REST is about 7 times slower than a gRPC server for data receiving and 10 times slower than gRPC for data sending, so that's the main reason for avoiding REST in our network.
Another reason for avoiding the REST usage in our server is it requires many workarounds for adding the possibility of internal calls and it is way more insecure. It is obvious that the Public API will still be available for the Rest API, but internally it will access our RPC server though. In other words, internally we will use gRPC directly, and a REST server will be available for public consumption of our services.
The main reason for using gRPC specifically and not another RPC framework is it gRPC is available for our target programming languages (Kotlin is officially supported, and Rust is supported by the community), and it is fast enough. It is also updated very frequently, so we don't expect to be using outdated technologies.
grpc/grpc-kotlin - The gRPC client that will be used in our internal operations will be written in Kotlin.
hyperium/tonic - The gRPC server itself will be written in Rust.
Suggestions are appreciated for new sections in this issue, or if you have a better idea about how to structure or improve our RPC server, feel free to comment down below. Thank you for the attention.
axyiee
commented
2 years ago
Moving to a RPC server
Table of contents:
Summary
We should use a RPC server instead of a REST server for our internal CRUD operations.
25 -
grpc-kotlinhas a Protocol Buffers compiler21 - This will deprecate the REST server for internal operations
Motivations and the proposed solution
We recently proposed the usage of a REST server for both internal and public operations, but in fact, REST is about 7 times slower than a gRPC server for data receiving and 10 times slower than gRPC for data sending, so that's the main reason for avoiding REST in our network.
Another reason for avoiding the REST usage in our server is it requires many workarounds for adding the possibility of internal calls and it is way more insecure. It is obvious that the Public API will still be available for the Rest API, but internally it will access our RPC server though. In other words, internally we will use gRPC directly, and a REST server will be available for public consumption of our services.
The main reason for using gRPC specifically and not another RPC framework is it gRPC is available for our target programming languages (Kotlin is officially supported, and Rust is supported by the community), and it is fast enough. It is also updated very frequently, so we don't expect to be using outdated technologies.
grpc/grpc-kotlin- The gRPC client that will be used in our internal operations will be written in Kotlin.hyperium/tonic- The gRPC server itself will be written in Rust.eexsty/prost- A fork oftokio-rs/prostwhich removes theprost::Messagederivation will be used.Final considerations
Suggestions are appreciated for new sections in this issue, or if you have a better idea about how to structure or improve our RPC server, feel free to comment down below. Thank you for the attention.