Question regarding deprecation status of C-based client and server

On the npm package information page for the grpc package, it lists the following:

This library is now only receiving bug fixes and runtime compatibility updates. In April 2021 it will be deprecated and will no longer receive any updates.

I’m wondering about the status and motivation behind this deprecation notice. Specifically, I’m curious because if I look at at the feature comparison page between the grpc and @grpc/grpc-js packages, it seems like there are still some notable items missing from the @grpc/grpc-js package.

However, perhaps more important is that even simple examples demonstrate a fairly substantial performance difference when run on my local machine. For example, the following “hello world” example (based on the grpc/examples) demonstrates a consistent improvement in performance when using the C-based grpc package as opposed the JavaScript-based @grpc/grpc-js package.

helloworld.proto:

syntax = "proto3";

package helloworld;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

package.json:

{
  "name": "grpc",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "grpc": "1.24.3",
    "@grpc/grpc-js": "1.1.7",
    "@grpc/proto-loader": "0.5.5",
    "google-protobuf": "3.13.0"
  }
}

server.js:

// var PACKAGE_NAME = 'grpc';
var PACKAGE_NAME = '@grpc/grpc-js';

var grpc = require(PACKAGE_NAME);
var protoLoader = require('@grpc/proto-loader');
var packageDefinition = protoLoader.loadSync('helloworld.proto', {
    keepCase: true,
    longs: String,
    enums: String,
    defaults: true,
    oneofs: true
});
var hello_proto = grpc.loadPackageDefinition(packageDefinition).helloworld;

function sayHello(call, callback) {
    callback(null, {
        message: 'Hello ' + call.request.name
    });
}

function main() {
    var server = new grpc.Server();
    server.addService(hello_proto.Greeter.service, {
        sayHello: sayHello
    });
    server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), function() {
        server.start();
    });
}

main();

client.js:

// var PACKAGE_NAME = 'grpc';
var PACKAGE_NAME = '@grpc/grpc-js';

var grpc = require(PACKAGE_NAME);
var protoLoader = require('@grpc/proto-loader');
var packageDefinition = protoLoader.loadSync('helloworld.proto', {
    keepCase: true,
    longs: String,
    enums: String,
    defaults: true,
    oneofs: true
});
var hello_proto = grpc.loadPackageDefinition(packageDefinition).helloworld;

function main() {
    var client = new hello_proto.Greeter('localhost:50051',
        grpc.credentials.createInsecure());
    var user = "world";
    var now = Date.now();

    client.sayHello({
        name: user
    }, function(err, response) {
        console.log('Greeting:', response.message);
        console.log(Date.now() - now);
    });
}

main();

In this case, if I set PACKAGE_NAME to '@grpc/grpc-js', I can run node client.js (once I have started the server) and it reports a message response in around 22-30ms (averaged 24.1ms over 10 runs). Interestingly, there is also a long pause after completion (presumably this is waiting for some socket to close?). If, however, I set PACKAGE_NAME to 'grpc', node client.js consistently reports less than 10ms (averaged 6.6ms over 10 runs). This performance difference seems to be attributable to the client-side of the gRPC implementation, because if I only switch the client to use the native C-based package, I observe similar results.

I’m wondering if there has been any formal performance comparison between the two packages and whether this will be considered in the deprecation of the apparently more performant C-based package. The reason I ask all of this is I’d like to use the more performant C-based package, however, the deprecation notice is concerning and makes me question its long-term future.

P.S. I apologize if this question has been asked and answered elsewhere, I searched the issues for similar topics but didn’t find anything relevant.

Thanks!

[murgatroid99]

We chose to move towards deprecating the old grpc library primarily because of major usability and maintainability problems related to the native module it relies on. At this point, continued active support of that library is essentially untenable.

Regarding feature support, while we do not yet have complete feature parity, we do have all of the features necessary for complete protocol-level compatibility with other libraries, and almost all of the features that (as far as I know) are actively used by Node gRPC users. In addition, that document imperfectly captures the scope of the feature set of this library. It doesn’t show the relative size or importance of the different features, and it doesn’t exactly cover everything. If there is a feature you want to use but is not available in grpc-js please file an issue about it so that we know to prioritize it.

Regarding performance, the benchmark you created here is measuring two things: the time it takes to initialize the connection(s) and the time it takes to make the request and get the response. The intended and recommended usage of gRPC is to create a connection once and then use it to make many requests, so in our own benchmarks we generally focus on the request time, and consider the connection establishment time to be amortized over many requests. I think you will find that if you measure just the time it takes to make a request, the numbers will be closer. Also, http2 is a relatively new module in Node and is still somewhat in active development so you may see some differences if you run the benchmark on a newer version of Node.

However, I will not claim that grpc-js performance is fully on par with grpc. The old library’s core had a lot of optimization work over the years, and grpc-js has some catching up to do. But that work can be done, and I am confident that we can get close to the same performance.

[sgerace]

Hi @murgatroid99, thanks for the very detailed response. I can definitely appreciate the added challenges related to maintaining two versions of a package. I also agree that in general, the time required to connect will be less important than the request performance since, as you pointed out, you should only be doing that once.

Regarding using a newer version of Node, that is a good point that we’ll investigate. We’re planning on upgrading to either Node 12.x or 14.x in the coming weeks, so I’ll definitely add this to the list of things to check. I’ve certainly witnessed fairly substantial performance improvements when upgrading Node versions in the past, so I wouldn’t be surprised to see similar improvements here.

Finally, simply hearing your explanation, and your acknowledgment that performance is absolutely a concern of the project and its maintainers, is very reassuring. Additionally, the fact that work is being performed to get grpc-js performance closer to grpc is good to know, as is hearing your confidence that you expect the gap to be closed over time.

Thanks again, I’ll go ahead and close this issue as I feel like my original question has been sufficiently addressed.