[PGijsbers]

(yes there's a wall of text but I promise it's hand written)
(I noticed I forgot to update the README again. Will do after lunch)

Change

This PR allows users to spin up the PHP REST API without also spinning up the Elasticsearch container.

Motivation

The PHP REST API is not fully functional when ES is enabled and no index exists: it will prepend ES errors to its regular output, making the responses impossible to parse. Building the ES images on startup is time consuming (30s-3mins on my machine), so with the introduction of the [ES flag]() it made sense to allow startup of services without Elasticsearch.

Alternatives Considered

The proposed approach "split" the PHP API service definition over two compose files: docker-compose.yaml and docker-compose.override.yaml. A default invocation of docker compose up uses both. This means the default behavior is not changed with this PR. Introducting a separate compose isn't pretty, but it seemed necessary. I considered the following alternatives:

• Defining a 'php light' service in addition to the regular one. This doesn't work because several services depend on the php-api service, and there is no way to instruct docker compose to use whichever service happens to be selected.
• Not providing separation, and relying on the user to set ES_ENABLED. This does not remove the dependency of the php api service on the elastic search service: the elastic search service is still started and the php api will only start after it's healthy, despite the fact that it does not need it. On my laptop, which already has the elastic search image, this has considerable overhead but it gets much worse in CI/CD where an extra image may need to be pulled in.
• As above, but also removing the elastic search dependency. This works great if elastic search is not enabled, but when you want to test scenarios where elastic search is necessary the PHP API now no longer waits for the service to be available so index creation would fail.
• As above, but also updating the startup script of the PHP API to wait for the elastic search service to start if ES is enabled. This is the only real alternative that I think could work in practice. But it hides the dependency and also requires users to use profiles: docker compose up php-api would no longer start the elastic search container, so it may lead to startup errors.

While I'm not a big fan of scattering the configuration across multiple compose files, I do think this is the best solution for v1.2.10.
Because the override file extends the original file by merging properties, the ES-enabled php-api definition needs to be moved to the secondary file.

Considering the frontend is the only service which I think needs Elasticsearch, I would propose to discuss changing the default behavior to not start the PHP API with elastic search. I created a separate issue for that where we can continue that discussion and propose that, if accepted, we address it in a separate PR.

[josvandervelde]

I was not familiar with the .override.yaml, but I like it! Fully agree, this is a nice solution until #24 is implemented.

Only point would indeed be to update the README.md :)