@@ -115,7 +115,14 @@ The `api/v1/index.html` and everything in `lib/redoc` is static code that render
└── 🐘 services.php
```
<!-- TODO -->
The main part of the server-side code is `api/v1/services.php`. Whenever a client makes a request to the server at this path, the server executes the PHP code. The PHP code can then output things (using `echo`) which are sent back to the client. Unlike static files (that are sent to the client in verbatim), the actual code contained in the PHP file is never sent back to the client[^1].
The code itself sends HTTPS requests to the different services to see if they are up and crafts the JSON response as described in the OpenAPI specification.
The `.htaccess` files are configuration for the Apache webserver:
*`api/.htaccess` redirects every request to `/api` to `/api/v1` (so you can enter https://status.fsco.li/api in your browser and are automatically directed to https://status.fsco.li/api/v1). This is just a comfort feature.
*`api/v1/.htaccess` is more complex: It rewrites every request to `/api/v1/services` to go to `/api/v1/services.php`. <!-- TODO: Why is this necessary? A: Query parameters -->
### Docker
@@ -125,7 +132,11 @@ The `api/v1/index.html` and everything in `lib/redoc` is static code that render
└── 🐋 Dockerfile
```
<!-- TODO -->
Only for development purposes, this repository contains a Docker configuration, so you can quickly start an Apache webserver locally to preview the site.
Why only for development? If you have a look at the `Dockerfile`, you see that it actually doesn't `COPY` any code. It just sets an Apache configuration option and then calls it a day. The `docker-compose.yml` is where we dynamically mount the contents of this repository into the container. This is very common for development: Any change you make to the repository is immediately reflected inside the container, so you don't need to rebuild the image every time you make a change.
While very common for development, it is very uncommon for production to only mount the code: The idea of an image is precisely to be self-contained, so it should contain all necessary code by itself (also allowing you to quickly switch between versions of the code by switching between images). To build a production-ready setup, you should add a `COPY . /var/www/html` instruction to the `Dockerfile` and remove the `volumes` section from `docker-compose.yml`.
## Deployment
@@ -157,6 +168,10 @@ This is why we have chosen a more convoluted-looking directory structure instead
*[Semantic Versioning](https://semver.org/)
### Couldn't we have done this entirely on the client?
<!-- CORS, maybe link LiveOverflow -->
## License
This project is released into the [Public Domain (CC0)](LICENSE). You can do with it whatever you want and you don't need to credit anyone.
@@ -167,3 +182,7 @@ Note that this does not apply to third party files (those found in `lib/*`), nam
* fscoli-next Theme (`lib/fscoli-next/*`), which is licensed under the [GNU General Public License v3.0](lib/fscoli-next/style.css)
For details and authorship information, see the linked license files.
## Footnotes
[^1]:That is, unless you make a configuration error or run a server without PHP capabilities. This means: Yes, you can technically store secrets in PHP files, they should not be sent to the client – but if you ever do that, make sure you verify everything works as it should.
