Request for new sandbox project: dapr-compose

[artursouza]

1. Describe how the Dapr community will benefit from this project? Please, describe one or more scenarios.
   In local development, developers need to manually run each service with dapr run and keep track of the different ports and components folder (if decide to separate per app). dapr-compose is a CLI tool that will automatically start any app locally with dapr run and keep track of termination and restart policies. It all done via a single YAML file:

version: 1
common:
  env:  # any environment variable shared among apps
    - name: DEBUG
       value: on
apps:
  - id: webapp
    root_directory: ./webapp/
    components_directory: ./webapp/components # can be default by convention too, ignore if dir is not found.
    config_file: ./webapp/config.yaml # can be default by convention too, ignore if file is not found.
    protocol: HTTP
    port: 8080
    command: python3 app.py
  - id: backend
    root_directory: ./backend/
    components_directory: ./backend/components # can be default by convention too, ignore if dir is not found.
    config_file: ./backend/config.yaml # can be default by convention too, ignore if file is not found.
    protocol: GRPC
    port: 3000
    env:
      - name: DEBUG
         value: off
    command: ./backend

Then, users can simply run: dapr-compose up to start all services. If a service crashes, it will be restart with exponential backoff.

2. Which programming languages will be used?
   Go

3. Does the project have any hard dependency on other technologies or cloud vendors? Example: Kubernetes, Azure, AWS, Terraform
   It depends on Dapr CLI commands.

4. Enumerate the repositories this project will need to be created.
   dapr-compose

5. What is the ETA to have this project reach a stable version and graduate to the main Dapr organization?
   No ETA.

6. Who are the maintainers of this project and corresponding employers?
   Artur Souza (@artursouza) from Microsoft

[artursouza]

I would love to get feedback and peer with other contributors on this project.

[artursouza]

This project does have similarities from Project Tye. The main difference is that this project has an opinion on how Dapr projects should be organized locally. Directory structure, file locations and conventions still to be discussed. Theoretically, Tye could (in the future) also adopt the same conventions decided here and understand Dapr projects natively.

[XavierGeerinck]

Interesting! It’s something I’m hitting against as well quite frequently since it’s a lot of port management. Might be nice to have an extended scope where it is possible to deploy your app on targets (local, container apps, …)

[artursouza]

We could have support for multiple environments but the app would need to declare a Dockerfile to build an image and a Registry to publish. It can be extended to be an opinionates dapr-make. So, it could run stuff like:

dapr-compose build
dapr-compose deploy

in addition to dapr-compose up for local development.

[yaron2]

I like and support this! However why not do this as part of the Dapr CLI? It would certainly ease a lot of the associated maintenance burdens.

So dapr compose up,dapr compose build and dapr compose deploy.

[artursouza]

It could be part of Dapr CLI but I think it can start as a sandbox project instead because:

1. This will invoke Dapr CLI to run these apps with sidecar.
2. The application model will need to evolve (with breaking changes) for some time.
3. It might be heavily opinionated to be in Dapr CLI.

Once this project reaches a stable version, we can decide to move it to Dapr CLI and archive the sandbox project.

[yaron2]

It could be part of Dapr CLI but I think it can start as a sandbox project instead because:

1. This will invoke Dapr CLI to run these apps with sidecar.
2. The application model will need to evolve (with breaking changes) for some time.
3. It might be heavily opinionated to be in Dapr CLI.

Once this project reaches a stable version, we can decide to move it to Dapr CLI and archive the sandbox project.

Ok that makes sense. About 1. This will invoke Dapr CLI to run these apps with sidecar that's a downside as CLI dependent on another CLI is something I've seen fail time and time again. For PoC purposes this might be ok, but I want us to consider moving this into the Dapr CLI if this graduates.

[artursouza]

I agree.

Also, Dapr CLI does invoke daprd today as well - so we are following that pattern already.

[artursouza]

After thinking about this again, I do think this is a better feature in Dapr CLI since users would not need to install yet another tool.

[shubham1172]

In local development, would it also help to allow users to run different components using dapr compose? For example, as a developer I want to spawn an instance of Kafka before my app starts on port 4040.

version: 1
common:
  env:  # any environment variable shared among apps
    - name: DEBUG
       value: on
services:
  - id: kafka
    image: docker.io/bitnami/kafka
    port: 4040
apps:
  - id: webapp
    root_directory: ./webapp/
    components_directory: ./webapp/components # can be default by convention too, ignore if dir is not found.
    config_file: ./webapp/config.yaml # can be default by convention too, ignore if file is not found.
    protocol: HTTP
    port: 8080
    command: python3 app.py

[greenie-msft]

In local development, would it also help to allow users to run different components using dapr compose? For example, as a developer I want to spawn an instance of Kafka before my app starts on port 4040.

version: 1
common:
  env:  # any environment variable shared among apps
    - name: DEBUG
       value: on
services:
  - id: kafka
    image: docker.io/bitnami/kafka
    port: 4040
apps:
  - id: webapp
    root_directory: ./webapp/
    components_directory: ./webapp/components # can be default by convention too, ignore if dir is not found.
    config_file: ./webapp/config.yaml # can be default by convention too, ignore if file is not found.
    protocol: HTTP
    port: 8080
    command: python3 app.py

+1 to this idea.

@XavierGeerinck, what did you have in mind for dapr compose deploy. I'm interested in what the UX would be there.

[msfussell]

@artursouza - Can you close this issue #207 since this will be CLI repo going forward, yes?

[artursouza]

Yes. Closing since this will be part of the CLI.