Grpc-web: I don't like GraphQL, grpc-web can be alternative?

[NiNJAD3vel0per]

I am seriously considering of Getting rid of GraphQL in my all apps.
Because GraphQL is just a rpc-like alternative and it has several disadvantages over Rest API.
I am thinking of using Rest + gRPC web combination for my all web apps.
HTTP/2 enhances Rest API style architecture.
gRPC(grpc-web) can improve the performance significantly.
We don't need to use GraphQL(this facebook webtech is just temp. web technique until other better solutions become mature like HTTP/2 with Rest and gRPC-web)

grpc-web progress is quite slower than I think.
Hey grpc core team in Google; Please work harder.. I don't like GraphQL..

[jonahbron]

GraphQL has additional features that are not within the scope of GRPC-Web. However you could implement a similar set of features on top of GRPC-Web (which I have in my system to some degree).

[RXminuS]

Ok, love the enthusiasm but I think it's important to place things in perspective here. Maybe it's a good idea for the team to put up a very clear "how does GPRC compare to..." page.

First, grpc-web Won't magically improve performance, you need to benchmark for your specific application to make sure it does. There is a significant overhead with the proxy, and depending on how you write resolves it could be really beneficial to only compute/cache the data that is needed. You could do the same thing in GRPC...but you'd be on your own.

There's also nothing preventing you from running GraphQL over http2. In fact it would probably be a bit easier since grpc-web needs to handle HTTP2 push over 1.1 connections using some envoy filters.

I wouldn't say grpc-web is mature at this point. It's only just become a "GA" feature but there is still a ton of bugs and documentation missing. The GraphQL ecosystem is amazing, especially if you stay in Typescript land.

That being said, GRPC does have some advantages (and for us they were important, so we are very happy with our choice). It's easier to deal with binary blobs (uploads etc). I personally find streaming requests a bit more intuitive than the invalidation logic in GraphQL. And if you have a lot of GRPC internally between microservices (90% of our code is Go/Python GRPC linked) it can be a natural extension.

However, based on your comment I'm guessing that you aren't using GRPC already, that there is a working GraphQL implementation AND that the performance increase probably won't materialize...therefore my suggestion would be to not change...as much as I personally like grpc-web.

[NiNJAD3vel0per]

Ok, love the enthusiasm but I think it's important to place things in perspective here. Maybe it's a good idea for the team to put up a very clear "how does GPRC compare to..." page.

First, grpc-web Won't magically improve performance, you need to benchmark for your specific application to make sure it does. There is a significant overhead with the proxy, and depending on how you write resolves it could be really beneficial to only compute/cache the data that is needed. You could do the same thing in GRPC...but you'd be on your own.

There's also nothing preventing you from running GraphQL over http2. In fact it would probably be a bit easier since grpc-web needs to handle HTTP2 push over 1.1 connections using some envoy filters.

I wouldn't say grpc-web is mature at this point. It's only just become a "GA" feature but there is still a ton of bugs and documentation missing. The GraphQL ecosystem is amazing, especially if you stay in Typescript land.

That being said, GRPC does have some advantages (and for us they were important, so we are very happy with our choice). It's easier to deal with binary blobs (uploads etc). I personally find streaming requests a bit more intuitive than the invalidation logic in GraphQL. And if you have a lot of GRPC internally between microservices (90% of our code is Go/Python GRPC linked) it can be a natural extension.

However, based on your comment I'm guessing that you aren't using GRPC already, that there is a working GraphQL implementation AND that the performance increase probably won't materialize...therefore my suggestion would be to not change...as much as I personally like grpc-web.

@RXminuS
Thanks for your mentions ! :)
I've already tested Grpc (not grpc-web) in Go and Python.
GRPC seems like an alternative solution especially for streaming and upload binaries just like you said and furthermore, Microservice! among stubs in a server-side area.

The main problem of graphql is it only utilizes "POST".Also, it is quite bothersome to set up graphql between client and server because my most of apps are based on Rest, not Graphql.
If I could, I'd like to spend the time to set up Grpc-web instead of GraphQL in near future.
I don't agree Graphql can replace the restful api world.
I know grpc-web is immature for now, yet it seems quite promising to me.

ps. I am actually a fan of Google rather than Facebook !
It would be nice to use grpc-web in my Angular webapps.