Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

They say not to rely on the output being stable, so I would recommend guaranteeing a stable translation yourself for a REST client. You can achieve this by translating from the JSON to your proto or grpc service structure yourself.

This is like saying all programs should be written in C, because otherwise programmers forget about how memory allocation works and the cost involved.

Any good REST client implementation abstracts away the remoteness too, apart from occasionally returning a network error the caller. I’m definitely not sitting there twiddling bits to call a REST API.

> It requires both server and client to agree on the definition.

This is true of literally every API. If the client and the server disagree on a REST API call, nothing good is going to happen. Period.

gRPC is designed to allow evolution of APIs where clients and servers have different versions of the IDL. It’s no more brittle than a JSON API, and arguably it’s actually less brittle because of how the approach it takes.

> It requires a different naming service from the standard internet naming service (DNS) which is brittle across network boundaries.

That is unequivocally false.

It doesn’t use a special naming service to connect servers and clients, unless you specifically choose to override the default behavior, which you could also do with JSON API if you wanted to make it really brittle as well.

Instead just use DNS, which is the default for both.

It absolutely doesn’t require a special naming service, as you claim.

gRPC is built on the HTTP/2 standard. Based on the rest of your comment, you clearly also didn’t know this.

> gRPC is a repeat of CORBA is a repeat of ONC-RPC is a repeat of... there's common reasons why RPC as a concept is brittle and tightly couples implementations of clients and servers.

Your information so far can be trivially disproven, so... apologies if I’m not going to take advice from you on this subject right now.

I’m glad JSON API works for you.

EDIT: I see you repeated a lot of this misinformation in yet another comment. I get it —- the very idea of RPC is offensive to you. But you should at least research the technology you’re ranting about. Your information about gRPC is entirely, factually wrong.

* It requires tight coupling between client and server

* It uses non standard naming and discovery which doesn't work across network boundaries, which is why SOAP and XML-RPC were invented, a way of channelling RPC over port 80/443.

* The problems of handling of state synchronization between client and server and the lack of standard failure and error modes.

* The lack of standards for caching of responses or middleware boxes for load balancing, rate limiting, deployment practices.

REST avoids these (and others) by:

* Using content negotiation and media types to communicate the format of requests and responses

* Using standard (DNS) naming and discovery network mechanisms

* Is a stateless protocol (between requests) that specifically expects that the client and server will exchange their states as part of each individual request. Being stateless, it accommodates network errors and the definitions of idempotency and limits on the number and types of verbs and reasonably strict definitions of their use also provide standard mechanisms for recovery.

* Specifically defines and accomodates naming, discovery, caching, chunking requests/replies, streaming, middleware cache and content distribution, network boundaries, security authentication and authorization etc.

Other than having an IDL that has tooling to generate stubs/clients in multiple languages, there are no distinct advantages of gRPC/protobuf over REST/HTTP, particularly in the general case of independent clients and servers from different organizations and user groups.

gRPC is a reasonable solution if your systems are able to be tightly coupled and deployed because they are either being developed as a monolith, or entirely within a common organization. If your network is reliable and not subject to interruption or partitioning between boundaries.

The entire "web services" saga of SOAP, WSDL, WS-* was an attempt 10-15 years ago to once again attempt RPC. So was RMI for Java. They failed for the same reasons.

People have been trying to "improve" RPC since the 80s, with numerous attempts and incarnations. They all suffer the same problems, which is that you cannot "wish away" the network by abstracting it out of existence.

The "annoying, pointless" questions of REST can be solved by not bikeshedding them each time, adopt JSON Schema, OpenAPI, JSON API and understand that REST is about the nouns, not the verbs. Limiting and strictly defining the operation of the verbs, which is what HTTP does, let's you focus on the nouns and how you want to "transfer the state" of the nouns between two endpoints. That's what REST is about.