Closed dennis-campos closed 2 years ago
@kgajera
I am in favor of not adding any of the docker related files to the template, but instead expand the documentation that Dennis added for how to set up a docker-compose.yml, a development Dockerfile, and a link pointing to how to setup a production Dockerfile
I think I'm in the same thoughts here -- If we don't have a complete Docker solution, I would opt for Docs or links to Docs.
I still think it's a good idea for us to figure out a Docker Deploy strategy but this seems more for local dev.
I think we need to settle the question of whether we're doing this for dev or for production. If it's dev-only, even if we run the app inside Docker, we don't need the Dockerfile
. And, actually, for production we probably don't either. If users are going to roll Docker in production, they'll need to plan their own setup anyway. It might not look anything like what we include. Like Kishan and Matt mentioned, I think linking to some docs for a production Docker setup would be better and not documenting that at all on our end (because, even with docs, we can't hit everyone's production setup and we'd need to keep those docs up to date).
Adding a
docker-compose.yml
to the template that does not include all services feels incomplete to me. This is not what I would expect if I was developer trying to use it- this might be based on my own experience, but this is how I've seen other template repositories work, for example: https://github.com/graphile/starter. This provides an easy for a way developer to get started without needing to worry about their local setup.
- For me, the main question is, how many developers would actually utilize a database only docker compose file enough to make it worth adding to the template? Or is it just adding bloat to the template?
I use a Postgres-only docker-compose setup on a lot of projects. There are a few benefits:
docker-compose up -d
). Also, one less daemon running on my machine is always a plus.docker-compose up -d
).cp -R .data ~/temp/my-project-data-before-changes
.We discussed this in Discord, but there are a few downsides to running a Next app in Docker:
I've worked on a lot of projects where we wanted to "Dockerize all the things!!" in dev and it honestly ends up being a headache (even just because of the bad DX from the slow refresh). I've settled on this: Run node locally, run anything that can run on node outside of Docker, and run everything else in Docker. Yes, managing Node versions can be a headache too, but the tooling around that has gotten so much better; you can specify the node version in code and use your node version manager of choice to install/run the correct one.
I forgot to mention: Great work on the documentation, working through the setup, and making good decisions around what to include and not to include, @dennis-campos!
I think we need to settle the question of whether we're doing this for dev or for production.
We were aiming for local development set up here.
I use a Postgres-only docker-compose setup on a lot of projects. There are a few benefits:
To me this seems more like a preference on how to run Postgres. I'm questioning whether there is a reason to include it in the template if there's not a clear majority who will run Postgres this way. That's why I like Blitz's approach on adding docs (https://blitzjs.com/docs/postgres) and that can be decided by the project.
We discussed this in Discord, but there are a few downsides to running a Next app in Docker:
Agree with your points to some extent. My main motivation for wanting to include a docker compose that supports running the app that "just works" was to lower the barrier of entry for someone trying out the template.
Also noting that our CLI currently prompts the user for database information when creating an app which I think adds another layer of confusion for a first time user who wants to run in Docker.
I use a Postgres-only docker-compose setup on a lot of projects. There are a few benefits:
To me this seems more like a preference on how to run Postgres. I'm questioning whether there is a reason to include it in the template if there's not a clear majority who will run Postgres this way. That's why I like Blitz's approach on adding docs (https://blitzjs.com/docs/postgres) and that can be decided by the project.
Good point. Maybe just documenting options is best.
We discussed this in Discord, but there are a few downsides to running a Next app in Docker:
Agree with your points to some extent. My main motivation for wanting to include a docker compose that supports running the app that "just works" was to lower the barrier of entry for someone trying out the template.
That's a helpful clarification. It does sound appealing. Though I wonder if it sets a bad example since running the dev app in Docker may not be a great setup. We're inviting new users into a bit of a painful developer experience.
Also noting that our CLI currently prompts the user for database information when creating an app which I think adds another layer of confusion for a first time user who wants to run in Docker.
True, that is confusing. If we include a Docker setup, we'd probably want to update that.
So are we reaching a consensus that documenting some Docker setup options is the best move?
Docker configuration to bison app.
Docker is set up to run postgres locally. If you want to run the entire app, please refer to the documentation.
Changes
Dockerfile
,.dockerignore
, anddocker-compose.yml
copyFile.js
to generate the proper files when running a bison app.Checklist