Skip to main content

gRPC

Under the hood, Reboot uses standard gRPC to make RPCs between state data types in addition to additional facilities that make it easy to safely interact with stateful methods.

Each Reboot durable state data type is represented by a Protobuf message, with an associated gRPC service definition to provide methods. A Servicer interface is generated from the protobuf.

Why gRPC?​

gRPC is a tried and tested, foundational protocol for making RPCs within a distributed system: many existing microservice systems use it already for communications between services, and it has an ecosystem that supports easily interoperating with HTTP.

Reboot's enhancements​

The fundamental differences between Reboot and standard gRPC are that:

  • Reboot automatically routes RPCs to the backend that is hosting the state using a required state ID, and then provides them their state as a method parameter.
  • Reboot transparently wraps method calls based on their type to control their concurrency, and ensure that they are executed atomically and transactionally.

By incorporating these state-management facilities under the hood, Reboot applications can be much easier to write and maintain!

HTTP and websockets​

You can make calls to a Reboot application using gRPC, websockets, and HTTP (which does JSON transcoding).

Reboot also supports exposing standard gRPC services which can be configured with arbitrary HTTP endpoints, which can be useful for things like webhooks.

More generally, using JSON transcoding or exposing standard gRPC or HTTP can be very useful when interacting with a client who is constrained in their ability to use Reboot's native API, or when trying to transparently replace an existing service using Reboot.