You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
No, not a problem. Missing functionality.
Describe the solution you'd like
This is an inquiry about the state of the server implementation in the pure JavaScript module.
Describe alternatives you've considered
None
Additional context
I'm mostly curious if anyone is working on this in any capacity. I've made some progress on this at https://gist.github.com/cjihrig/3017098791307ff04b728fff1b0a6c79https://www.npmjs.com/package/grpc-server-js. I'm very interested in moving to the pure JS module (even though it's beta) and am happy to help work on the server implementation. If I'm not totally off the mark with my implementation thus far, I'd like to convert it to TypeScript and PR it (assuming the beta status means that it doesn't need to be 100% done and production ready).
Currently, the server is a planned feature in the future, but we haven't done any work on it yet. The code you have there is interesting, but I wouldn't consider it complete enough to publish. The clients in both implementations pass the same set of interop tests, and I would want to do the same thing with the server to consider it a minimal working server. This would at least require support for all kinds of calls, plus at least basic compression support to handle incoming compressed messages, and there may be other things I'm not thinking of at the moment. I would also want some level of cancellation and deadline support, because those features are already implemented on the client.
I think all of that functionality will require a more complex implementation than what you currently have, and I think some design work may need to be done.
Thanks for the update. I didn't see it before. I will take another look at that code, and we might be able to integrate it with a bit of work. One hard requirement for integrating it into our codebase is that the public API has to exactly conform to the existing server in the other library. Some can just throw a not implemented exception, like addProtoService. But it needs to have addHttp2Port instead of bind, even if that makes the internals awkward.
I think I'll go ahead and close this. Right now my team is using the server as is, so exact API parity with the old module isn't too important. I also want to have some control over the code and release schedule to work on some new features. Thanks for the feedback though!
Activity
murgatroid99 commentedon Sep 10, 2018
Currently, the server is a planned feature in the future, but we haven't done any work on it yet. The code you have there is interesting, but I wouldn't consider it complete enough to publish. The clients in both implementations pass the same set of interop tests, and I would want to do the same thing with the server to consider it a minimal working server. This would at least require support for all kinds of calls, plus at least basic compression support to handle incoming compressed messages, and there may be other things I'm not thinking of at the moment. I would also want some level of cancellation and deadline support, because those features are already implemented on the client.
I think all of that functionality will require a more complex implementation than what you currently have, and I think some design work may need to be done.
cjihrig commentedon Sep 10, 2018
OK, since no work has been started on the server, I plan to keep working on it.
UPDATE: Feedback has been incorporated, and all previously mentioned features implemented. Published on npm as https://www.npmjs.com/package/grpc-server-js.
murgatroid99 commentedon Sep 20, 2018
Thanks for the update. I didn't see it before. I will take another look at that code, and we might be able to integrate it with a bit of work. One hard requirement for integrating it into our codebase is that the public API has to exactly conform to the existing server in the other library. Some can just throw a not implemented exception, like
addProtoService. But it needs to haveaddHttp2Portinstead ofbind, even if that makes the internals awkward.cjihrig commentedon Sep 20, 2018
I think I'll go ahead and close this. Right now my team is using the server as is, so exact API parity with the old module isn't too important. I also want to have some control over the code and release schedule to work on some new features. Thanks for the feedback though!