Workflow for developing app in compiled languages like Go is not clear

[develar]

DevSpace is awesome, at least, it looks so :) Thanks for the excellent documentation.

But development experience doesn't look smooth, and I am not sure or I miss something, or it is still not yet implemented/polished.

Say, I have a simple app with frontend (vite spa) and backend (golang).
In Quickstart (https://devspace.sh/cli/docs/quickstart), you suggest to:

As soon as the terminal opens up, you can start your application:
go run main.go

First issue:

But wait, shouldn't devspace dev start-up app a fully running application? Does it mean that currently, I have to in each terminal for component invoke some command?
If you have the only component in your app, you will not use k8s/devspace. I propose to improve Quickstart and provide examples for at least two components.

Second issue:

Documentation for https://devspace.sh/cli/docs/configuration/development/file-synchronization doesn't mention that you cannot use actual commands to run or compile or somehow else process application code since, well, a deployed container in a dev mode doesn't have application code — it is not synchronised yet.
For production, multi-stage is used — golang:1.16.6-buster to build an app, gcr.io/distroless/static-debian10 to run produced binary. So, you need some helper that will wait when application code will be initially uploaded, then will compile it, and then on onUpload.execRemote.onBatch will somehow restart running app (say, via signal).

I do not request feature "please implement such helper for me". I just want to understand that I don't miss something and my understanding is correct.

[LukasGentele]

Thanks for opening this issue. To your two issues:

1. Starting the application on devspace dev: This was actually the default behavior in DevSpace for a long time but we changed it because most teams wanted their engineers to have more control (e.g. be able to run unit tests, install dependencies, recompile certain things on demand) and a static entrypoint can't really handle all of this. However, we typically in the devspace init add a devspace_start.sh script now which is called inside the container once the terminal opens. It can be useful to either start certain service OR to show some information about commands that the user may want to run to kick things off inside the container.

Regarding backing service needing to start: Let's say you have 10 microservices and each of the git repos for these services has a devspace.yaml, then they typically somehow reference each other via dependencies (https://devspace.sh/cli/docs/configuration/dependencies/basics). Dependencies are deployed similar to devspace dev and you could even specify to use a "production" profile when these dependencies are deployed. EIther way, they should stand up without manual interaction. Only the service that you are currently working on (where you ran devspace dev) should be starting in interactive mode (terminal after replacePods). And if you want to work on 2 service, you should be able to run devspace dev again for the 2nd service and it should just replace this service's instance with an interactive/terminal one. This is designed to be as flexible and composable as possible while still providing a great UX for the engineers because they don't need to do anything when working on a service. They run the same commands as in their local terminal when testing locally but with the only difference that they run devspace dev first to open the container terminal.

Regarding more complex docs example: Maybe you're right on that front. We should probably add some "microservice" examples with different containers interacting. Not a bad idea at all. Thanks for suggesting that! If you'd like to contribute a demo project, feel free to link it here and we can see where to add it in the getting started guide.

2. The helper script you are talking about was an essential part of the DevSpace workflow before we made the workflow I described in 1. the default way of working with DevSpace. You can still use our helper by enabling image building (which is now by default only in profile production rather than the base config) and then using injectRestartHelper: https://devspace.sh/cli/docs/configuration/images/inject-restart-helper

I hope this clarifies a few things that seemed unclear before. Let me know if you have any questions or feature requests regarding any of these. We want DevSpace to be the tool that provides the best UX and fastest dev workflow for Kubernetes, so any feature request or feedback specific to your stack or workflow is always welcome and highly appreciated.