API endpoint to provide playlist information

changed milestone to %1.0-alpha2 — Precise Pheasant

assigned to @nnrcschmdt

discuss how this proxy should be implemented in detail. @equinox suggested to use a jRPC/gRPC proxy implementation rather than REST endpoints.

Let's also evaluate if some caching strategy should be applied.

This apparently was a misunderstanding. I didn't mean to suggest to use gRPC over REST. I only mentioned gRPC in context of Envoy which probably could be configured to route the HTTP requests to the right playlist information backend (tank or engine-api) dependent on the requested time-range. However for most deployments it would most likely be easier if steering has a built-in reverse proxy.

As for caching: i would vote against it - at least for now.

Thanks for the clarification and the tip on Envoy.

Regarding reverse proxy: the Aura Web docker compose comes packaged with a pre-configured NGINX reverse proxy. Or are we talking about an additional reverse proxy soley for steering?

Anyway, things like Envoy are new to me, so I'll have to dig deeper first.

I don't think that nginx is powerful enough to do this. It's probably ok for the most simple cases (selecting the proxy backend based on the current date/time using the map-module) but for shows that are currently running it would be very nice to merge the information from engine and tank. This means sending 2 outgoing requests for one incoming. I don't think the architecture of nginx allows for such a thing. Maybe using the nginx-lua module but if we use that we might as well write it in python as part of steering.