A Crystal web framework that makes building applications fast, simple, and enjoyable. Get started with quick prototyping, less bugs, and blazing fast performance.
When generating an application via amber new [project name] the generator creates a helpful docker-compse.yml file. This makes running or deploying an application in a modern containerized environment fairly trivial. However, the docker-compose.yml is not set up by default to support a containerized local development scheme. This means that developers will have to manually install postgresql, mysql, etc or run their own local database container if they wish develop against it locally. This change set adds the default port exposure on the host machine for postgres (port 5432) and mysql (port 3306), such that a developer can run a host machine amber process, but, a containerized database.
e.g.
$ docker-compose up db
$ amber watch
At the moment, since the ports are not exposed, a local amber process will not be able to talk to a separate database container without this change.
Alternate Designs
By default it seems as though amber is nudging users towards use of Docker a bit. This is slightly different in philosophy from Rails (which does not assume anything about deployment or development scheme: e.g. no Procfile or Dockerfile generated by default). The only other alternative design I could think of was dropping the docker-compose.yml generated by default entirely such that Amber equally makes no assumptions about how end developers will develop or deploy their applications. I personally think generated the docker-compose.yml is awesome given I prefer container style local development and deployment. Since Amber already generates the compose file, I don't think it's too much more to lean into exposing the ports for local container development.
Benefits
Local containerized development from amber new
Possible Drawbacks
Continued assumption by framework of how a developer will deploy and develop and application
Description of the Change
When generating an application via
amber new [project name]the generator creates a helpfuldocker-compse.ymlfile. This makes running or deploying an application in a modern containerized environment fairly trivial. However, thedocker-compose.ymlis not set up by default to support a containerized local development scheme. This means that developers will have to manually installpostgresql,mysql, etc or run their own local database container if they wish develop against it locally. This change set adds the default port exposure on the host machine forpostgres(port 5432) andmysql(port 3306), such that a developer can run a host machineamberprocess, but, a containerized database.e.g.
At the moment, since the ports are not exposed, a local amber process will not be able to talk to a separate database container without this change.
Alternate Designs
By default it seems as though amber is nudging users towards use of Docker a bit. This is slightly different in philosophy from Rails (which does not assume anything about deployment or development scheme: e.g. no
ProcfileorDockerfilegenerated by default). The only other alternative design I could think of was dropping thedocker-compose.ymlgenerated by default entirely such that Amber equally makes no assumptions about how end developers will develop or deploy their applications. I personally think generated thedocker-compose.ymlis awesome given I prefer container style local development and deployment. Since Amber already generates the compose file, I don't think it's too much more to lean into exposing the ports for local container development.Benefits
amber newPossible Drawbacks