Assessments

This section contains answers to questions from all chapters.

Chapter 1, Introducing Dapr

1. Service-to-service invocation, state management, publish and subscribe, bindings, actors, observability, secrets, and configuration.
2. The CLI lets you interact with the local or remote runtime.
3. First, install Dapr CLI, then initialize Dapr.
4. You can install Dapr on Kubernetes via the CLI or Helm.

Chapter 2, Debugging Dapr Solutions

1. Using the Dapr extension, you can prepare a project for debugging.
2. You can follow the usual approach to combine the debug configuration of multiple projects together.
3. You can launch the project via launch configuration, using the Dapr CLI or Tye, and then attach VS Code to the corresponding process.
4. You adapt the Tye recipe for Dapr to fit your solution’s specifics.

Chapter 3, Microservices Architecture with Dapr

1. Bounded contexts are so relevant because they help architects in taming the complexity of the overall architecture into more easily manageable microservices.
2. Given that runtimes such as Dapr are available, there is a lower barrier of entry in adopting microservices: nevertheless, the size and culture of your team are more relevant in deciding whether you are up with the task.
3. In my experience, observability is the most underrated requirement in a microservices architecture, which Dapr can bring significant advantages to.

Chapter 4, Service-to-Service Invocation

1. A lot! A few examples are the minimal hosting model and minimal APIs
2. Dapr does always rely on gRPC for communication between its sidecars.
3. For most microservices, there is not a need for gRPC; if you are looking for network efficiency between hosts/nodes, then Dapr will give you that benefit with service-to-service invocation.
4. It depends on what you value most; I prefer the simplicity of HTTP on the microservice side.