In a previous article I described how I prepared my local development environment from working with the source code of the Dapr project – locally editing, building and running customization on Dapr. This is a prerequisite for creating custom Dapr components – as is my true intention. In this article I will complement the previous one with the overview of how to extend the local development environment for the Dapr components and how to make a first small change and see it reflected at runtime.
When the local setup is correct, I am all set for creating those custom components.
Clone Dapr Components Repo into local dapr-dev directory
or simply: git clone github.com/dapr/components-contrib
Replace the reference in Dapr to components-contrib
When dapr is built and the daprd executable is created, the sources used for all components are read from the github.com/dapr/components-contrib. However, I want the local sources for these components to be absorbed at build time. In order to do so, I have to instruct Go – the compiler – to not go out to github for these sources but instead use them from my local directory.
The following statement creates this “substitution” instruction:
replace github.com/dapr/components-contrib => ../components-contrib
The result is a single line in the file dapr-dev/dapr/go.mod:
Make a small change in the Redis State Store Component, Rebuild and Run
I want to be assured that the local components’ sources are actually used when rebuilding dapr – and that a change I apply is absorbed and takes effect. I can quickly try this out by making a small change in one of the components that is implicitly loaded by dapr: the Redis Statestore.
I open file redis.go in folder state/redis under components-contrib. I add two lines that each write a log entry – one in the Init function and one in the Get function:
Before make build is successful I first have to run go mod tidy (usually only needed the first time after cloning the repository to download the referenced sources).
Next, time to make build:
and to copy the resulting daprd binary.
At this point, when I run the quickstart hello-world application with dapr. it should use the locally created executable for daprd that includes the ever so slightly modified redis state store.
From the quickstarts/hello-world/node directory, I execute:
dapr run –app-id nodeapp –app-port 3000 –dapr-http-port 3500 node app.js
The logging includes the new log line produced in function Init:
When I try to revoke data from the state store,
wget http://localhost:3500/v1.0/state/statestore/order
I also see the effect of my change to the Redis State Store:
And now I feel I am ready for bigger things such as creating my own custom component. This is the subject for another article.
Resources
My a previous article on setting up a local development environment to work on the Dapr source code
Dapr Components GitHub Repo – https://github.com/dapr/components-contrib
Dapr Docs: Setting up local Dapr development environment: https://github.com/dapr/dapr/blob/master/docs/development/setup-dapr-development-env.md
Dapr Docs: Custom Development and local build of Dapr: https://github.com/dapr/dapr/blob/master/docs/development/developing-dapr.md
Dapr Docs: Development of Custom Component – instructions (also on make build and replace) – https://github.com/dapr/components-contrib/blob/master/docs/developing-component.md
