gRPC + Web + Client + GraphQL Support?

[smlarkin (Shawn Michael Larkin)]

From all my research, gRPC looks to be the most performant / reliable alternative to HTTP, but is only supported server-side currently.

There is a way to add a proxy between client / server to use gRPC on the frontend but this adds another layer of complexity. Also, there is a gRPC roadmap to natively support it in the browser, but this is probably gong to take a few years to happen.

Currently, Dgraph does have a client JS library that supports gRPC (Node) for GraphQL +/-. And I understand this library will be expanded to support Vanilla GraphQL soon too

I use Apollo Client, which has hooks for React. It’s a good frontend promise-based library that has a lot of helpful features built into it. But it would be even better if I could add the performance of gRPC to connect to Draph / GraphQL – instead of sending the traditional GraphQL spec (an HTTP Post for every request).

I see frontend gRPC as an evolutionary progression from HTTP – just an opinion – as HTTP 2 becomes more ubiquitous. What would it take to create a web client that supported gRPC (…hopefully with vanilla GraphQL baked in too)?

[MichelDiz]

@smlarkin

There is a way to add a proxy between client / server to use gRPC on the frontend but this adds another layer of complexity.

You can use Nginx see this Dgraph + Nginx Load Balancing · GitHub forked from @dmai

@smlarkin

And I understand this library will be expanded to support Vanilla GraphQL soon too

Hum, I’m not aware of this. There’s no roadmap to add support for GraphQL in any client made by Dgraph. There is an internal conversation about creating a GraphQL Client, but it is really incipient. But not sure if we are going to do it for real, as there are tons of clients out there supported by GraphQL specs. ping @michaelcompton

@smlarkin

it would be even better if I could add the performance of gRPC to connect to Dgraph / GraphQL

gRPC is not a thing yet in the GraphQL community. There is a little movement about that. It requires specifications and etc. One of the problems with GraphQL via gRPC is how to implement subscriptions with gRPC since it has been standardized to use WebSockets. It is possible to replicate this with gRPC, but it requires more thought about it (e.g support it in the browser would be essential).

IMHO, HTTP still works perfectly. I can’t see the need to add complexity to that. This on the browser side can get too much complex as gRPC was created to serve side. If you put several Dgraph nodes behind a load balance, there will be no limitations that will distance HTTP from gRPC performance.

Cheers.