cli
cli copied to clipboard
dapr
Proposal: app-port watch mode
Describe the proposal
Current CLI is not easy to develop Dapr user application because it always needs to have user app executable. The problem is that a developer always needs to build the binary for the testing and it is hard to debug user app from IDE's debuggers without attaching debugger to process. It results in the low productivity in order to develop user app.
In order to resolve this problem, this proposes app-port watch mode to cli.
For example,
dapr watch --app-id mynode --app-port 3000 --port 3500
- dapr cli will monitor
localhost:3000port. cli will not run daprd unless 3000 port is available. - When 3000 port is available, Dapr cli runs daprd and then daprd connects to user app.
- cli will monitor the port on the background and if the port is unavailable, cli will kill daprd process
We can simplify this by removing the minimum arguments from the run command and "watch" when no args are provided.
We can simplify this by removing the minimum arguments from the run command and "watch" when no args are provided.
sure, we can allow no args, but if someone would run multiple dapr, he or she needs to specify the ports..
The ports are anyway specified with --app-port.
yeah that's what I said :)
Is there a reason why the Dapr CLI shouldn't always monitor the port, whether dapr run specifies a command line to start or not? I'm thinking of the case where someone starts an application using a stack-specific watcher, such as dapr run --app-id <id> --app-port <port> dotnet watch run.
This also brings up the question of the granularity of such port monitoring; stack-specific watchers may take down, rebuild, and restart applications fairly quickly. If the Dapr CLI can't capture such recycling, then the port monitoring may not be very useful. As an alternative, what if the application had the option of being more direct in telling Dapr that it's restarting, such as by POST'ing to a designated Dapr "restart" endpoint (e.g. POST http://localhost:3500/v1.0/lifecycle/restart). Applications could then add this to their startup logic (when in development mode, obviously) to indicate to Dapr that the application was (re)started and that daprd should be restarted.
Is there a reason why the Dapr CLI shouldn't always monitor the port,
Do you mean that daprd monitors the port ?
@youngbupark In your original proposal, you suggested that the Dapr CLI monitor the port and start/restart daprd accordingly. I was just asking whether it matters how the Dapr CLI was invoked (e.g. with a "watch" option or otherwise"); it seems like it'd be useful for Dapr to comprehend that the application has been restarted regardless.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
@yaron2 @youngbupark Is this issue still valid and requires attention?
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.