Magento 2 interconnectivity: gRPC or GraphQL?

What is gRPC?

First of all, gRPC stands for gRPC Remote Procedure Calls, where in the g stands for gRPC. It is a recursive joke (just like GNU). But because Google came up with it, most people say that the G stands for Google. As described on their own website, gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems.

The main key here to understand is the word transparently. The client and server applications do not need to know about their existence, they don't even need to know gRPC its protocol, it is up to the gRPC configuration to connect the dots. This is in contrast to other protocols like SOAP or GraphQL, where both sides explicitely need to make use of the protocol to send messages forth and back.

How gRPC kind of works

With gRPC, you'll make sure that the gRPC configuration connects to an available call in the application (for instance, a public function in a PHP class in Magento, which has a specific signature of input arguments and return value).

In my example above, I referred to a PHP class, but this is actually where things are a bit complicated: There is a PHP client available, but there is no PHP server available (due to the fact that PHP does not use long-living processes by default). There are server packages available for Node, Go and so. So, typically with Magento, you would be using Magento as client to connect to gRPC-driven services written in other languages.

GraphQL vs gRPC

Often, GraphQL and gRPC are compared with each other - so they are compared in this blog as well. However, I personally think they are very different. Still, because they are both used in the light of Magento and microservices (at least, in this blog), it makes sense to cover the comparison anyway.

About GraphQL

When GraphQL was integrated into Magento, the main idea was to make sure there could be a headless frontend (PWA Studio) to make use of the GraphQL API of Magento to fetch all relevant data from the backend. With this, the GraphQL API quickly became a BFF (not best friends forever, but a Backend for Frontend).

However, the GraphQL ecosystem is much larger than the Magento GraphQL API: There are companies like Relay and Apollo that aim to convert all underlying backend services (call them microservices if you feel like it) to become GraphQL-compatible, so that the graph is everywhere. The benefit here is that a single Graph (entities with callbacks) could be used to describe your entire business logic (e-commerce, inventory, blogs, customer relations, etc) while headless frontend simply follow from that.

Downsides to GraphQL, upsides of gRPC

There are a couple of downsides to this approach: Sometimes having separate connections for separate services (like ElasticSearch) simply is done better by using that native API (like ElasticSearch its REST API), instead of trying to convert this to GraphQL. And not for every scenario, GraphQL its features are an added-value (request-driven responses, schema merging, subqueries, fragments).

Sometimes a call to a backend service simply just needs to be just that: A simple call, as performant as possible. And that's where gRPC comes into the game: It not only makes that call possible, it also does this in the most performant way possible. gRPC uses HTTP/2 under the hood (and QUIC or actualy HTTP/3 is on the agenda), so that multiplexing is applied - a fast way to get data over the wire.

Combining GraphQL and gRPC in the Mesh

When Igor Miniailo (chief architect at Adobe Commerce) started to talk about gRPC, it scared the hell out of me at first, because I thought it would be replacing GraphQL. That's not true. GraphQL is here to stay most likely, it is just that some parts of Magento its interconnectivity (nice word, huh) is less fit for just GraphQL - gRPC might be a better fit.

As mentioned, there are limitations: For PHP, there is only a client, not a server. This client (or let me rephrase: a client) is included in the Magento_Grpc module. I haven't tried this out myself and the module overall seems a bit experimental and not updated for quite some time (2 years, without PHP 8.1 support). But still it could be something to play with.

On the other hand, the fact that it is more difficult to make backend services compatible with gRPC, was also picked up by the people behind the GraphQL Mesh. In other words, if Magento would be connecting to a Mesh server (in Node, for example), then that Mesh could be connecting towards backend servers with gRPC using the grpc handler. Lately, Magento has not mentioned gRPC anymore but the Mesh was mentioned - so to me, this sounds like the path forwards.

GraphQL for frontends, gRPC for backends

In a nutshell, gRPC seemed to have caused a little storm, when its integration was announced by Magento. This blog might come a bit late, but all-in-all, it is nice to pick up on the differences between GraphQL and gRPC anyway, even though gRPC will not be for everyone.

Bottomline is that GraphQL is still the ideal tool for frontends, while gRPC is there for specific scenarios for backend services. And they both play nicely together, thanks to the Mesh.