Local dev using docker compose (should be a 1st class citizen)

[naartjie]

Hi 👋

In our project we've gone with the recommended local dev workflow using edgedb cli. I believe this is disadvantageous to our project and that we'd be better off using docker-componse.

I opened this discussion to ask the community why Docker and Docker Compose is not recommended for local dev in the docs. Am I missing some of the benefits of using edgedb cli?

By requiring a locally installed edgedb cli for our project:

• Devs need to install "one more thing" to get going
• Devs take on more sysadmin/db admin tasks
• Sometimes things break locally (eg EdgeDB project init fails: ClientConnectionFailedError: cannot establish connection for 30s: timed out #5158)
• We have 2 different code paths for dev/production (this could be an issue with the dotnet driver only and might not be so visible with other drivers):
  • prod uses DSN connection string
  • dev uses edgedb.toml

[elprans]

Is there something specific you're missing from our Docker image and/or its accompanying documentation?

If your preference is to use Docker and Docker compose for local development, you can totally do so, there is no hard requirement on using CLI-driven instances.

That said, the CLI itself is very much recommended if you want to be productive while doing database dev tasks, most importantly edgedb migration create and such.

[elprans]

We have 2 different code paths for dev/production (this could be an issue with the dotnet driver only and might not be so visible with other drivers):

We recommend that you use the environment variables (EDGEDB_DSN and such) in production. This helps to avoid having distinct client setup code paths.

[elprans]

I opened this discussion to ask the community why Docker and Docker Compose is not recommended for local dev in the docs. Am I missing some of the benefits of using edgedb cli?

That warning is mostly targeted at new users that might be "defaulting" to docker-based workflow without a very clear need. Using the native CLI workflow has the following benefits:

• automatic credential management;
• automatic instance startup and shutdown on inactivity;
• much better performance on Mac, because a native build is used as opposed to running a Docker image via a VM;
• automated upgrades (edgedb instance upgrade);
• easy way to pop an authenticated UI (edgedb ui)

[naartjie]

Hi @elprans, thank you so much for taking the time to respond and shedding some more light.

Is there something specific you're missing from our Docker image and/or its accompanying documentation?

No, I think I'm all set, in fact our project already has a half-working docker-compose file. I say half working because all of the developers have opted to use locally installed edgedb instance and there are things which don't work out the box.

I want to refactor the project to instead allow the default workflow to be docker based, and when required it can be customised to a local install (instead of the other way around, which it is currently). My original motivation for posting this was to put a feeler out for how I might be putting the project/team at a disadvantage by changing the default workflow.

That said, the CLI itself is very much recommended if you want to be productive while doing database dev tasks, most importantly edgedb migration create and such.

Understood. You are way closer to the db and the schema/entities and you are able to iterate faster.

We recommend that you use the environment variables (EDGEDB_DSN and such) in production. This helps to avoid having distinct client setup code paths.

↑ This is the exact problem we had in our project. EDGEDB_DSN environment var used in production and some project.toml / edgedb instance link magic in dev which I still don't fully understand.

(You might already know our story from other sources, but I'll reiterate here for others' sake: we've now switched away from using the dotnet driver and are using http directly instead, hence our db url is now unified across any env).