If you have spent more than five minutes in microservices development, your default answer for service-to-service communication is probably REST. It is simple, human-readable, and Postman makes it look easy. But as my Hospital Information System (HIS) grew, I started asking: "Is 'easy to read' really more important than 'hard to break'?"

The project I am referencing: Hospital Information System

That is when I decided to shift my internal communication to gRPC.

The JSON Guessing Game

To tell the truth, I do not like the JSON guessing game. Data integrity is not a luxury; it is a requirement. When a microservice asks for the availability of anything, it needs to be 100% sure about the data types it receives. With REST, you are essentially playing a guessing game. Did the Doctor service change a field name from doctorId to id? Did they change a date format? And so on.

Why gRPC Became My Choice

Protocol Buffers as the Law

Instead of writing documentation that people might not read, I define my contracts in .proto files. Protobuf is a binary serialization format that enforces a strict schema.

HTTP/2 Performance

Internal calls need to be fast. gRPC uses HTTP/2, which supports multiplexing (sending multiple requests over a single connection) and header compression.

Type Safety & Auto-generation

I love writing code, but I hate writing boilerplate (and I use Java...). gRPC generates the client and server stubs for me.

How I Used It

In my case, when a patient is admitted, the admission-service needs to verify both the Patient's status and the Doctor's license. Using gRPC for these calls ensures that these "read" operations are extremely low-latency, allowing the UI to remain responsive while complex entity verification happens in the background.

Here is a real example from the project showing how a contract is defined (appointment_event.proto). This acts as the ultimate source of truth for the services, eliminating any guesswork about data types: 

syntax = "proto3";

package appointment.events;
option java_multiple_files = true;

message AppointmentEvent {
  string patientId = 1;
  string doctorId = 2;
  float amount = 3;
  bool paymentStatus = 4;
}

The Honest Trade-offs

Debugging is Harder

You cannot just curl a gRPC endpoint or look at the payload in a browser. You need specialized tools like BloomRPC or Postman's gRPC support.

Learning Curve

Browsers do not support gRPC natively (you need gRPC-web), so it is strictly for "backend-to-backend" communication in my case.

Boilerplate

While code generation saves time, you still have to manage .proto files and the build pipeline to generate the classes.

I still use REST for my external API (via the Gateway) because that is what the world speaks. But for the internal "brain" of the Hospital Information System, gRPC is the clear winner. It swapped the "JSON guessing game" for a strict, high-performance contract that makes the system significantly more resilient.