Include STAC browser in the helm chart

[sunu]

eoAPI's docker-compose setup ships with STAC browser as an ui to interact with the STAC catalog - https://github.com/developmentseed/eoAPI/blob/80a7255fefffa19af89ce001834fe7dc50294a4c/docker-compose.yml#L6

Should we include that in the helm chart as well and perhaps make it optional?

[ranchodeluxe]

@sunu: sounds good to me, not high on my priority list since I have other things I want to focus on but anyone can put in a PR

[alekzvik]

Hello,

I looked into implementing this change and stumbled upon some inconveniences.
I tried to use nginx-based ingress, similar to other services and route all the requests with a prefix (e.g. /browser) to a newly added service for stac browser.
The problem with this approach is that /browser as pathPrefix must be specified during build process for the stac-browser image (link). This means we can not use the image published by stac-browser.

I can see few options how to proceed:

1. build one more image in the radiantearth/stac-browser with pathPrefix set to /browser (not sure if stac-browser maintainers want it or need it)
2. build the image in the CI of this repo
3. build the image in some third repo
4. do not use pathprefix routing

Do you have any opinions on the matter?

[ranchodeluxe]

I can see few options how to proceed:

1. build one more image in the radiantearth/stac-browser with pathPrefix set to /browser (not sure if stac-browser maintainers want it or need it)

2. build the image in the CI of this repo

3. build the image in some third repo

4. do not use pathprefix routing

Do you have any opinions on the matter?

Hey @alekzvik, thanks for writing and thinking about this ✨

I think options 1 and 3 make the most sense to me.

Regarding option 4, this is still tractable work and offers some tradeoffs that are worth noting. If we add a simple values flag that changes this deployment what we get is:

Pro:

• each API has it's own ingress and subdomain or host

Con:

• auto-scaling gets a little more complicated. this option would probably still want to share a single load balancer and single ingress controller though; b/c it's easier to set auto scaling rules on one thing version three things separately (which is why we stuck with the single ingress and path rewrites). that said I think nginx exported metrics about request rate are still aggregated by host so it still might complicate auto scaling rules in a way that I'm not seeing clearly (and in a way integration tests would have to account for)

[alekzvik]

I tried approach number 1, it was rejected by the maintaner. I then created a repo for approach number 3 and submitted a PR - #168.