Introduction to Dapr Part-2
Introduction
Please read part 1 of the Introduction to Dapr series before reading this one to learn about the benefits and setup of Dapr.
Microservice Based Application should have the ability to communicate with other services, which is called as inter Service communication. This can happen in two ways
- Synchronous communication
- Asynchronous communication
Synchronous communication
Synchronous communication occurs when one service communicates with another service via the REST endpoint using the HTTP or GRPc protocol. The calling service will wait until the caller service responds in this approach.
Asynchronous communication
Asynchronous communication occurs when one service communicates with another via asynchronous messaging. The calling service will not wait for the caller service to respond. It will inform the caller service with a specific message or data. Asynchronous communication in microservices will be accomplished using messaging brokers such as Apache Kafka, RabbitMQ, and Redis Streams.
In general, developers should handle both kinds of communication. But Dapr provides out-of-the-box solutions for both communications.
In this blog, we will discuss Synchronous communication in Dapr, which is known as service invocation.
Service Invocation
Service invocation is a way of handling synchronous communication In Dapr which provides features such as built-in load balancing and service discovery as well as distributed tracing, metrics, error handling, encryption, and other features.
service invocation can be done in two protocols HTTP or GRPc
To understand it better, let's go with an example.
Firstly, create a new Express.js application with the name user-service which has the file index.js.
This file has only one route, /user, which returns a user. In general, we must go to localhost:4000/user URL to access this route.
This route gives a result like this
However, if other services want to use this route in Dapr, they can use the Dapr sidecar URL of that application instead of calling the service directly .
Let's take a look at how to get to this route using a Dapr sidecar. To accomplish this, we must launch the application with Dapr
- -app-id : Name for application. You can give any meaningful name related to the application.
- -app-port : The port in which your application wants to run
- -dapr-http-port : In This port dapr sidecar will run for the application
- npm start : This is used by dapr to start the application. This command is basically an entry to start an application
In summary, the above command will start the application in app-port with the given command npm start, as well as the application's sidecar in dapr-http-port.
Instead of starting the application normally (npm start), use the above command to do so.
If you see something like this in the console, your application and the sidecar of your application started successfully.
Now similarly, create another service called notification-service, which has an index.js file.
Similarly, start the in notification-service with Dapr with command like
Now you want to go to the /user route to get user information from the notification service. To do so, we must utilise the Dapr sidecar URL.
- daprPort : The port in which dapr sidecar is running
- appId : The app-id of which you want to invoke a route
- methodname : The route you want to invoke
In our case, we want to use user-service from notification to obtain user information so that the sidecar URL will look something like this:
Now install the Axios in notification-service make Axios call to user-service to get user information. The new index.js file in the notification-service look something like this:
Now if you hit the /notify .it will make Axios call to user-service sidecar to get user information
It will show the result as
Yes, we did use Dapr Sidecar to collect user information. However, you can see why we use a sidecar URL rather than the application URL. There will be many advantages if you use a sidecar URL because you will not have to worry about service discovery. It will find appropriate services in the network and will be provided with distributed tracing for APIs, among other things.
We have now seen how to invoke a service using a Dapr sidecar URL. However, Dapr offers an SDK that we can utilize to invoke services without explicitly using the Dapr sidecar URL. yet, SDK also employs sidecar URLs in the background.
Now install Dapr JS-sdk
Firstly, import Dapr in index.js file
Secondly, we have to connect with Dapr client so that with the client we can access the service invocation method
The first argument will be the host address, the second will be the port on which the sidecar is running, and the third will be the protocol we are using, whether HTTP or GRPc.
Now replace Axios call as
The first argument will be app-id(user-service) followed route(user) you want to hit in that service
so the final index.js file in notification service will be like this
Book a Discovery Call.
