The microservices don't have to be written in Golang to leverage the power of gRPC; you can write gRPC servers and clients in any number of languages that use a protobuf defined through IDL. I'd gladly contribute to something if it'd be helpful, though.
What you've laid out might be the simplest approach for getting an MVP up quickly, but once you look under the hood in Dgraph, I think you could come to the conclusion that you don't need to include Apollo at all. This is a doozy, so apologies for the lack of brevity, but I hope it's ultimately clear what I mean.
Dgraph stores its data as RDF triples and partitions the data across Alpha Nodes (their method of horizontal scalability) based on predicate, not object. As Dgraph traverses the full query, each successive subgraph is queried via gRPC from the appropriate Alpha Node. I've been toying with the notion of modifying the subgraph routing algorithm so that, when the query parser comes across a predicate that is flagged on the schema as representing some external resource (i.e. not data stored in the database), the subgraph gRPC is passed on to some user-defined network address that behaves exactly as it would expect an Alpha Node to for Dgraph's purposes (in terms of a conforming gRPC response) but which is actually some other microservice.
In any case, it's clear that this design pattern isn't necessarily tied to any single system. Just now, we've worked through how it could be implemented through Neo4j (with something akin to neo4j-graphql-js & the appropriate tooling) or through Dgraph, maybe even any other native graph database.