nt_web_template/full-stack-fastapi-template
2
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

✨ Use Live Reload server by default in development

Browse Source
This commit is contained in:
Sebastián Ramírez
2019-03-14 16:05:50 +04:00
parent 6c83c57ad6
commit 5cb50a9986
3 changed files with 16 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -148,6 +148,10 @@ After using this generator, your new project (the directory created) will contai
### Next ### Next
* Set `/start-reload.sh` as a command override for development by default.
* Update generated README.
### 0.2.0 ### 0.2.0
**<a href="https://github.com/tiangolo/full-stack-fastapi-postgresql/pull/2" target="_blank">PR #2</a>**: **<a href="https://github.com/tiangolo/full-stack-fastapi-postgresql/pull/2" target="_blank">PR #2</a>**:

14
{{cookiecutter.project_slug}}/README.md
View File

@@ -69,7 +69,13 @@ The changes to those files only affect the local development environment, not th
For example, the directory with the backend code is mounted as a Docker "host volume" (in the file `docker-compose.dev.volumes.yml`), mapping the code you change live to the directory inside the container. That allows you to test your changes right away, without having to build the Docker image again. It should only be done during development, for production, you should build the Docker image with a recent version of the backend code. But during development, it allows you to iterate very fast. For example, the directory with the backend code is mounted as a Docker "host volume" (in the file `docker-compose.dev.volumes.yml`), mapping the code you change live to the directory inside the container. That allows you to test your changes right away, without having to build the Docker image again. It should only be done during development, for production, you should build the Docker image with a recent version of the backend code. But during development, it allows you to iterate very fast.
There is also a commented out `command` override (in the file `docker-compose.dev.command.yml`), if you want to enable it, uncomment it. It makes the backend container run a process that does "nothing", but keeps the process running. That allows you to get inside your living container and run commands inside, for example a Python interpreter to test installed dependencies, or start the development server that reloads when it detects changes. There is a command override in the file `docker-compose.dev.command.yml` that runs `/start-reload.sh` (included in the base image) instead of the default `/start.sh` (also included in the base image). It starts a single server process (instead of multiple, as would be for production) and reloads the process whenever the code changes. As it is in `docker-compose.dev.command.yml`, it only applies to local development. Have in mind that if you have a syntax error and save the Python file, it will break and exit, and the container will stop. After that, you can restart the container by fixing the error and running again:
```bash
docker-compose up -d
```
There is also a commented out `command` override (in the file `docker-compose.dev.command.yml`), you can uncomment it and comment the default one. It makes the backend container run a process that does "nothing", but keeps the process running. That allows you to get inside your living container and run commands inside, for example a Python interpreter to test installed dependencies, or start the development server that reloads when it detects changes, or start a Jupyter Notebook session.
To get inside the container with a `bash` session you can start the stack with: To get inside the container with a `bash` session you can start the stack with:
@@ -91,7 +97,7 @@ root@7f2607af31c3:/app#
that means that you are in a `bash` session inside your container, as a `root` user, under the `/app` directory. that means that you are in a `bash` session inside your container, as a `root` user, under the `/app` directory.
There is also a script `/start-reload.sh` to run the debug live reloading server. You can run that script from inside the container with: There you use the script `/start-reload.sh` to run the debug live reloading server. You can run that script from inside the container with:
```bash ```bash
bash /start-reload.sh bash /start-reload.sh
@@ -103,11 +109,11 @@ bash /start-reload.sh
root@7f2607af31c3:/app# bash /start-reload.sh root@7f2607af31c3:/app# bash /start-reload.sh
``` ```
and then hit enter. That runs the debugging server that auto reloads when it detects code changes. and then hit enter. That runs the live reloading server that auto reloads when it detects code changes.
Nevertheless, if it doesn't detect a change but a syntax error, it will just stop with an error. But as the container is still alive and you are in a Bash session, you can quickly restart it after fixing the error, running the same command ("up arrow" and "Enter"). Nevertheless, if it doesn't detect a change but a syntax error, it will just stop with an error. But as the container is still alive and you are in a Bash session, you can quickly restart it after fixing the error, running the same command ("up arrow" and "Enter").
...this previous detail is what makes it useful to have the container alive doing nothing and then, in a Bash session, make it run the debugging server. ...this previous detail is what makes it useful to have the container alive doing nothing and then, in a Bash session, make it run the live reload server.
### Backend tests ### Backend tests

2
{{cookiecutter.project_slug}}/docker-compose.dev.command.yml
View File

@@ -10,3 +10,5 @@ services:
--web --web
# backend: # backend:
# command: bash -c "while true; do sleep 1; done" # Infinite loop to keep container live doing nothing # command: bash -c "while true; do sleep 1; done" # Infinite loop to keep container live doing nothing
backend:
command: /start-reload.sh