Extending Local Dapr Development Environment for Custom Components

Lucas Jellema

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:

SNAGHTML2b93441band 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:image

And now I feel I am ready for bigger things such as creating my own custom component. This is the subject for another article.


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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Next Post

A quick and easy Apache NiFi development environment

Vagrant can be used to quickly create development environments in for example VirtualBox, VMWare or Hyper-V. I decided to use Vagrant to create a quick Apache NiFi development environment. For Apache NiFi development, you also often require input/output for which Kafka can be used, the NiFi Registry to manage shared […]
%d bloggers like this: