Angular support

Hi guys,

it would be really nice to have a deep Angular support.

One can say it is supported, and, well, one can use it with Angular. However, it currently feels like an alien bird in the nest because

1. two-way binding and export message as “normal” JavaScript-friendly Object is not possible and sorry, but to me it is not usable, see https://github.com/grpc/grpc-web/issues/382#issuecomment-442005857
2. dependency injection is not anyhow taken into account. Ideally every service client could become a native angular service
3. the methods are not compatible with neither RX Observables / native Promises. With Promise it is quite clear it cannot be supported because of non-unary methods, but RX is fully compliant here.

This is what I came to after a couple of attempts

export function fromClient<T>(c: T) {
  return <any>autoBind(<any>c) as T;
}

export function fromUnary<T extends Message>(clientMethod: (...p) => UnaryResponse, request: Message, meta?: Metadata) {
  return new Observable<T>(obs => {
    const req = clientMethod(request || null, meta || null, (err: ServiceError, response: T) => {
      if (err) {
        obs.error(err);
      }

      obs.next(response);
      obs.complete();
    });

    return () => req.cancel();
  });
}

and usage:

const client = fromClient(new HelloServiceClient(environment.grpc));
const obs = fromUnary<Hello>(client.getHello, new HelloRequest());

This code is far away from ideal. It is actually ugly, because I need to monkey-bind the methods and status is not returned anyhow yet (however the status part is quite solvable with pipe > filter and some boolean parameter in observable response).

Finally, the question: do you plan to support Angular in this / related repository? Should @angular/cli care of this instead? Or it is up to the end user to decide how to solve this problem?

I am ready to participate / support here (if possible).

[smnbbrv]

I gave up using it with angular for now. And the reasons are way bigger than the originally mentioned.

The show stopper for me is the inability to use two-way binding. The generated messages have a structure of Java-like setters / getters, while JavaScript has pure set / get attributes. That means all forms that are directly bound / mutating the message (at least template driven) are not usable anyhow. Angular material also mostly refers to the properties as names (see https://material.angular.io/components/table/overview table sorting and table filtering) and not as getters / setters.

A possible solution would be to use the toObject functionality (which is somehow implemented by https://github.com/improbable-eng/grpc-web), but it is not standardised in proto v3 and does not seem to appear. Even if the mentioned above was working, there is no fromObject functionality to cast it back.

This is all very sad. I was really looking forward to use gRPC because I am sick tired of translate-copy-pasting the interfaces but, well, the latter is way easier than using current gRPC implementations. There are too many limitations.

I update the original post with these thoughts as well.

[zaucy]

I think it would be better suited to have a protoc plugin that supplies ‘deep’ support for angular instead of including it in this repository. There’s no end to the amount of frameworks that could incorporate gRPC Web. I think it would be unreasonable to keep support for these frameworks in this repository.

I have experimented with a plugin for angular support. All it does is wrap services into injectable angular services and wraps grpc-web’s calls to use Promises and Observables. However, it is only tested with improbable-eng’s implementation of gRPC Web. You can see it here: https://github.com/zaucy/protoc-gen-angular and it is also available as an npm package here: https://www.npmjs.com/package/@grpc-gen/protoc-gen-angular.

I plan on updating it in the future, but I have no timeline. I would happily accept pull requests or any kind of collaboration (in the form of a GitHub issue) from the community to make it more useable.

Side Node: the @grpc-gen organization is just a prefix so I don’t clog up any npm package names in case someone makes a fantastic protoc-gen-angular plugin before I do.