I’m curious if anyone else has interest in testing out GRPC with FHIR in the future.
What is GRPC?
GRPC is a high performance open source RPC framework based on Google’s internal implementation. It means having a machine-readable contract (written in an IDL) at both ends of a communication. Because there’s a known contract for the information flowing back and forth, there are massive savings over the wire. There are GRPC server stubs in 7 languages and 9 client languages.
We’ve not talked about GRPC specifically, though there have been occasional discussions about ProtoBuf or equivalent over the last few years. All of these techniques suffer from the problem that they are very fragile against change on either end. That’s the price you pay for performance. So community interest as a whole has been fairly muted, and hasn’t grown to the level to sustain any sub-community that is active. Perhaps it will in time…
Cheers, Graham. I’m happy to hear it’s on your radar. Yeah, I was exactly thinking the same, of using protobuf with gRPC. I’ll educate myself some more on it. There’s a great thread here on versioning that highlights the challenges and ways developers have tried to sort them out.
Perhaps I’ll pivot to thinking of this kind of implementation using a much, much smaller subset of FHIR, if any opportunities come up for experimenting.
Google took care of it in their work on machine learning. Protocol buffers for FHIR using Java (other langs coming):
Thanks Richard. I’m baffled. How did you get hold of this piece of news?
I follow a Google engineer on Twitter @eigenhector
Part of the design of both Thrift and Protocol Buffers is to support backwards and forwards compatible changes. Can you qualify the “fragile against change” comment?
The design requires certain assumptions about how content is managed in order to be backwards and forwards compatible, and even then, that only stretches so far. pre-normative content in FHIR is not maintained consistently with those assumptions.