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
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 yes, I found it too!
Some man few weeks ago commited to PromiseClient template generation, you can contribute to create AngularWayRxJSClient, it will be very helpful for using it from Angular.
Also I share some my findings:
1) DI
providers: [
TodoService,
{
provide: TodoServiceClient,
useFactory: TodoServiceClientFactory
}
]
where TodoServiceClientFactory is:
import { TodoServicePromiseClient } from '@grpc/todo_grpc_web_pb';
import { environment } from '@environments/environment';
export const TodoServiceClientFactory = () => {
return new TodoServicePromiseClient(environment.backendUrl, null, null);
};
2) About bad code generation:
I also use Observable wrapper as you do.
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.
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.
I'm working on another Angular gRPC example project here:
https://github.com/kmturley/angular-nest-grpc
Is there any auth example in Angular ?
@N1nJaC0d3 here is the example about how to send auth token.
https://github.com/ultrasonicsoft/grpc-spring-angular-auth/blob/master/src/app/api.service.ts
Hi Dalu,
You can create an issue in my project, if you feel it isn't working correctly. I did document in the README:
If you update backend .proto files, then you will need to recompile them to frontend services using:
cd frontend
npm run compile
Envoy proxy should run automatically as part of the docker-compose up. If it's not working, please create an issue and I can look into it!
I started a small project which goal was primarily to learn how to create protoc plugins and protobuf as well, but, as it happens often it did not stop there and I've got some sort of working solution out of it.
If you are interested to learn more - https://github.com/ngx-grpc/core . It targets all the Angular integration issues I know about; adds lots of missing features like interceptors etc.
Currently I started to use it in one of my projects, let's see how it goes.
Most helpful comment
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
toObjectfunctionality (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 nofromObjectfunctionality 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.