Thank you for your input. Regarding the Protobuf.js changes, one of the primary goals of this API change is to decouple gRPC from Protobuf.js as much as possible, because the existing tight coupling has prevented us from upgrading the dependency from Protobuf.js 5 to 6 without breaking the API. In addition, gRPC is serialization format agnostic, so we do not want users to need to use the service definition types from one specific serialization library. On top of that, there is some complexity in transforming the information in a Protobuf.js Service object into the information gRPC needs to run a client or server, so it is simpler for gRPC to expose an API with a service definition type that matches that information.
Adding "abortShutdown" and "unbind" functions is currently infeasible because the underlying API that the library is implemented on doesn't have that kind of granularity. However, this does indicate that the names of the existing functions may need to be changed. The function "tryShutdown" is really "unbind and stop accepting incoming calls, and notify when all ongoing calls have terminated". So, "try" isn't really accurate, because it doesn't actually fail. And "forceShutdown" is really "unbind and stop accepting incoming calls, and terminate all ongoing calls immediately". Regarding the connection and disconnection hooks, having the API expose calls and not connections is a deliberate design choice. We explicitly do not support per-client state. Part of the reason for this is that the semantics of gRPC do not correspond exactly to the semantics of HTTP/2, in some ways that would cause unexpected outcomes for people trying to use this kind of per-connection state. In particular, gRPC clients do automatic reconnection, which means that the "same client" may be multiple connections, and gRPC clients also do client-side load balancing, which means that a single client may send different requests to different servers. Basically, there are no guarantees that per-connection state would persist for the lifetime of a client, or that any particular request would be made to a server that already has that state. The solution to these is to include that state in call metadata or in a database that can be referenced using call metadata. I am interested in the "API layering" suggestion, but I'm not exactly sure what it would entail. Can you expand a bit on what this API that you are suggesting might look like? I am particularly interested in what a unary call and a bidirectional streaming call would look like. On Mon, Dec 11, 2017 at 3:08 AM <[email protected]> wrote: > # Protobuf.js-related Changes > > - protobuf.js can already parse and reflect upon service definitions. > Can't we just reuse this functionality and pass the `Service` reflection > object to the main API? > > # Extend server API > - Add a method `Server.abortShutdown()` to complement > `Server.tryShutdown()` > > Reason: a server might decide it is overloaded and is not able to process > more clients, but that state is transient and might be remedied in the > future. > > `Server.tryShutdown()` should not unbind from the server port. There > should be a complementary method `Server.unbind()` to `Server.bind()`. > > - Per client connect and disconnect hooks > > The server API should provide per client connection and disconnection > hooks, that are called with a server side `Connection` object (naming up > for discussion). > > Reason: A service might want to implement per connection state > (authenticated, etc…), or simply keep track of connected clients (eg. for > load statistics or connecting to per client backend services). > > - The server side `Connection` object should provide a method to send > `GOAWAY` and `PING` frames (and maybe other advanced functionality). > > # API layering > > Since I do not expect the current callback/streams based API to change > anytime soon, it should be modified a little bit to enable an easier > layering of different call styles on top of it. I am thinking here of > promises, generators and rxjs style APIs. > > For example, the object `ServerWriteableStream` conflates three distinct > entities into one: > > - The `request` object from the client. > - Metadata about the call (cancelled state, client metadata, peer info). > - A `Writable` stream for sending responses and completing/aborting the > call. > > If these were provided as separate objects to the handler function, > different APIs could be layered more cleanly on top of it. For rxjs for > example, a `ServerWriteableStream` could be driven from an `Observer` of an > `Observable` provided from a higher level API, while the request and > metadata objects could be passed up unmodified. > > Best, > André > > > On Tuesday, November 28, 2017 at 12:00:59 AM UTC+1, Michael Lumish wrote: >> >> I have created a proposal that describes changes that will be made to the >> Node.js gRPC API for the major version bump to 2.0: >> https://github.com/grpc/proposal/pull/46. If you have any comments or >> suggestions, please discuss them in this thread. >> > -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/b2e9c1f3-7403-43c1-8c39-570e802ce909%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/b2e9c1f3-7403-43c1-8c39-570e802ce909%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAPK2-4cqrEi1s59ZDzaJxp34UfYAH9JZTZ0qFviXhoRtHiMkMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
